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

On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <
andrew.hutton@siemens-enterprise.com> wrote:

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

See my reply to Hadriel on XSS and bid-down attacks.

> 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.
>
> Regards
> Andy
>
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Hadriel Kaplan
> > Sent: 20 June 2013 08:11
> > To: Richard Barnes
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] No Interim on SDES at this juncture
> >
> >
> > On Jun 19, 2013, at 8:58 PM, Richard Barnes <rlb@ipv.sx> 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.)
> > > <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.
> >
> > 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
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>