Re: [rtcweb] Encryption mandate

[Randell Jesup <[e-mail]>]

On 9/7/2011 4:20 PM, Christopher Blizzard wrote:
> On 9/7/2011 12:20 PM, Randell Jesup wrote:
>> Splitting the two topics....
>>
>>
>> On 9/7/2011 3:07 AM, Olle E. Johansson wrote:
>>
>>> To fearlessly  jump into another can of worms, I still think we 
>>> should have confidentiality - SRTP - by default. We know that these 
>>> applications will run on a myriad of devices on a myriad of networks 
>>> and it will not work to let users have to decided whether or not 
>>> they want confidentiality. If Skype did not have confidentiality by 
>>> default, there would be articles every summer and xmas in the 
>>> evening taboloids about how easy it is to listen in to your 
>>> neighbours calls and that would have hurted Skype badly.
>>>
>>
>> There is a strong argument for this.  The strongest argument for the 
>> other side is  you don't need a media gateway to talk to non-WebRTC 
>> endpoints, just a signalling gateway.  This means less delay 
>> potentially (especially if the application provider has gateways only 
>> in one geographic location) and less expense for the server provider 
>> for a pretty common usecase (gateway to PSTN).  The delay could be a 
>> significant issue.
>> It was also brought up that some usecases for internal PBX/business 
>> use would not need/prefer forced encryption.  As mentioned at the 
>> meeting, encrypting to the media gateway only gets you a modicum of 
>> privacy (though it might protect you from the "neighbor's wifi 
>> capture" case).
>>
>> You could make forced-encryption the default, and allow the 
>> application control over whether to allow it is turned off for 
>> specific cases, like a PSTN call, or under the server's control.  
>> Signalling is secure, so it could even use a direct optional 
>> downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp 
>> draft)
>>
>> It's a tough call - guaranteed (local) security is nice, but I worry 
>> about those relay cases like taiwan->USA media gateway->taiwan.  Not 
>> a huge deal on signaling/call-setup, but media...
>>
>>
>
> I want secure-by-default, maybe even secure-only.
>
> Even if it's not secure-only there's also an important UI 
> consideration depending how we end up doing that in browsers.  In the 
> past we've made the secure mode special (the lock icon in the early 
> days, now the green/blue bar) but I think that we should be making the 
> insecure mode special.  That is, always mark a connection as very 
> clearly unencrypted via UI affordances.  Just like banks "wanting to 
> know how to get the lock icon" we should be making call sites "wanting 
> to know how to get rid of that huge ugly warning that makes us look bad."

A "listening-ear" icon maybe? :-)

Agreed on defaults, maybe on secure-only.  I should note that if it's 
secure-to-media-gateway, that doesn't tell you if it's secure past that 
point, so the lack of the "listening-ear" icon doesn't really mean it's 
*really* secure.  We discussed this some at the last IETF I think.  If 
you can verify the receiver at the other end you may have more assurance 
about who you're talking to... but that's a tough question on it's own.

My experience is that media gateways a great for NAT traversal, and are 
so-so to sucking for conversational quality unless they're very close to 
one or the other endpoint (and may not be great there), and they can 
have serious costs associated with them for the service.

>
> Once again, I would much prefer secure-only, but I'll take 
> secure-by-default across browsers if I can get it.
>

The proposal would put it under control of the application to allow; 
presumably only an app that included in their service access to legacy 
media endpoints would do so.

I'll note that allowing this has minimal (not zero) security impact as 
this is UDP; a bigger issue with this might be ICE.  Currently the ICE 
requirement make this idea rather moot, unless the app can control that 
too (typically this is used to connect to PSTN gateways that you don't 
need ICE to access).   Without ICE there may be larger security issues 
per ekr's draft that just showed up; though I'll note that UDP isn't 
generally a major method of DoS or attack on a site.  It might be used 
in theory for SPIT though; if that's a real threat in any volume that 
may kill this idea.

-- 
Randell Jesup
[e-mail]