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

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 8:04 AM, Elwell, John wrote:

> [JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only self-signed certs at the endpoints, requires other means (signalling path or human-assisted) to  provide strong guarantees that you are talking to the person or organization you expect.

Agreed.

However there are weaker guarantees of properties that are certainly favorable as compared to, for instance, plain RTP or even server-keyed SRTP. (See my previous email.)

> For SIP, the (theoretical) solution is to send a fingerprint of the certificate and have that bound to authenticated identity in accordance with RFC 4474, although not feasible in most deployed SIP environments. Although RTC-Web is not specifying signalling, clearly it needs to say something about the problem, and can't just indicate to the user that communication is secure just because DTLS-SRTP is used.

Correct.

> 
> Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever we select) is terminated at a gateway, there is a real problem ensuring that the user knows the call is not necessarily secure end-to-end. Perhaps this argues towards option B, since if DTLS-SRTP is not used from browser to gateway, at least the browser should know to indicate a lesser level of security to the user.

If you are sitting in an Internet cafe using someone else's unencrypted wifi and a telephony service provider you trust would you rather 1) use DTLS-SRTP between you and the telephony provider and plain RTP past their gateway inside their internal network, or 2) use plain RTP on the wifi network and all the way to the telephony provider?

I agree that we can't display "this connection is secured everywhere" to the user... but look, HTTPS is the same. When I see a lock icon on my screen and click to see that yes, I'm really talking to who it says in the address bar, I still can't tell if they're terminating my HTTPS session in a front-end box and then using HTTP beyond it, or if the HTTPS really goes all the way to the server. And when I use HTTPS to talk to Gmail, there's no way to tell if an email I send will be sent over a TLS channel or if it'll just be plain SMTP from Gmail to my recipient.

> 
> The whole issue of the browser knowing what it can tell the user concerning the security posture of a communication is a really difficult problem.

It isn't a difficult problem if what the user is told is confined to what is provably true. (See my previous Gmail example.)

Matthew Kaufman