Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

[Matthew Kaufman <[e-mail]>]

On 4/25/2013 3:14 PM, Dan Wing wrote:
> On Apr 25, 2013, at 9:39 AM, Alan Johnston <[e-mail]> wrote:
>
>
>> 2. We need it or something like it for API reasons. There are cases where the JavaScript needs to tell the browser what SRTP key to use.
> DTLS-SRTP with EKT can also perform that function, and does it without disclosing the SRTP key to all the SIP proxies and all the web servers on the signaling path.

1. Are you suggesting that we also mandate EKT?
2. Do you believe that an evil web server would do something other than 
negotiate DTLS-SRTP with the mixer it is in cahoots with?

The only advantage I can see is that if we mandate cipher suites that 
have PFS, then you get PFS... which helps until the evil web site's 
mixer records all the cleartext and saves it indefinitely as well. But 
it does help in the case where the partially-evil website only tells 
people the keys it logs. And then not, when the partially-evil website's 
mixer or gateway uses EKT and then only tells people the keys it issued.

So my conclusions (and correct me if I'm wrong):
  DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is 
just a different encrypted channel over which the key is set.

DTLS-SRTP w/EKT requires a more complex media gateway relationship for 
interworking (as it needs to be in-path for the keying on that side, 
despite the use of SDES on the other side).

DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other 
side of the interworking relationship anyway, so even though there isn't 
SDES to the browser there's SDES on the other (likely SIP) side.

And DTLS-SRTP without EKT fails for the cases where the key needs to be 
set for interworking.

And finally, to get the browser-to-browser security guarantees you want 
you need to be A) sure that you're really talking browser to browser and 
not via something else in path (like a mixer) and B) would really prefer 
that there be no way that the in-path device be able to force a key 
(thus you'd want to NOT allow EKT in the browser-to-browser case, even 
though there's no way for a browser to know what it is talking to)

>
>> Since JSEP uses SDP for this API surface, SDES works for this. Obviously it is a bad idea to send this key over unsecured channels, but this is separate from this API issue.
>>
>> And just to be clear, browser to browser should use DTLS-SRTP, and only thus mode should be considered "secure" using whatever user interface a browser chooses.
> But is there a secure mechanism to differentiate browser-to-browser calls from browser-to-non-browser calls, so we don't have to worry over SDES downgrade attacks?

This is provably impossible.

>   And for the use-cases where JavaScript has to set the key, those will often be browser-to-browser calls, meaning that we will have to support browser-to-browser SDES, contrary to your desire that browser-to-browser use DTLS-SRTP?

Yes, of course.

>   DTLS-SRTP with EKT permits the application to set the SRTP key, and more securely than SDES.

See above. I don't believe that it is "more securely". The path is 
different. Whether that path is more secure or equivalently secure is 
debatable.

Matthew Kaufman