Re: [rtcweb] Retransmit: Summary of Alternatives for media keying

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 6:44 PM, Hadriel Kaplan wrote:

> 
> On Jul 28, 2011, at 1:18 PM, Matthew Kaufman wrote:
> 
>> 
>> On Jul 28, 2011, at 11:13 AM, Hadriel Kaplan wrote:
>> 
>>> I would be perfectly happy with using sdes-based SRTP.  But if the call would otherwise fail altogether, I'd like the option to make the call no matter what (ie, even if it ends up being cleartext).
>> 
>> Why would the call "otherwise fail altogether"?
> 
> Because I'm calling someone who has a legacy VoIP device or is on the PSTN, and they're not going to support DTLS-SRTP.

I'm confused... do you want maximum security (because DTLS-SRTP is probably the best path to that of the choices) or maximum interoperation with legacy (because plain RTP is probably the easiest way to get that)

> Of course we could require the RTCWEB service to deploy "gateways" in order to terminate DTLS-SRTP and do SDES-based SRTP or cleartext RTP to non-RTCWEB, but that's expensive and complex.

Expensive? Maybe. Complex? Not really.

>  Not to mention its mis-leading - the media is not secure end-to-end, and again the lock-icon model won't work.

The lock icon model works just as well as the lock icon works on Gmail to indicate that your interaction with Gmail is protected but the email you send might be going via plain SMTP.

It might even be better than this, if we do a good job of sending requirements to W3C.

> 
> 
>> Have you ever called into a conference call from a public place, with your microphone muted?
> 
> Nah, I talk too much.  ;)

Even so, you'd probably rather not be recorded by a 3rd party using the microphone in your headset if you can avoid it.

Matthew Kaufman