Re: [rtcweb] No Interim on SDES at this juncture

Hadriel Kaplan <> Fri, 21 June 2013 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1196D21E80F8 for <>; Thu, 20 Jun 2013 18:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.553
X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5wyFjKBJMzzu for <>; Thu, 20 Jun 2013 18:11:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CD6321E80E6 for <>; Thu, 20 Jun 2013 18:11:32 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L1BSc3009461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 01:11:29 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L1BRPw023590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 01:11:27 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L1BRFf004736; Fri, 21 Jun 2013 01:11:27 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 18:11:26 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <>
In-Reply-To: <>
Date: Thu, 20 Jun 2013 21:11:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Richard Barnes <>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: []
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jun 2013 01:11:52 -0000

On Jun 20, 2013, at 6:24 PM, Richard Barnes <> wrote:

> It's more secure in the sense that it makes a malicious web server do more work: It forces the web server to act as the PBX and terminate DTLS, instead of just pulling the key out of the SDP and decrypting media.  So the browser user is (incrementally) better protected against the malicious web server.

Uh huh.  So, like, the only people who could afford to do that and would want to do that would be criminals, drug dealers, mobsters, casinos, news organizations, political parties, and governments then?  Phew!  And here I was being worried.

But wait a minute... I was under the distinct impression from people in this group that doing DTLS-SRTP termination on the gateways was no big deal for "modern" servers... that it was so cheap and trivial that your cell phone could do it for umpteen streams... that we shouldn't be worried about the overhead of it whatsoever.  Surely you can't be telling me that it's at all difficult for someone running a malicious web site to do it?!?

> It's more secure in the sense that JS can't access the key, so an injected script can't grab the key and exfiltrate it.  So the browser user is better protected against XSS risks.

This part I'd like to understand better.  Can you explain it?  
If a Browser cannot determine what server the JS being executed for WebRTC API calls/callbacks came from, or cannot tell if it came from one over HTTPS in particular, then using SDES might be a real problem.  I was under the impression browsers did know those things (or at least that they're theoretically supposed to, ignoring that  there are "bugs" here and there).

> It's more secure in the sense that SDES has no end-to-end authentication [1], so implementing SDES creates bid-down attacks.  If an attacker can't get a valid identity, he just claims not to support DTLS-SRTP.  So the browser user is better protected against bid-down attacks by remote users (e.g., the malicious web server's PBX).

This is just another symptom of talking to a malicious web server, and basically a repeat of the argument that DTLS-EKT is "more secure" because a malicious web server has to do a little more work to steal everything.  It's like being stuck in a big cage with a man-eating lion and deciding to run around in circles in the hopes the lion isn't going to chase you.  If he's hungry at all, you're dead; chasing you down is not sufficiently more difficult for him to stay hungry.