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

Following up my recommended practice on changing the subject to reflect 
the (sub)thread content...

On 07/25/11 04:35, Randell Jesup 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.
>
> 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.

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.

Received on Monday, 25 July 2011 14:19:07 UTC