Re: Not encrypting content (Re: [minutes] WebRTC F2F meeting Quebec City - 23 July 2011)

On 07/25/11 14:15, Randell Jesup wrote:
> On 7/25/2011 1:28 PM, Harald Alvestrand wrote:
>
>> On 07/25/11 12:58, Randell Jesup wrote:
>>> This is true, though a subtlety that users generally wouldn't grok. 
>>> It's still insecure,
>>> just a different level of insecure.  You still want to flag to the
>>> user it's insecure, if
>>> possible.  And depending on who you expect to be wiretapping, that
>>> post-gateway
>>> link may be the less-secure one.
>> ObLangFrust: The idea of seprating things into "insecure" and "secure"
>> as if they were black and white is a fallacy, and leads to bad quality
>> of both debate and documentation. There's only "secure against certain
>> classes of attack".
>> No matter how hardened my connection is, it does not guard against an
>> attack consisting of a microphone in my room and a spy video camera over
>> my shoulder.
> Agreed - for you and I, that definition of 'secure' is correct.  Users as
> a general class would never understand that distinction, which was where
> I was thinking about.
>
> You can even argue against providing the user with any notification of
> security, at least unless they ask to see it.  I'm not sure I'd agree, 
> but
> it is an argument you can make.
Last time I was faced with this in an UI design context, we decided to 
give a prominent UI warning if the call was NOT encrypted (and we could 
detect that), and say nothing at all in case it was.
The logic was that we could give no guarantees of security, but we could 
guarantee that it was not secure..... as well as making the UI as 
"quiet" as possible in the normal (encrypted) case.
>
> If you say "no application can use this to access a gateway to the
> PSTN/etc", then you could assert that it's always encrypted - but that
> fails if the "application" includes gateways that talk webrtc (securely)
> and then forward the data to an insecure net - and there's no way to
> ever avoid that happening.  So it's best to include that use-case in our
> analysis, IMHO.
I think the PSTN interoperability use cases can be implemented this way....
>
>

Received on Tuesday, 26 July 2011 12:36:10 UTC