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

[Richard Barnes <[e-mail]>]

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) <
[e-mail]> 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 [[e-mail]]
> *Sent:* Tuesday, June 18, 2013 12:32 PM
> *To:* Matthew Kaufman (SKYPE)
> *Cc:* Magnus Westerlund; Hadriel Kaplan; [e-mail]
>
> *Subject:* Re: [rtcweb] No Interim on SDES at this juncture
>
>   On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <
> [e-mail]> 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: [e-mail] [[e-mail]] on behalf of
>> Magnus Westerlund [[e-mail]]
>> Sent: Tuesday, June 18, 2013 2:56 AM
>> To: Hadriel Kaplan
>> Cc: [e-mail]
>> 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  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>