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

On 07/25/11 12:58, Randell Jesup wrote:
> On 7/25/2011 10:18 AM, Harald Alvestrand wrote:
>
>>> Right - a call to a PSTN gateway (or various other gateways, or to a
>>> hardware videophone, or a SIP softclient, or a SIP PBX, etc) may not
>>> support SRTP.
>>> The alternatives are:
>>> 1) use a media gateway to access all non-rtcweb resources
>>>       Since we can't assume a non-rtcweb device will support SRTP, 
>>> any connections
>>>       made to a non-rtcweb endpoint would need to go to a 
>>> "strip-SRTP-and-forward"
>>>       media gateway, removing any chance of the rtcweb device 
>>> talking directly (for media)
>>>       to the non-rtcweb resource.
>> Note that this actually protects against on-network wiretapping from the
>> RTCWEB-compatible browser to the SRTP-stripping gateway - in the case
>> where your attack model is a wiretapper using a firesheep-like attack in
>> the local LAN, this may have some value.
>> If the non-SRTP leg is between a service provider's RTCWEB gateway and
>> its PSTN legacy network, it's possible that this leg is relatively
>> secure against wiretapping.
>
> 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.

I agree that the risk may be differently distributed in different 
situations; when I call through a PSTN gateway to a telephone user in a 
country known to commonly use wiretapping, I don't assume that my local 
LAN is the point at which the call is at greatest risk.
>
>>> 2) allow non-SRTP connections, at least when the destination is a
>>> non-rtcweb device,
>>>       and inform the application that the streams are unencrypted. 
>>> Note that in 1) they're unencrypted (elsewhere), but the app may not 
>>> be informed of this,
>>> making it hard to inform the user.   We could still require SRTP for
>>> rtcweb-to-rtcweb connections.
>>> 3) ? any other ideas?
>> A nice thing about not requiring support for unencrypted RTP is that
>> implementations who don't implement unencrypted RTP don't have to figure
>> out how to tell the user that the call isn't encrypted - it's simply not
>> going to happen.
>
> Unless the unencrypted RTP is on the far side of a gateway - in theory 
> that
> SRTP-stripping effect should be relayed back to the user.  And since 
> there's *no*
> way to ensure that an rtcweb-implementing endpoint *isn't* an 
> SRTP-stripping gateway,
> we should allow for that possibility and at least give a way for that 
> information to be passed
> back.
> Yes, a gateway could lie about this.  There's no way to avoid that for 
> cases that don't
> terminate in another rtcweb client, and even there you must use an 
> end-to-end keying
> regime with some form of key-chaining ala ZRTP or some secondary 
> known-secure
> channel to verify no MITM.  And even there there's no way to ensure 
> the first connection
> isn't MITM'd without a second secure channel.
>
>> Passing information to the user about what happens to the data after it
>> leaves the browser is (in my picture of the world) a task that can only
>> be performed fully by the (Javascript, provider-provided) application,
>> so I would tend to not have the browser assume any responsibility for 
>> it.
>
> Except that the information must be available to the JS code.  The 
> status of
> remote gateway could be in the application realm, but then that may 
> require
> either it be signaled at negotiation (but what if it changes later?) 
> or use
> a reliable data channel for this.
That reliable data channel may be Websockets or XHDR via the Web server.
I don't see any clear requirement on the parts below the PeerConnection 
API here yet.
>
>
>

Received on Monday, 25 July 2011 17:29:10 UTC