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

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 2:17 AM, Hadriel Kaplan wrote:

> 
> Well gee that doesn't sound like too hard a choice set to choose from, though I guess it depends on whether there's a requirement/desire to interop with existing VoIP devices and the PSTN, or not.

There is a requirement to interop with existing VoIP devices and the PSTN, however other requirements (like ICE for consent to send media) will impose additional requirements that limit which existing VoIP devices are or can be made compatible.

> 
> If we don't expect/desire RTCWEB clients to communicate with existing VoIP devices or PSTN, then sure we can start with a clean slate.

There is a desire for the media to be transported in RTP for a variety of reasons, including the ability to easily terminate the traffic in PSTN gateways, reuse of existing RTP stacks for building both browsers and interoperable devices, and middlebox awareness of what the traffic might be.

>  In fact, you could also create a whole new version of SIP for inter-server, since there's no need to use SIP v2.0 between RTCWEB domains and we've learned things we could have done better, and for a pure inter-domain server-to-server signaling protocol it could be a lot simpler. 
> 

You could. In fact, for inter-domain federation you are probably free to use whatever you and the other domain agree to use.

However, again for software reuse reasons, you're likely to pick SIP.

> But anyway... with regards to your alternatives below, you seem to imply that using DTLS-SRTP is by itself "secure", such that the UI could display a lock-icon for example.  I was under the impression that DTLS-SRTP provided no guarantee of anything without the humans on both ends verifying they're using the same keying material/SAS/etc.  Is that not the case? (okay yes it requires being a MitM to subvert, but that's not a high enough bar to claim anything)

Plain RTP - can be intercepted by both MitM attackers and passive observers. No perfect forward secrecy (in fact, no secrecy at all). 

SRTP w/SDES-style keying - both MitM attackers and passive observers can record the traffic but not play it out until they obtain key. The key is provided by the server and is likely recorded in server logs. Protection of the key on the wire requires HTTPS or similar signaling. Impossible to provide perfect forward secrecy.

DTLS-SRTP (or any other end-to-end keying) - assuming the use of DH key agreement, both MitM attackers and passive observers can record the traffic, however ONLY MitM attackers are able to participate in the key agreement algorithm, and so ONLY MitM attackers would ever be able to play out the contents. The key agreement occurs between the two endpoints (assuming no MitM attacker, of course) and is not recorded anywhere else and is not available to the signaling server. Provides perfect forward secrecy. MitM attacks be avoided if you trust the signaling service and exchange fingerprints between the two ends for authentication OR if you use a user interface that lets you examine the fingerprints and verify them out-of-band OR if you use additional software that you trust (along with a 3rd party that you trust) to examine the fingerprints automatically and alert you in the case of mismatch.

All of these statements of course only apply between you and whatever is terminating the session. If it is a gateway to another protocol, the security provided stops at that point and is only continued if the far end of the gateway is also secure *and* you trust both that security and the gateway.



> 
> Assuming that's true, and given how few humans would actually know to perform manual verification of dtls-srtp, I think this topic isn't as cut-and-dried as choosing between "secure" vs. "insecure".  Both alternatives are capable of being secure or insecure, and it's up to the human to do something to figure it out in either case.  There is no real alternative which is inherently "secure", afaict.

There are gradations of security that are provided by default, depending on the choices made.

If the browser is able to send plain RTP at all, then you need a way for the user to tell if it is sending plain RTP or encrypted RTP. If it can only send encrypted RTP, then this requirement goes away. For some threat models (for instance passive observers watching your unencrypted wifi traffic), any encryption at all is better than plain RTP. For others (passive observers that can record the traffic and also have future access to the server logs), encryption + end-to-end keying is far superior to any of the other choices.

But, like all security arguments, you are correct. It is never black and white, so you can never say "this is secure". But you can certainly say "this ISN'T secure" for some of them (like plain RTP, or even the ability for the browser to switch you from SRTP to RTP without making it clear to the user).

Think of the threat models you are likely to experience yourself... then tell me which level of protection YOU want.

Matthew Kaufman