Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

[Randell Jesup <[e-mail]>]

On 11/11/2011 8:38 AM, Hadriel Kaplan wrote:
> On Nov 11, 2011, at 7:02 AM, Roman Shpount wrote:
>
>> Well, this is a perfect example when specifying mandatory security for wrong reasons is simply being ignored. All the reactions I've seen to this so far were "this is only a SHOULD, let's disregard this for now". Getting security requirements in the standard which are too high too be practical usually produces products which disregard security completely, reaching the exactly opposite effect. I think, in this particular case, the right course of action is to use AVT tones in RTP as the rest of the industry is doing now.
> I think using in-band tones in RTP for DTMF instead of 4733 would be a really bad idea.

+10.  Let's not even discuss that option further.

>> Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established.
> That's an interesting idea.  The extra round trips of DTLS-SRTP, added to those of ICE, have had me worried about clipping when the user answers the call.  It's been an advantage of SDES not to worry about that.

Anything we can do to minimize clipping and reduce startup RTTs is a 
*very* good thing.  We should start seriously analyzing this as we're 
getting down to more specifics.

And recent privacy breaches have shown that otherwise-good pre-warming 
of connections and pre-negotiation of codecs may be problematic from a 
security point of view - exchanging ICE candidates with an incoming 
OFFER from your abusive ex-boyfriend might tell them where you are 
(local IP), though it would be possible for people not wanting to 
disclose their address to *require* a TURN proxy be in use and not offer 
local IP, limiting the leaked information.  This does require proactive 
selection of safety by the user, a risky proposition.

As a possible compromise, you could force TURN for the pre-start of the 
call and if accepted, renegotiate with real local addresses.  Might 
cause a glitch though if you're not careful.

-- 
Randell Jesup
[e-mail]