- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Mon, 25 Jul 2011 14:15:19 -0400
- To: public-webrtc@w3.org
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