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

"Hutton, Andrew" <> Thu, 20 June 2013 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BDE321F9F49 for <>; Thu, 20 Jun 2013 13:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PjfrXM557Qcf for <>; Thu, 20 Jun 2013 13:52:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 872F511E80D3 for <>; Thu, 20 Jun 2013 13:52:49 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id 999E723F0469; Thu, 20 Jun 2013 22:52:48 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 22:52:48 +0200
From: "Hutton, Andrew" <>
To: Hadriel Kaplan <>, Richard Barnes <>
Thread-Topic: [rtcweb] No Interim on SDES at this juncture
Thread-Index: AQHObVFVBYzpHvj1BUGlhj09l8oaqpk+DoOAgAEDiyA=
Date: Thu, 20 Jun 2013 20:52:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 20:52:55 -0000

Agree with Hadriel here I so no additional security benefit for EKT given that any media gateway is going to be in cahoots with the webserver and has access to the key.

So all we are left with is the performance benefit of using SDES support in the browser which is significant and reduces the barrier to deploying WebRTC so let's go for the option that is easy to specify, easy to deploy, cheap to implement (already exists in Chrome), and we are all familiar with.

SDES support looks like the obvious choice.


> -----Original Message-----
> From: [] On
> Behalf Of Hadriel Kaplan
> Sent: 20 June 2013 08:11
> To: Richard Barnes
> Cc:
> Subject: Re: [rtcweb] No Interim on SDES at this juncture
> 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?
> 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
> _______________________________________________
> rtcweb mailing list