Re: [rtcweb] Encryption mandate

[Paul Kyzivat <[e-mail]>]

Chris,

I agree with you that the UI indication of security is important.
But its also *hard* for this application, for a variety of reasons:

- While it may be easy for the browser to know if the media stream
   is itself secured, its hard (impossible) to know that its secured
   to its ultimate end point. That is the problem with intermediaries.

- it may turn out that not all the streams in the "call" have the
   same degree of security.

Of course this can all be dealt with via proper definition of what the 
UI indication means, and doesn't mean. But doing that will just render 
it meaningless to many users. To be widely understood, the indication 
will need to be simple, and closely aligned with what people "expect".

Consider a stream that is secured to a PSTN gateway, and then travels 
over the PSTN to somebody's phone. Should that be considered a "secure" 
call? Or an "insecure" call? Or somewhere between those?

Its going to be hard work to figure out what can both be reliably 
reported to users and also be understandable and meaningful to users.

	Thanks,
	Paul


On 9/7/11 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."
>
> Once again, I would much prefer secure-only, but I'll take
> secure-by-default across browsers if I can get it.
>
> --Chris
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>