Re: [rtcweb] Encryption mandate

[Paul Kyzivat <[e-mail]>]

On 9/8/11 5:33 AM, Michael Procter wrote:
> Paul, Olle,
>
> Both of you correctly point out that determining when a session is
> secure is a very hard problem - one that is nigh-on impossible except
> for certain restricted scenarios.  But I think we may have missed the
> change of emphasis in Chris' proposed UI change.  Instead of marking a
> session as secure (which is hard to determine), he is suggesting
> marking it as insecure (which is easier!).
>
> If the signalling and media entering and leaving the browser are not
> secured by an appropriate mechanism, then the session should be marked
> as 'insecure'.  If they are secured, then Chris' proposal would have
> no indication on the browser, which intuitively seems to match what we
> know about the session - secure to the server but 'who knows' after
> that.  Whether that is good enough for you will depend on whether you
> trust the service you are using.

I agree that this might provide some utility that isn't otherwise 
achievable. However, trusting the service remains an issue. Big brother 
will probably ensure that most of them have back doors.

	Thanks,
	Paul

> Michael
>
> On 8 September 2011 06:48, Olle E. Johansson<[e-mail]>  wrote:
>>
>> 8 sep 2011 kl. 02:14 skrev Paul Kyzivat:
>>>
>>> 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.
>>>
>> Agree. I see your way of thinking as an argument to make all sessions
>> confidential, encrypted by default. We can't reliable define a "secure call"
>> and separate insecure sessions from secure sessions. Which mean that a UI
>> indication won't mean anything. We can just make sure that the first hop is
>> protected, the rest is up to the application that operates the media
>> session.
>> /O
>
>
>> On 9/7/11 4:20 PM, Christopher Blizzard wrote:
>>
>> 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
>