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

[Matthew Kaufman <[e-mail]>]

On Jul 29, 2011, at 10:17 AM, Hadriel Kaplan wrote:

> 
> On Jul 29, 2011, at 8:59 AM, Randell Jesup wrote:
> 
>> No disagreement at all.   I'm discussing that DTLS-SRTP is vulnerable 
>> (to a degree) to MITM
>> attacks, which is well-known, if you don't have a known-secure signaling 
>> channel.  I'm not making the
>> argument that Hadriel is.
>> 
> 
> But that *is* the argument I was making. (or at least trying to :)  
> I certainly wasn't claiming SDES nor RTP are as secure as DTLS-SRTP could be.

We agree here.

> 
> What I said to start this whole thing was: the two alternatives should not be described as choosing between secure and insecure.  BOTH alternatives require the user to verify something for the call to be secure.  BOTH alternatives have the potential to be very secure.  That is all.

I suppose that depends on what you mean by "the potential to be very secure"... certainly plain RTP *might* be secure, if it never leaves your desktop.

DTLS-SRTP + a security inspection UI gives the user a way to verify something *independently of the service provider* to see if the call is secure. SDES does not. The only way to be sure the service provider isn't colluding with someone to tap your call when you use SDES is to agree with the other party to mangle the key you receive from the service provider. (The "pessimist" approach to trust in this environment.)

> 
> BTW, I am assuming of course that even if we choose the alternative of DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer cannot do it then SDES, and if the peer can't do that then RTP. (assuming the human has set whatever browser knobs are necessary to enable/disable this stuff)

Agree. Though the human needs to be able to see a lot more about what is going on if we allow all three.

> So between two RTCWEB browsers it would always be DTLS-SRTP.

Agree.

Matthew Kaufman