Re: [rtcweb] SRTP and "marketing"

[Randell Jesup <[e-mail]>]

On 3/29/2012 2:08 AM, Hadriel Kaplan wrote:
> On Mar 29, 2012, at 2:54 AM, Randell Jesup wrote:
>
>> That doesn't mean I don't want to implement a truly secure communications ability.  Note that by "secure" here I mean "I can detect if the service MITMd me" -- without reading cert phrases and preferably without having to install client certs and somehow build a working PKI.

>> One idea we've had is a non-centralized WebRTC service built on distributed hash tables and a partial-mesh set of connections used to pass signaling on WebRTC (or other) data channels to set up calls, with some type of Id system to validate who you get connected to (since you can't really trust any of the nodes fully).  If an intermediary node can downgrade you to SDES and sniff the keys, there is no security.
> If you use SDES, no one should be claiming you *have* end-to-end security.  You have security from the browser to the HTTPS server, but nothing more.  The browser shouldn't be showing a lock icon, for example (and it shouldn't for DTLS-SRTP either).  Since the media potentially goes into the PSTN, it can be no more secure than that.  No matter how much stronger we make the Browser-to-Gateway link, the end-to-end can't exceed the PSTN's level of security.  It's reasonably sufficient security for everyday use, but it won't let you bypass the government.  And using DTLS-SRTP to a gateway won't either.  And arguably even using IdP won't if the government can force the IdP to lie.


Total agreement.  SDES cannot be touted as secure.  It's more secure 
against sniffers; that's all.

>> An alternative would be to allow a hybrid: SDES at the start of a call and rekey over to DTLS-SRTP after the call is connected.  If something blocks the DTLS connection it would be treated as a gateway-to-legacy/PSTN call (i.e. show no security, though it's secure against non-in-path attackers); if the DTLS connection is allowed, we can use it to rekey to DTLS-SRTP and to verify identity.
> Why bother?  I assume the concern is a bid-down.  Let's imagine we were dealing with a malicious website, and the website javascript removed DTLS-SRTP from SDP but put in SDES, so that browser believes it's talking to a gateway and uses SDES.  The malicious website now has your SRTP key and can decrypt your media, assuming it has some access to your media.  So you build a better browser and try an active check for DTLS-SRTP in the media plane regardless of SDP.  If your browser is popular, why wouldn't the malicious website just insert a DTLS-SRTP b2bua gateway, and still be able to listen in?

This allows avoiding a gateway ('burning gateway' argument) with PSTN 
calls while minimizing the risk of bid-down.  Note, correctly, that you 
need Identity+DTLS-SRTP to be secure against in-signaling-path attackers 
(providers or governments).  That's not of no benefit.  It's not of real 
benefit to J. Random Salesman, but even non-political people may worry 
about someone watching in more than they worry about listening in.  
(#include lawsuits over schools using laptop computers to take snapshots 
from student computers at home, etc, etc).

> As far as I can see, there is no bid-down issue created by adding SDES - it was already there.  It was already possible to insert a DTLS-SRTP B2BUA and be malicious.  Yes, we may have made it slightly cheaper to be malicious, but it was already possible.  The only thing that prevents a malicious website's DTLS-SRTP B2BUA from working is if then humans verify the fingerprints or having an IdP you can trust.  Even if you *do* verify the fingerprints and find they do NOT match, all you know is it went through one or more gateways in the middle - you don't know it's malicious - it could just be going through the PSTN legitimately.

Video doesn't go through the PSTN...  That's a kinda obvious downgrade.  
And only people who care will note the insecurity; part of why it must 
be dead-simple but not overly intrusive (no doorhangers, etc).  This is 
W3C land though, mostly.  This just comes back to the argument over 
whether users care.  Some do, and most of them are non-technical.  
Identity doesn't provide perfect security.  It does provide better 
security and at least makes any tapper be concerned that they're raising 
red flags, if the person notices/cares.  I guarantee the Tunisian 
rebels/activists mentioned by Tim would care.


> With SDES the browser can indicate right-off-the-bat that the call is not end-to-end secure, without having to show the fingerprint and having the user read it out.

True :-)

>> This minimizes the risk of bid-down - the primary additional risk is that without initial SDES, to tap the signal you'd need to use a WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it off.  Also, a "good" gateway in a pure DTLS-SRTP world might have a identity established ("[e-mail]"); with SDES it wouldn't by default (but it could if it wanted to by rekeying via DTLS also).
> Yeah I've been trying to figure out if there's some advantage to having a gateway be able to indicate "[e-mail]", once there is an IdP model.  I would think it's a major pita to deploy such a thing on gateways, unless there's a very popular IdP they could know everyone would trust.  It would actually be easier to just give the gateway a real TLS cert for DTLS to use, from a major CA, since gateways are the types of systems real certs would be reasonably possible to install on.
>
>
>> I'm still strongly in favor of pure DTLS-SRTP - as Harald and others say, less moving parts and less things that need to be secured.  But this might be a useful compromise if we *need* to support SDES in some cases.
> I'm trying to be convinced that DTLS-SRTP is worth the complexity, cost and downsides on the gateways, but I haven't found it yet.  I think people are willing to be convinced, myself included, but I have yet to hear a real advantage for DTLS-SRTP in the gateway scenario.  Everything put forward today for DTLS-SRTP applied to the browser-to-browser scenarios, but not gateways.

Whereas I come at it from "I care about browser-to-browser cases and 
avoiding doing something that hurts them, and I don't care about 
security (other than sniffers) for gateway calls".  :-)



-- 
Randell Jesup
[e-mail]