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

[Randell Jesup <[e-mail]>]

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.

>> 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.

> (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.

> 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.

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).

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.

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.

-- 
Randell Jesup
[e-mail]