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

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.

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.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 25 July 2011 18:16:57 UTC