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

Richard Barnes <rlb@ipv.sx> Thu, 20 June 2013 00:58 UTC

Return-Path: <rlb@ipv.sx>
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 193AF21F9EDA for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 17:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UmNso3vPRwY for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 17:58:34 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBB21F9EBC for <rtcweb@ietf.org>; Wed, 19 Jun 2013 17:58:33 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id b10so4586690vea.2 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 17:58:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.52.35.17 with SMTP id d17mr1538634vdj.74.1371689912507; Wed, 19 Jun 2013 17:58:32 -0700 (PDT)
Received: by 10.58.73.195 with HTTP; Wed, 19 Jun 2013 17:58:32 -0700 (PDT)
X-Originating-IP: [108.18.40.68]
In-Reply-To: <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8@TK5EX14MBXC273.redmond.corp.microsoft.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C78AD@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgTFSbYSX7v3q37tsjzaPMshyyBroGWr=qmy-HGm82GJFg@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8@TK5EX14MBXC273.redmond.corp.microsoft.com>
Date: Wed, 19 Jun 2013 20:58:32 -0400
Message-ID: <CAL02cgQMkHu-NqEeScT2ObfknJ+3OjXi7Y=7rUJtqeu3CbewMQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=20cf307cfc40fa331e04df8b7173
X-Gm-Message-State: ALoCoQl6q7G/HJZKzP/iFB6+arfgSff7/VDjhKHqJHiukHLUl+fKWsq2UKLzFshxPm2q3eD1Ebkr
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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, 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
below.)
<http://goo.gl/uRi0W>

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.


-----BEGIN-WSD-----
alt SDES Scenario

App->Browser: Create offer
Browser->App: SDP+SDES (with key)
App->WebServer: SDP+SDES
WebServer->PBX: SDP+SDES
PBX->Callee: SDP+SDES
Callee->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->PBX: SDP+DTLS-SRTP
PBX->Callee: SDP+SDES/SIP
Callee->PBX: SDP+SDES/SIP
PBX->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

end
-----END-WSD-----


On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net> 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 [rlb@ipv.sx]
> *Sent:* Tuesday, June 18, 2013 12:32 PM
> *To:* Matthew Kaufman (SKYPE)
> *Cc:* Magnus Westerlund; Hadriel Kaplan; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] No Interim on SDES at this juncture
>
>   On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <
> matthew.kaufman@skype.net> 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: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of
>> Magnus Westerlund [magnus.westerlund@ericsson.com]
>> Sent: Tuesday, June 18, 2013 2:56 AM
>> To: Hadriel Kaplan
>> Cc: rtcweb@ietf.org
>> 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:
>> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html 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.
>> > http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
>> > http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 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: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>