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

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 11:13 AM, Hadriel Kaplan wrote:

> 
> On Jul 28, 2011, at 8:25 AM, Matthew Kaufman wrote:
> 
>>> 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 would be perfectly happy with using sdes-based SRTP.  But if the call would otherwise fail altogether, I'd like the option to make the call no matter what (ie, even if it ends up being cleartext).

Why would the call "otherwise fail altogether"?

> 
> (And since you're sitting in an Internet cafe in hearing distance of everyone, any sense of privacy is gone anyway. ;)
> 

Have you ever called into a conference call from a public place, with your microphone muted?

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

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

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

If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords.

>  The DTLS-SRTP may only reach the NAT-router in the Internet Cafe, for example, be terminated by it and a separate DTLS-SRTP between it and the bank.  And if I'm talking to an IVR system (as one frequently does with banks), there is no human to verify the keys/SAS with.

Correct. But there is a signaling channel, and if you trust it you can assure that there is no router doing MITM at the cafe. Perhaps you'll even be calling your bank's IVR using *their* calling service...

Matthew Kaufman