Re: [rtcweb] SRTP and "marketing"

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 29 March 2012 10:26 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF7121F89CE for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 03:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j-PjlMEu1J7 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 03:26:13 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25E1421F89BD for <rtcweb@ietf.org>; Thu, 29 Mar 2012 03:26:13 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Mar 2012 06:26:08 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 02:08:30 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Randell Jesup <randell-ietf@jesup.org>
Thread-Topic: [rtcweb] SRTP and "marketing"
Thread-Index: AQHNDXJcDpOwIC7VUECfiGAXLr857A==
Date: Thu, 29 Mar 2012 06:08:29 +0000
Message-ID: <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com>
References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org>
In-Reply-To: <4F73B2B6.9080008@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D51E56187AB1054ABFF1762497517175@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SRTP and "marketing"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 10:26:14 -0000

On Mar 29, 2012, at 2:54 AM, Randell Jesup wrote:

>>   No one is concerned about that.
> 
> Define "no one" :-)

There are Billions of people on the planet.  Obviously I don't mean the number who don't care is 0. :)


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


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

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.

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.


> 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 ("gateway@L3.com"); 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 "gateway@telco.com", 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.  

-hadriel