Re: [rtcweb] No Interim on SDES at this juncture

[Dan Wing <[e-mail]>]

On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan <[e-mail]> wrote:

> 
> On Jun 21, 2013, at 12:45 PM, Dan Wing <[e-mail]> wrote:
> 
>>> We've talked about that one before I think.  If jQuery is out to get you, it's game over.  It's essentially equivalent to a malicious web-server, except of course that the operator of the web-server isn't intending to be malicious (which is an important distinction).  But again, not only does jQuery have access to information such as who you're talking to and when, it can also redirect your media to a gateway of its choosing to terminate the DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff.
>> 
>> For the attacker to succeed with the redirection of DTLS-SRTP to a server it controls, the attacker would also need to modify the SDP's a=fingerprint line which is as  trivial as the attacker's other SDP modifications.  To prevent the attacker from succeeding with such modification, we need cryptographic identity (to protect the From/To/Date/a=fingerprint and other fields), and need the browser (not JS) to verify the identity using an external service (e.g., local disk, IdP separate from the web server providing us the (compromised) JS and the SDP).  While it is true that today we don't have a way today to provide that cryptographic identity (RFC4474 does not work, draft-wing-rtcweb-identity-media written by me and Hadriel was met with silence) DTLS-SRTP creates the foundation to build cryptographic identity which can be verified by the browser itself.  Such cryptographic identity protects from this specific attack, and DTLS-SRTP protects from other attacks.
> 
> I agree - when we have such a thing, using DTLS-SRTP will have much more meaning.  But (1) there is no such thing yet, and (2) it won't make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway scenarios we're talking about, since the DTLS isn't going end-to-end.  I.e., none of the calls would successfully authenticate using such an out-of-band mechanism, even the good ones.
> 
> [note though I'm not saying DTLS-SRTP is useless today - quite the contrary, I hummed in favor of making it MTI back when that was decided, and I still think it should be MTI]

Will the existence of SDES prevent WebRTC from building this more secure system with strong identity?  That is, when we add cryptographic identity will that be effective to prevent a bid-down attack from DTLS-SRTP to SDES?  I am thinking right now that when we add identity we can prevent that bid-down, so at that time SDES could become a proper second-class citizen.

-d