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

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 5:54 PM, Randell Jesup wrote:

> On 7/28/2011 1:18 PM, Matthew Kaufman wrote:
>>  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.
>>> But the browser ties the identity of the name I typed in the address bar to the cert, so that if I typed "https://mybank.com", I know it's secure to mybank.com.  Of course it could be cleartext after whomever has a cert for mybank.com, and may even end up triggering protocols that exit mybank.com and go to evil.com, but I implicitly trust mybank.com to be careful with bank info.
>> Ok, so you trust your "banking service".
> 
> And more to the point, you trust the chain of certificates incorporated into the browser to verify it's actually the entity that owns mybank.com (and EV certs come into play here too).  Overall, that's a "good" chain of trust, though no such chain is perfect.

It appears to be "good enough" for people to do banking using their web browser, which is pretty amazing if you think about it.

> 
>>> That's not the same for DTLS-SRTP; until and unless the human being verifies the keys/SAS with the far end, nothing is known.
>> If you trust your "calling service" (and are connected to it with HTTPS) then you can use that trusted service to exchange the fingerprints and verify the keys of the far end to prevent MITM.
> 
> Right, this is trusting that not only they are who they say they are, but also trusting that they haven't been compromised.   And one may not have the same level of trust in that that you have (have to have) in your bank.

I'm not sure how this is any different from any other type of calling scenario.

You always need to trust the person at the far end to not reveal the call, and trust the equipment they (and you) are using.

>> (You can also add a browser extension that uses a service that you trust but that isn't your calling service, and when you're calling other people with the same extension you can check the fingerprints in an automated way using that.)
> 
> Definitely possible, and adds another largely-independent layer of trust.

Yes, but independent layers of trust are a feature, not a bug.

And what are you arguing here? My claim is that DTLS-SRTP is often *more* secure than SDES-style keying, and certainly no worse.

This is one of the things that backs up my claim. I still haven't heard why SDES or plain RTP would be superior from a security point of view.

> 
>> If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords.
> 
> I may trust my calling service to connect me (to someone), but I may not trust them to not MITM me themselves (read CALEA or other national security services), and I may not trust them not to be compromised, since they have a far smaller monetary stake in avoiding it compared to a bank.

Sure, but again all of these things are EASIER if they use SDES. They can MITM you themselves by letting anyone get a copy of the traffic from anywhere and sending that person the keys, even after the fact. (Both passive attacks like this and getting the key later are prevented with DTLS-SRTP and DH key agreement).

> 
> Another idea related to identity: as mentioned, the cert trust chain in a browser verifies that you're talking to mybank.com or myprovider.com.  This can be leveraged to provide authentication by cert that you're talking to someone who's part of mybank.com, even if you went through myprovider.com to get there and myprovider.com might be compromised.  It doesn't directly help verify you're talking to Joe Your Neighbor, but other services can help with that (as mentioned - extensions, etc).

Yes, all good ideas, but built upon DTLS-SRTP, and not SDES or plain RTP.

> 
> Effectively, for a fairly large subset of the net, we have a deployed PKI of a form.  It's not perfect (DNSSEC anyone; recent todo with bogus certs because a CA snafu) but for most uses that it covers it's pretty good.  Getting it to cover identifying the destination as a dependent of the primary cert may be an issue for many companies, however.

I doubt it, but perhaps.

> 
> In any case, there may be a way to leverage this existing trust chain, both to authenticate who's calling you and who you're calling, for a subset of possible destinations.

Almost certainly.

Matthew Kaufman