Re: Early arriving media before 200 OK

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Rob Raymond" <robin@xxxxxxxxxxxxxxx> writes:
> BTW, I'm talking exclusively about early arriving media from the 200 OK and
> not about early media.
>
> Here are the solutions that I've heard:
> 1) Discard all media before the 200 OK - not acceptable, that early arriving
> media often includes the "hello" which if lost causes a very poor user call
> experience. Horrible in fact. I'm already concerned by the amount of data
> loss during the round-trips for DTLS negotiation and the required SIP
> signaling for ICE before a path change, let alone adding to the trouble.
>
> 2) Play a tone in the background while media is insecure. If the tone is too
> loud then the audio is unrecognizable and it interferes and if the audio is
> too low then not all users will be able to hear it (including those with
> some hearing impairments). Tones interfere with signals such as FAX tones.
> Besides, who is to say it's an audio media stream at all.
>
> This is not a metaphor users are familiar. Typically tones indicate other
> things, such as toll costs, but never an indication of a current security
> level. I think this proposal was more about early media than early arriving
> media but still the idea is still not good.
>
> 3) Visually indicate to the user that the call is not yet secure. I dislike
> this one most of all. The user will engage "secure" mode and expect all
> calls placed to be secure, especially if they have a mode which is "only
> allow secure calls".
>
> With modern USB devices and other such devices, the user doesn't even have
> to look at a computer or LCD screen anymore. This method assumes the user is
> actively paying attention to the subtlety of a user interface change. When a
> user places a secure call, they expect the call to be secure, not partly
> secure, or secure after a few seconds.
>
> Further, this ruins the reputation of security. If the call is secure then
> nobody should be able to interfere especially with bogus media. Allowing
> media propagated from the likes of spammers, fraudsters, hackers and
> hoaxsters is not acceptable. This is not a good impression of what security
> should look like.
>
>
> I propose that the bar be raised and that this limitation be rejected in
> favour of something that ensures all early arriving media is at least the
> recipient of the INVITE.

I agree that this is a concern--though not as serious a one as you
seem to believe (see S 8.4 of draft-fischl-sipping-media-dtls-01)
but it can be ameliorated in a number of ways.

1. If ICE is being used it's not an issue at all.
2. We can have the SDP offer include a randomly-generated key which
   is used to key TLS PSK mode.

I don't have a problem considering the addition of the second
feature to the SDP once we get the rest of the SDP details worked
out.

-Ekr