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

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.

>> 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.



-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 25 July 2011 16:59:54 UTC