Re: [minutes] WebRTC F2F meeting Quebec City - 23 July 2011

On Jul 25, 2011, at 4:35 AM, Randell Jesup wrote:

> On 7/24/2011 5:12 PM, Francois Daoust wrote:
>>   Matthew_Koffman: I think legacy interoperability is missing from
>>   your slides.
>>   ??2: what do you mean with legacy interoperability
>>   Matthew_Koffman: I can show you existing devices that do RTP but not
>>   SRTP. If you want to non secure devices, you need to relax the
>>   bullet presented that unencrypted data do no need to be carried.
>>   hta: one of the things that someone mentioned is that we need to
>>   talk to gateways.
> 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.
> 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?

I have an (IETF) draft addressing in more detail my own personal opinion on this that I hope to submit today, which will be too late to consider in this current IETF meeting but should answer these questions.

Also, my draft-kaufman-rtcweb-security-ui talks about allowing the user to directly examine whether or not the media is encrypted... clearly we'd want to expose this in Javascript as well, but the user cannot trust what the application tells them, so we need both methods. This draft is an IETF submission that is intended to become a recommendation from IETF to W3C, but certainly anyone on the W3C side (my organization is not a W3C member) could accelerate that process.

Matthew Kaufman

Received on Monday, 25 July 2011 11:08:35 UTC