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

Richard Barnes <> Thu, 20 June 2013 00:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 193AF21F9EDA for <>; Wed, 19 Jun 2013 17:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.657
X-Spam-Level: *
X-Spam-Status: No, score=1.657 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 5UmNso3vPRwY for <>; Wed, 19 Jun 2013 17:58:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22b]) by (Postfix) with ESMTP id E1FBB21F9EBC for <>; Wed, 19 Jun 2013 17:58:33 -0700 (PDT)
Received: by with SMTP id b10so4586690vea.2 for <>; Wed, 19 Jun 2013 17:58:32 -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=Q7wQrWWilhIcnl9OtR4OcT3LE05W+UlurDD+U5ak0C4=; b=J36GRQoG1zuHyhogQdx3T1oICzYjPF0W/1lInxeAyX9RoHZXqBoXW4q9wKybwoTRqO vA4jh4NRZLmq6FoYTJ0zcjxilOet1vz/94GcEh8unURcS4bqT3gNgbDPpYqrJ0TZLQSq 8DdeJx4t0rwNb2Z1ZEPTDUzU2vvGJWxWWk3bCgvp8hez5xSmJYEojvZJ9/YMaXs4vZB9 o4U4p5ITCNGlD1NkNssE95B+bBqtgYZiFjTPaJ8dZYoCEET7DgGxL1EyOKXAQoZqQdjs KegQoblBgNnAkCCSbCDWqYaZWqnhvKPiExTJ6nOkB1qlQ5kiQ4se5ICm1Wl49LCFoFaf kwBg==
MIME-Version: 1.0
X-Received: by with SMTP id d17mr1538634vdj.74.1371689912507; Wed, 19 Jun 2013 17:58:32 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jun 2013 17:58:32 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Wed, 19 Jun 2013 20:58:32 -0400
Message-ID: <>
From: Richard Barnes <>
To: "Matthew Kaufman (SKYPE)" <>
Content-Type: multipart/alternative; boundary=20cf307cfc40fa331e04df8b7173
X-Gm-Message-State: ALoCoQl6q7G/HJZKzP/iFB6+arfgSff7/VDjhKHqJHiukHLUl+fKWsq2UKLzFshxPm2q3eD1Ebkr
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 00:58:38 -0000

I think we still disagree on the scenario.  I've tried to sketch out the
full sequence of operations to be clear.  (WebSequenceDiagrams source

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

alt SDES Scenario

App->Browser: Create offer
Browser->App: SDP+SDES (with key)
App->WebServer: SDP+SDES
WebServer->PBX: SDP+SDES
PBX->WebServer: SDP+SDES
WebServer->App: SDP+SDES
App->Browser: Set remote answer (with key)
Browser->Callee: SRTP

else DTLS-SRTP Scenario

App->Browser: Create offer
Browser->App: SDP+DTLS-SRTP (no key)
App->WebServer: SDP+DTLS-SRTP
WebServer->App: SDP+DTLS-SRTP
App->Browser: Set remote answer (no key)
Browser->PBX: DTLS
PBX->Browser: EKT
Browser->PBX: SRTP
PBX->Callee: SRTP


On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman (SKYPE) <> wrote:

>  So lets assume the case where I have a web server that is talking to my
> browser *and* generating SIP traffic to talk to your SDES-capable (and
> ICE-capable) PBX.
>  And assume that your PBX initiated the call and picked the keying.
>  So in the EKT case we have (for key flow):
>  your PBX -(SDES in SIP)-> my server -(SDES in JSON in HTTPS)-> browser
> -(EKT)-> a media relay i now need to run
> (for media):
>  browser <--(key that was received over HTTPS and then sent using EKT)-->
> media relay <--(key that was received via SDES)--> your pbx
>  but in the SDES case we have (for key flow):
>  your PBX -(SDES in SIP)-> my server -(SDES in SDP in HTTPS)-> browser
> (and that's it, because I don't need a media relay in path any more)
> (for media):
>  browser <--(key that was received over HTTPS at the browser, SDES in SDP
> on SIP side)--> your pbx
>  Your diagram is missing the part where the browser either learns the key
> that it is supposed to ask EKT to set or tells your SIP/SDES side what key
> it set using EKT. Either way, those keys go over HTTPS to/from the browser,
> yes?
>  Matthew Kaufman
>  ------------------------------
> *From:* Richard Barnes []
> *Sent:* Tuesday, June 18, 2013 12:32 PM
> *To:* Matthew Kaufman (SKYPE)
> *Cc:* Magnus Westerlund; Hadriel Kaplan;
> *Subject:* Re: [rtcweb] No Interim on SDES at this juncture
>   On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <
>> wrote:
>> Back on April 25th, I made some claims. I still believe these are true:
>> 1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is
>> just a different encrypted channel over which the key is set.
>  Could you explain this in a little more detail?  I agree that the COMSEC
> properties are the same, but it seems like the communicating parties are
> different.
>  DTLS-SRTP+EKT:  Browser ---(EKT)---> Gateway ---(SDES)---> Endpoint
> SDES+HTTPS: Browser ---(HTTPS)---> Server ---(???)---> Gateway
> ---(SDES)---> Endpoint
>  That is, in the DTLS-SRTP+EKT case, the key never traverses the server.
>  Does your argument require that the server and the gateway be equally
> trusted?  (For example, because the server can choose the gateway.)  It
> doesn't seem like this is necessarily true in the general case.
>  --Richard
>> 2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for
>> interworking (as it needs to be in-path for the keying on that side,
>> despite the use of SDES on the other side).
>> 3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other
>> side of the interworking relationship anyway, so even though there isn't
>> SDES to the browser there's SDES on the other (likely SIP) side.
>> 4. And DTLS-SRTP without EKT fails completely for the cases where the key
>> needs to be set for interworking.
>> 5. And finally, to get the browser-to-browser security guarantees you
>> would need to be A) sure that you're really talking browser to browser and
>> not via something else in path (like a mixer) and B) would really prefer
>> that there be no way that the in-path device be able to force a key (thus
>> you'd want to NOT allow EKT in the browser-to-browser case, even though
>> there's no way for a browser to know for sure what it is talking to... I
>> suppose that *if* you trusted your browser and the browser at the other end
>> (which you need to do anyway, because they could just leak keys or media),
>> you could mandate that browsers set some bit that disallows EKT and hope
>> that the other end respects it)
>> Since we can't get interworking at all without either DTLS-SRTP + EKT or
>> SDES, and since the security guarantees of DTLS-SRTP + EKT are the same as
>> those of SDES, and since the interworking gateway is made more complex
>> (because the keying must be in-path), I believe the only possible
>> conclusions are A) We accept that interworking with other SRTP systems is
>> desirable and therefore SDES is the best way to achieve that or B) We
>> prevent any interworking with other RTP or SRTP systems.
>> As someone who could make some money sending traffic to/from non-RTCWEB
>> networks, I'm a fan of "A".
>> And no, I'm not planning on writing a draft that says to just do what we
>> should be doing anyway.
>> Matthew Kaufman
>> ________________________________________
>> From: [] on behalf of
>> Magnus Westerlund []
>> Sent: Tuesday, June 18, 2013 2:56 AM
>> To: Hadriel Kaplan
>> Cc:
>> Subject: Re: [rtcweb] No Interim on SDES at this juncture
>>  Hadirel and WG,
>> Please see my response inline.
>> On 2013-06-14 18:58, Hadriel Kaplan wrote:
>> > You can't be serious. There was exactly ONE email asking for agenda
>> > items, here:
>> > It
>> > was sent on May 30th.  It gave a generous 6 days to respond.  Luckily
>> > no one ever goes on vacation for longer than 5 days. Instead, two
>> > people sent a response on June 10th, a tremendous 11 days after the
>> > request.  Outrageous!  That's a almost twice as long as they were
>> > given!
>> >
>> > Thank goodness the chairs detected this monstrous breach of
>> > procedure, and thwarted the attempts of anarchy!  I mean if people
>> > are allowed to respond to emails so tardily, how can we be expected
>> > to get things accomplished as quickly as they've so far been in this
>> > WG?!?
>> Yes, we have only sent a single email this time, being the second round
>> in a short time we tried to schedule this meeting.
>> >
>> > Sure, an interim for this topic has been waiting for many months if
>> > not a whole year, and now that people didn't respond in 6 days but
>> > took instead 11 days the topic will be delayed indefinitely yet
>> > again... but that's no excuse for blatantly flaunting the rules!
>> Yes, there has been difficult finding a time could work for this
>> meeting. That was why the agenda request time was short.
>> >
>> > Personally I saw the email on May 30th, and assumed Oscar and Dan
>> > would respond to you for agenda time.  I assumed that if no one had
>> > submitted agenda items to you, that the WG Chairs would send out an
>> > email warning about that, or perhaps even directly email the people
>> > who they expected to submit agenda items.
>> >
>> Yes, you assumed that someone would respond. Rather than you reaching
>> out to verify that others would drive the question for you. Hadriel you
>> are apparently very interested in this topic. Why don't you ensure that
>> an agenda topic is on the agenda for Berlin? The WG chairs are happy to
>> receive agenda requests already now.
>> >
>> >> If you want to discuss this, write a draft describing how how your
>> >> additional keying is to be integrated, what the pro and cons of it.
>> >> That will enable direct discussion of a proposal. The WG clearly
>> >> are opinionated on this matter, but apparently don't have energy to
>> >> produce proposals.
>> >
>> > There *are* drafts.
>> >
>> > There
>> > are even powerpoint slides, sent to the chairs the last time this
>> > meeting almost happened but didn't.
>> One of those drafts has been expired since February I would like to
>> point out.
>> The looking at these drafts, they are neither a proposal for what to
>> actually do. Dan Wing's draft is argument in general why SDES would be
>> bad for security. Oscar Ohlsson's is an argument for why a number of
>> potential risks are not a serious issue and what the other gains of
>> using security descriptions are.
>> From my perspective I really would like to see some progress in at least
>> the proposal for actually adding additional keying to ensure that the
>> raised issues in drafts or earlier WG meetings and email discussions are
>> meet. Additionally I would really like to see some more details for how
>> the actual integration of an additional keying mechanism is supposed to
>> work.
>> >
>> > I think the problem must be that those things weren't signed in
>> > triplicate, sent in, sent back, queried, lost, found, subjected to
>> > public enquiry, lost again, and finally buried in soft peat for three
>> > months and recycled as firelighters.
>> No, that is not it. This topic has dragged on for various reasons. Yes
>> we chairs are clearly to blame for some of them, like being slow to
>> attempt to schedule a meeting. However, after that there has been issues
>> finding a suitable time where sufficient mass of people could
>> participate. There has been time conflicts with other meetings resulting
>> in a cancellation, which in hind sight was unnecessary. Then a
>> rescheduling, lurk warm response from the WG, limited agenda items and
>> another almost collision resulting another cancellation.
>> I am sorry that this makes you frustrated. Well, it makes also me
>> frustrated. I wished this topic was dealt with and out of the way, but
>> it is not. So, if you want it dealt with. Please request agenda time for
>> Berlin and ensure to update any drafts or other material to actually
>> take into account what actually has happened in the last 15 months.
>> Regards
>> Magnus Westerlund
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto:
>> ----------------------------------------------------------------------
>> _______________________________________________
>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list