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

[Max Jonas Werner <[e-mail]>]

On 21.06.2013 18:45, Dan Wing wrote:

> On Jun 20, 2013, at 7:58 PM, Hadriel Kaplan <[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.

draft-ietf-rtcweb-security-arch-06, section 5.6 talks quite clearly
about verifying peer identities (without concentrating on a signalling
protocol like SIP) so if you would want to have secure communication
(even with a signalling server you don't trust) _and_ verified peers a
combination of DTLS-SRTP and the mentioned peer authentication mechanism
in draft-ietf-rtcweb-security-arch-06 would be a must.

As far as I understand it, SDES cannot provide the same level of
end-to-end security under the assumption that you don't trust the
signalling server.

Max