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

Richard Barnes <> Thu, 20 June 2013 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9F1921F9E39 for <>; Thu, 20 Jun 2013 15:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.375
X-Spam-Level: *
X-Spam-Status: No, score=1.375 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKH8YvjTcIfT for <>; Thu, 20 Jun 2013 15:24:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::22f]) by (Postfix) with ESMTP id D756221F9DF7 for <>; Thu, 20 Jun 2013 15:24:14 -0700 (PDT)
Received: by with SMTP id m1so8488652oag.6 for <>; Thu, 20 Jun 2013 15:24:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uyIJ+xKil9oDtGYhVLf7TDXJuxrclUiixZ7FMUD/LFg=; b=NtwILv10OK+GBx7B7Af6xzcLdBHjvCCuXtBrN6tb2GKhlUDg0JDIUmZucZQUUUWm4p 1ZOLNQssHpDButA6JYg8z5NuR45i7O4fkk5PyuUoOWknjtQqXYxvjz+KOS9yu/yLGkO2 4/hxhFuEnL7eGMc91Aaulk9q+oXY8v/BPvlBm+EbQmF+V4UpGnKZzXMzgJ2jqj9qBQ5A m4P5mYJtaXd07nxJkewDmmDKOOXvaRM4CDdxs7rSWGt73HFlI50GMNPKkKwV7hGZBj6s Ulu4Phxfvz5w4WDgsCpLi5jIScMHFPLN0lZYWPeC+H4hUv39A1o25YvFbps940pMWsZx XOFg==
MIME-Version: 1.0
X-Received: by with SMTP id t10mr5357348oei.2.1371767043831; Thu, 20 Jun 2013 15:24:03 -0700 (PDT)
Received: by with HTTP; Thu, 20 Jun 2013 15:24:03 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 20 Jun 2013 18:24:03 -0400
Message-ID: <>
From: Richard Barnes <>
To: Hadriel Kaplan <>
Content-Type: multipart/alternative; boundary=089e013c66b45cca0104df9d6775
X-Gm-Message-State: ALoCoQnOQXEPcTXwRf0vDK7URMJP7TIl8P2lOerDps64qSri6P+uUMq7jepWsQdaFjuX1OamUXvf
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: Thu, 20 Jun 2013 22:24:39 -0000

On Thu, Jun 20, 2013 at 3:11 AM, Hadriel Kaplan

> On Jun 19, 2013, at 8:58 PM, Richard Barnes <> wrote:
> > I think we still disagree on the scenario.  I've tried to sketch out the
> full sequence of operations to be clear.  (WebSequenceDiagrams source
> below.)
> > <>
> >
> > ISTM that there are two major differences:
> > -- In the SDES case, the JS and the Web Server both have access to the
> media keys.  In the EKT case, the browser handles the keying update
> directly.
> > -- In the EKT case, the PBX/gateway has to be in the media path to do
> EKT.  After EKT, it just switches packets (it's basically a TURN server).
> >
> > So it seems like a security benefit for EKT and a performance benefit
> for SDES.  Your quantitative valuation of these benefits / costs may vary.
> I'm confused.  EKT has "a security benefit" for whom, exactly?
> It's not more secure for the browser user, since a malicious web server
> can simply *be* the PBX, terminate DTLS-EKT and get the key and the browser
> user would never know it.
> It's not more secure for the SIP user, since the SIP user is only doing
> SDES and has no idea what's happening on the far-end.
> Who are you saying is being better protected from what?

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.

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.

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


> I suppose we could claim the owner of the PBX feels more secure, if
> they're not the same as the owner of the web-server and don't trust the
> web-server.  But again, if the web-server owner is malicious it will just
> terminate the media pretending to be the PBX on one side, and pretending to
> be the browser to the real PBX on the other side.  And why would a PBX
> owner accept calls from a web-server it doesn't trust to begin with?
> Afaict, the main security benefit of DTLS-EKT is the same as that of
> DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't be
> sniffed even if cleartext HTTP is used.  So in a weird way, the security
> benefit of it is it let's us use an insecure HTTP transport for the
> JSON/SDP/HTML/whatever.  Luckily the ability to see and modify what goes on
> there is no big deal... like for example be able to insert a malicious
> DTLS-SRTP B2BUA that records everything.  Oh, wait...
> -hadriel