Re: [rtcweb] SRTP not mandatory-to-use

[Oscar Ohlsson <[e-mail]>]

 
Randall said:

> I'd like to explore the possibility of making sure there's a 
> workable DTLS-SRTP implementation openly available, and 
> locking WebRTC down to that only.
> 
> If we use SDES, we're effectively trusting the JS app (and 
> website) to a very large extent.  (Not to turn on the 
> camera/mic, but with the contents of all conversations.)  It 
> also means bid-down to SDES is trivial.  I'm not sure what 
> this would mean to identity validation via BrowserID or 
> others (ekr?); that might survive this, but it means media 
> could be decrypted in realtime or later if anyone has copies 
> of the packets and can get the key from the app/website.

As has been pointed out many times before it is not significantly harder to eavesdrop on a SDES call than a DTLS-SRTP call. When comparing SDES to DTLS-SRTP the comparison should really be made with plain DTLS-SRTP without key continuity or the new identity mechanism.

There are a number of reasons why key continuity doesn't work in a web context. EKR mention the problem of multiple browsers but there are other issues as well (e.g., public key not bound to an id, an increasing amount of public keys stored over time, anonymous users with one time public keys, etc). It is therefore unlikely that the user will react if the peer's fingerprint is replaced by the web application.

The new identity mechanism doesn't help eiter unless it is made mandatory to use. In the same way as the web application can downgrade from DTLS-SRTP to SDES it can downgrade from DTLS-SRTP+identity to plain DTLS-SRTP. I doubt that the identity mechanism can be made mandatory since:

(1) Many web applications do not want to depend on external identity providers
(2) Some users do not have any identity provider account
(3) Many web applications are already trusted by the user
(4) Users may not always want to reveal their identity
(5) Working out all the details of the identity mechanism will take time

Protecting ourselves against the web application would also require disabling (or at least require user consent for) lots of useful JavaScript functionality (e.g. forwarding, manipulation, or recording of streams). The bottom line is that (except in the case of security aware users) the web application will be able to eavesdrop on calls.

I know that logging and cross-site scripting has been pointed out as potential vulnerabilities for SDES. These two problems should be properly analyzed but let's defer that discussion for now. 

Regards,

Oscar Ohlsson