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

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Jun 2013 08:55:04 -0700

Howdy,

The chairs apologize for the delay in announcing; as Cullen noted, we are
evenly split 8 hours apart at the moment, which is making coordination
difficult.  As it stands, we got two direct proposals for the interim, one
proposing a summary and one a comparison, both asking for 15 minutes of
time.   As it happens, both also arrived after the original deadline for
discussion.  That seems to us as chairs to indicate that this isn't the
highest priority on the working groups mind at this point, and that
spinning up an interim to discuss it might distract from the ongoing work
on dependencies in MMUSIC.

Working group discussion on the point, and documents addressing it, are
welcome at this point, if folks do want to re-open the topic in this
venue.  We may also allocate time in Berlin, depending on the other agenda
items.

regards,

Ted Hardie, for the chairs.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 22:25:19 -0400

Oh excellent, then it's a "No Plan" for SRTP as well.  Cool.
I don't expect there to be time in Berlin for it either, since I expect that time to be dedicated to choosing an MTI Video Codec.

-hadriel

On Jun 11, 2013, at 11:55 AM, Ted Hardie <[email-masked]> wrote:

> Howdy,
> 
> The chairs apologize for the delay in announcing; as Cullen noted, we are evenly split 8 hours apart at the moment, which is making coordination difficult.  As it stands, we got two direct proposals for the interim, one proposing a summary and one a comparison, both asking for 15 minutes of time.   As it happens, both also arrived after the original deadline for discussion.  That seems to us as chairs to indicate that this isn't the highest priority on the working groups mind at this point, and that spinning up an interim to discuss it might distract from the ongoing work on dependencies in MMUSIC.  
> 
> Working group discussion on the point, and documents addressing it, are welcome at this point, if folks do want to re-open the topic in this venue.  We may also allocate time in Berlin, depending on the other agenda items.
> 
> regards,
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Jun 2013 22:52:55 -0700

> I don't expect there to be time in Berlin for it either, since I expect that time to be dedicated to choosing an MTI Video Codec.

[BA] I can think of many better things to spend time on than the MTI issue.  To quote from another famous "plan":You are interested in the unknown, the mysterious, the unexplainable. That is why you are here.
http://en.wikiquote.org/wiki/Plan_9_from_Outer_Space

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Jun 2013 16:58:42 +0900

> I don't expect there to be time in Berlin for it either, since I expect that time to be dedicated to choosing an MTI Video Codec.

I doubt the MTI codec issue will be discussed in Berlin because several people have expressed the thought that the outcome of Nokia vs HTC / Google trial over VP8 will change their opinion so it seem we will wait yet some more for this information to become available.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 11:09:11 -0400

I was being sarcastic.  The previous two IETF meeting agenda times were ostensibly too full to have the SDES discussion due to the MTI video codec discussion.  Instead we spent the time talking about IdP, which is a possible future need, rather than a current actual interoperability issue - which is what SRTP key exchange actually is.  At the last Sipit, one of the only interop issues found was incompatible SRTP key exchange.

Hopefully there will be some standards-developing organization (SDO) out there that is responsible for media-plane interoperability of WebRTC hosts that can tackle the problem.  So far I've only found two SDOs that both seem to focus on browser APIs and what goes in HTTP.

-hadriel

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Jun 2013 08:38:57 -0700

> Oh excellent, then it's a "No Plan" for SRTP as well.  Cool.

Hi Hadriel,

Actually this isn't correct.  The plan of record for this is DTLS/SRTP:

Once the DTLS handshake has completed, the keys are exported [RFC5705
<http://tools.ietf.org/html/rfc5705>]
and used to key SRTP for the media channels.

If you think that plan isn't clear enough in the security architecture and
security documents,
suggested text would be welcome.  The point of an SDES discussion wasn't to
create an
initial plan, in other words, or event to discuss changing the existing
plan, but to consider
whether other options were to be included.

> I don't expect there to be time in Berlin for it either, since I expect
> that time to be dedicated to choosing an MTI Video Codec.
>
>
We haven't set an agenda for Berlin, but the obvious thing to do here is
not to wait, but to kick of the discussion on the list with a draft
proposing what you want to see; or, as I said below "Working group
discussion on the point, and documents addressing it, are welcome at this
point, if folks do want to re-open the topic in this venue. "

best regards,

Ted

> > The chairs apologize for the delay in announcing; as Cullen noted, we
> are evenly split 8 hours apart at the moment, which is making coordination
> welcome at this point, if folks do want to re-open the topic in this venue.
>  We may also allocate time in Berlin, depending on the other agenda items.
> >
> > regards,
> >

---

From: "Vijaya Mandava (vimandav)" <[email-masked]>
Date: Wed, 12 Jun 2013 16:20:51 +0000

I absolutely agree. we need to find a solution to the incompatible SRTP
key exchange.

Thanks,
Vijaya

On 6/12/13 11:09 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Instead we spent the time talking about IdP, which is a possible future
>need, rather than a current actual interoperability issue - which is what
>SRTP key exchange actually is.  At the last Sipit, one of the only
>interop issues found was incompatible SRTP key exchange.
>
>Hopefully there will be some standards-developing organization (SDO) out
>there that is responsible for media-plane interoperability of WebRTC
>hosts that can tackle the problem.  So far I've only found two SDOs that
>both seem to focus on browser APIs and what goes in HTTP.
>
>-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 12:29:08 -0400

On Jun 12, 2013, at 11:38 AM, Ted Hardie <[email-masked]> wrote:

> On Tue, Jun 11, 2013 at 7:25 PM, Hadriel Kaplan <[email-masked]> wrote:
> 
> If you think that plan isn't clear enough in the security architecture and security documents, 
> suggested text would be welcome.  The point of an SDES discussion wasn't to create an 
> initial plan, in other words, or event to discuss changing the existing plan, but to consider 

What we had talked about back in IETF 83 (or some previous meeting) was whether DTLS-SRTP would be the only MTI key exchange, or whether SDES would also be MTI.
We did not come to consensus in IETF 83, and tabled it for more discussion.  Since then it has been put at the end of the agendas, resulting in us running out of time for it.  At the last IETF 86 or Boston interim, one of the WG Chairs (I don't remember who) said we'd have a virtual interim dedicated to cover it.  Now we don't.  Ergo, we don't have a plan.

> We haven't set an agenda for Berlin, but the obvious thing to do here is not to wait, but to kick of the discussion on the list with a draft proposing what you want to see; or, as I said below "Working group discussion on the point, and documents addressing it, are welcome at this point, if folks do want to re-open the topic in this venue. "

We've had a lot of discussions on the list about this over the past couple years.  I thought the general feeling was at this point we needed to discuss it live - either in person or on a con call - because it was hard to follow all the arguments in email.  Maybe that was just my feeling, but I could swear some other people said the same thing at the last IETF 86 meeting or Boston interim.

-hadriel

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Jun 2013 10:08:04 -0700

On 12 June 2013 09:29, Hadriel Kaplan <[email-masked]> wrote:
> We've had a lot of discussions on the list about this over the past couple
> years.  I thought the general feeling was at this point we needed to discuss
> it live - either in person or on a con call - because it was hard to follow
> all the arguments in email.  Maybe that was just my feeling, but I could
> swear some other people said the same thing at the last IETF 86 meeting or
> Boston interim.

That's consistent with my understanding.  This seems far less
contentious than the video MTI discussion, but continuously deferring
discussion hasn't helped.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 Jun 2013 10:56:28 +0000

Also agree with Hadriel and Martin here we seem to have been talking about an interim to discuss SDES for a long time and the IETF86 minutes stated that a virtual interim was the way forward. The last time we actually discussed this was at IETF83 about 15 months ago.

Personally I think we need to find a way to accommodate SDES in RTCWEB even if it requires some user authorization and/or indication in the browser regarding the risks. It is probably the primary interop issue that exists today regarding interop of WebRTC with the rest of the VoIP world.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Thomson
> Sent: 12 June 2013 18:08
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [rtcweb] No Interim on SDES at this juncture
>

---

From: Tim Panton <[email-masked]>
Date: Thu, 13 Jun 2013 12:07:37 +0100

I fear it just _looks_like_ the primary interop issue.

As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without
the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)
Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES.

The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay.

I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway.
Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.

Tim.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Jun 2013 14:59:48 +0200

> Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.

My impression from Paris was that if the WebRTC world supports EKT, then 
gatewaying into an SDES realm requires some fancy key-shuffling, nothing 
more.

If the WebRTC world does not support EKT, then decrypt/encrypt will work 
in all cases.
My impression from the performance numbers people have quoted is that 
the CPU cost of decrypt/encrypt doesn't cost enough to be the 
deal-breaker between "viable solution" and "not viable solution"; other 
things weigh far more on capex/opex.

The architectural/non-cost argument I see against decrypt/encrypt is 
"the gateway wants to be able to disclaim the ability to look at the bits".

Agree with Tim about the relative difficulty of adding the needed features.

---

From: Tim Panton <[email-masked]>
Date: Thu, 13 Jun 2013 16:30:45 +0100

On 13 Jun 2013, at 13:59, Harald Alvestrand wrote:

> 
> 
> The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits".

Which is implausible because it will probably have to have the DES keys to be able to decode RTCP at least.

I'm not sure how much implausible deniability is worth these days.

T.

---

From: Dan Wing <[email-masked]>
Date: Thu, 13 Jun 2013 12:14:27 -0700

>> the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)

It was my presentation at IETF83 in Paris.

> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.

Right -- EKT is what makes the flames go away.  Slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf shows the flames, and the flames go away when we add EKT on slide 33.

> 
> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.
> My impression from the performance numbers people have quoted is that the CPU cost of decrypt/encrypt doesn't cost enough to be the deal-breaker between "viable solution" and "not viable solution"; other things weigh far more on capex/opex.
> 

-d

---

From: Dan Wing <[email-masked]>
Date: Thu, 13 Jun 2013 12:14:30 -0700

> Which is implausible because it will probably have to have the DES keys to be able to decode RTCP at least.

RTCP is usually only authenticated (not encrypted), which is the recommendation of RFC3711 (SRTP).

-d

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jun 2013 12:47:42 -0700

> "the gateway wants to be able to disclaim the ability to look at the bits".

[BA] There are only a limited number of situations where it is possible to "disclaim the ability to look at the bits".  For example, a PSTN gateway, PBX connecting to a SIP trunk, a video compositor or an audio mixer need to access decrypted RTP packets in order to do their job.  What non-P2P scenarios are you imagining where that would be possible? 
 
> things weigh far more on capex/opex.
 
[BA] I believe it is correct to say that the CPU cost of SRTP encrypt/decrypt  is not the bottleneck in large membership conferences (a good MCU implementation running on a high-end multicore server is likely to saturate a 1 Gbps NIC before CPU utilization becomes a factor).  Given that, I don't see that EKT will actually have that much impact, compared with other decisions about the key exchange -  whether PFS is required, key establishment algorithms and key sizes, etc.  For example, see: 
http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Jun 2013 23:39:37 -0400

> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.

My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig".  In fact if I recall correctly it was you who said something along those lines in Paris. :)

> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.

Yup.

> My impression from the performance numbers people have quoted is that the CPU cost of decrypt/encrypt doesn't cost enough to be the deal-breaker between "viable solution" and "not viable solution";…

Yes, I also think that's true, that the cost/complexity overhead of decrypt/encrypt wouldn't break the viability.  It does cost more to do it, though, so if we can get away without having to do it (without truly sacrificing security) then it would be a good thing.  Things add up after all, both in processing cost and time.

But yes clearly it isn't as big a deal as having to transcode video, for example, which would not be viable.

> The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits".

I hadn't heard that one.  I'm not really sure how one could prove that anyway though, since SDES would certainly give the gateway the *ability* to look at the bits.  You would have to either check the code or believe the logs, and if you're willing to believe them then you might as well believe the code/logs that the gateway isn't storing/sampling the bits when it decrypts/encrypts.

> Agree with Tim about the relative difficulty of adding the needed features.

Afaict, adding SDES is trivial if you went to the trouble of doing DTLS-SRTP already.  The converse isn't true.

-hadriel

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Jun 2013 21:50:52 -0700

> My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig".  In fact if I recall correctly it was you who said someth…

Likewise.  I also wonder what the API surface for this feature needs
to look like.  Clearly, someone needs to decide to push new keys into
the session, but can that be the application: is this something that
would have an API in the browser?

(That's a serious question, BTW.  Comment 22 provided that interface,
because we wanted to support SDES and the same interface conveniently
applies to EKT, but that leads to some interesting issues with respect
to media security.)

As I see this issue, it's a not a matter of "do we need SDES in
addition to DTLS-SRTP", it's more a matter of "how do we solve the
my-MCU-is-on-fire problem", for which there are two proposals on the
table: SDES and EKT.  The latter has some issues with respect to
deployment, even if it has some merits from a security perspective.
There are other reasons that SDES is preferable to us, though those
might not be compelling to others, but I can't get over this central
issue.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jun 2013 09:43:56 +0200

On 2013-06-12 18:29, Hadriel Kaplan wrote:

> 
> What we had talked about back in IETF 83 (or some previous meeting) was
> whether DTLS-SRTP would be the only MTI key exchange, or whether SDES
> would also be MTI.
> We did not come to consensus in IETF 83, and tabled it for more
> discussion.  Since then it has been put at the end of the agendas,
> resulting in us running out of time for it.  At the last IETF 86 or
> Boston interim, one of the WG Chairs (I don't remember who) said we'd
> have a virtual interim dedicated to cover it.  Now we don't.  Ergo, we
> don't have a plan.

It was me that said we where going to schedule an interim meeting. Which
we chairs failed to to in the previous cycles between meetings which was
our bad.

However, this time we have proposed a time and requested people to
submit agenda items to that meeting. Don't hold us WG chairs responsible
because you in the WG aren't providing input into what should be discussed.

I see an tendency on the mailing list to shout "Security Descriptions is
important!". But, when we ask for people willing to provide a proposal
for how to integrate it, or even provide input into a discussion that
could reach a WG conclusion that Security Description or some other
additional keying than DTLS-SRTP is desired people goes silent.

Without proposals we chairs where not seeing reasons to hold this
interim meeting.

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.

Cheers

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: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jun 2013 07:53:49 +0000

Hi,

I agree with what Magnus says.

Also, in general, in order to get most out of meetings (virtual or physical), it is good to have mail discussions. I don't even remember the last time I saw an e-mail on this topic (until it was announced that the meeting won't be held, that is).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 14. kesäkuuta 2013 10:44
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [rtcweb] No Interim on SDES at this juncture

On 2013-06-12 18:29, Hadriel Kaplan wrote:

> 
> What we had talked about back in IETF 83 (or some previous meeting) 
> was whether DTLS-SRTP would be the only MTI key exchange, or whether 
> SDES would also be MTI.

It was me that said we where going to schedule an interim meeting. Which we chairs failed to to in the previous cycles between meetings which was our bad.

However, this time we have proposed a time and requested people to submit agenda items to that meeting. Don't hold us WG chairs responsible because you in the WG aren't providing input into what should be discussed.

I see an tendency on the mailing list to shout "Security Descriptions is important!". But, when we ask for people willing to provide a proposal for how to integrate it, or even provide input into a discussion that could reach a WG conclusion that Security Description or some other additional keying than DTLS-SRTP is desired people goes silent.

Without proposals we chairs where not seeing reasons to hold this interim meeting.

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.

Cheers

Magnus Westerlund

---

From: Tim Panton <[email-masked]>
Date: Fri, 14 Jun 2013 10:00:57 +0100

> Afaict, adding SDES is trivial if you went to the trouble of doing DTLS-SRTP already.  The converse isn't true.

If you add SDES to an existing DTLS-SRTP the key and crypto stuff is (relatively) trivial - 
but you are adding additional valid options and paths to the SDP -
making it even harder to validate and parsers even more entangled than before.

You can see that 2 ways:
	1) "SDP is always going to be a loosely defined option ridden pain to parse, thats what SIPit is for - to knock out the bugs"
	2) "SDP is a mess, we should be doing everything possible to simplify the subset we require in rtcWEB"

- I'm mostly in camp 2. Having spent more time on getting the SDP right than I did on the DTLS itself.

T.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Jun 2013 12:17:16 -0400

> Also, in general, in order to get most out of meetings (virtual or physical), it is good to have mail discussions. I don't even remember the last time I saw an e-mail on this topic (until it was an…

Doing a very rough search on my email client, the last time SDES was discussed was waaaaay back on May 10th, in this email:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg07460.html
Who can even remember what the Internet was like back then?

But more seriously, we had a LOT of emails about the topic last year.  There was agreement to discuss it in a meeting instead, because the discussion was too difficult for people to follow in email.  So why would people keep discussing it in email?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Jun 2013 12:58:53 -0400

> because you in the WG aren't providing input into what should be discussed.

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?!?

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!

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.

> opinionated on this matter, but apparently don't have energy to produce

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.

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. 

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Jun 2013 19:16:59 +0200

I just remember that somebody wrote a draft explaining why DTLS offers NO
more security than SDES. AFAIR the draft was just ignored. I'm also
surprised that there is no need to discuss this subject.

--
Iñaki Baz Castillo
<[email-masked]>
El 14/06/2013 18:59, "Hadriel Kaplan" <[email-masked]> escribió:

> 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?!?
>
> 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!
>
> 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.
>
>
> 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.
>
> -hadriel
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Jun 2013 10:21:21 -0700

On 14 June 2013 10:16, Iñaki Baz Castillo <[email-masked]> wrote:
> somebody wrote a draft explaining why DTLS offers NO more security than
> SDES. AFAIR the draft was just ignored.

If someone were to claim that the sky was green, ignoring the claim
would be a reasonable response.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jun 2013 20:12:47 +0000

Hi,

> But more seriously, we had a LOT of emails about the topic last year.  There was agreement to discuss it in a meeting instead, because the discussion was too difficult for people to follow in email…

Because that's what we do in IETF :)

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 16 Jun 2013 22:31:21 +0530

Hi all,

IIRC, SDES related presentation was supposed to be discussed during IETF-84
(https://datatracker.ietf.org/meeting/84/agenda/rtcweb/) as per the plan.
AFAIK, those presentation are not delivered so far. 

In case I missed the presentation, Please send the minutes of the meeting.

Thanks
Partha

> Behalf Of Hadriel Kaplan
> Sent: Friday, June 14, 2013 10:29 PM
> To: Magnus Westerlund
> Cc: [email-masked]
> 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.
> 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?!?
> 
> 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!
> 
> about that, or perhaps even directly email the people who they expected
> to submit agenda items.
> 
> 
> 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.
> 
> -hadriel
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 16 Jun 2013 20:34:15 +0200

> I hadn't heard that one.  I'm not really sure how one could prove that anyway though, since SDES would certainly give the gateway the *ability* to look at the bits.  You would have to either check…
I've heard Cullen mention it a number of times when talking about 
competitors of Cisco using WebEx for business planning.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jun 2013 11:56:56 +0200

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.

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2013 09:01:38 -0700

On 18 June 2013 02:56, Magnus Westerlund <[email-masked]> wrote:
> I would really like to see some more details for how

Why isn't RFC 4568 sufficient?  This worked perfectly well in the
versions of Chrome that I tested almost a year ago.  There's a little
specification work to do with respect to what a browser generates for
output and permits as input through the API, but that's true of
virtually all SDP parameters already, so this isn't particularly
special.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 19:02:22 +0000

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.

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: [email-masked] [[email-masked]] on behalf of Magnus Westerlund [[email-masked]]
Sent: Tuesday, June 18, 2013 2:56 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [rtcweb] No Interim on SDES at this juncture

Hadirel and WG,

Regards

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Jun 2013 15:32:01 -0400

On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> 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.
>
> 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.
>
> From: [email-masked] [[email-masked]] on behalf of
> Magnus Westerlund [[email-masked]]

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 21:16:38 +0000

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 [[email-masked]]
Sent: Tuesday, June 18, 2013 12:32 PM
To: Matthew Kaufman (SKYPE)
Cc: Magnus Westerlund; Hadriel Kaplan; [email-masked]
Subject: Re: [rtcweb] No Interim on SDES at this juncture

On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE) <[email-masked]<mailto:[email-masked]>> wrote:
Back on April 25th, I made some claims. I still believe these are true:

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

Matthew Kaufman

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Magnus Westerlund [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, June 18, 2013 2:56 AM
To: Hadriel Kaplan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] No Interim on SDES at this juncture

Hadirel and WG,

Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 21:20:04 +0000

"Either way, those keys go over HTTPS to/from the browser, yes?"... or worse, the keys are sent from my server to my media relay server over its own signaling channel and then *it* runs the EKT from its end. Either way, I've got the keys and I'm probably sending them over HTTPS... only in this case, to my gateway and not the browser.

But then the browser *still* gets the keys over a channel no more/less secure than HTTPS.

Matthew Kaufman

________________________________
From: [email-masked] [[email-masked]] on behalf of Matthew Kaufman (SKYPE) [[email-masked]]
Sent: Tuesday, June 18, 2013 2:16 PM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [rtcweb] No Interim on SDES at this juncture

Matthew Kaufman

--Richard

Matthew Kaufman

Hadirel and WG,

Regards

Magnus Westerlund

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Jun 2013 16:15:53 -0700

> Additionally I would really like to see some more details for how

[BA] Since both SDES and DTLS/SRTP (via the DtlsSrtpKeyAgreement constraint) are supported in Chrome at the moment, an example of how it would work is available in running code. 
 
Are you looking for a presentation on the implementation details?  Examples of the SDP that are used?

---

From: Michael Procter <[email-masked]>
Date: Wed, 19 Jun 2013 13:25:57 +0100

On 18 June 2013 22:16, Matthew Kaufman (SKYPE)
<[email-masked]> wrote:
> 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?

I don't understand this part of your argument.  I was under the impression that
using DTLS-EKT meant we could avoid having keying information visible to
Javascript in the browser whilst still interoperating with legacy SRTP UAs that
determine their own transmission keys.

In your example, I thought it would work like this:

your PBX <-(SDES in SIP)-> my sip server <-(??)-> my media relay
<-(DTLS-EKT)-> browser

The PBX chooses its transmission key, and advertises it through
SDES/SDP.  The browser chooses its transmission key and advertises it
through DTLS-EKT. The media gateway has the job of matching up the
SDES pieces with the EKT pieces, and thereafter forwarding packets.

Yes, there is some call control coordination to do between the web server
and the sip server/media relay, but no keying information needs to pass to
the web server, nor on to the Javascript running in the browser.

Have I missed a use-case?  Is there a requirement to set the browser's
transmission key to a specific value (in which case, you are correct that
it would have to pass over HTTPS at least) too?

Regards,

Michael

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jun 2013 06:46:06 -0700

Michael said: > 
> SDES pieces with the EKT pieces, and thereafter forwarding packets.

[BA] Since the PBX can only handle SDES, and the media server speaksDTLS/SRTP-EKT,  the media server needs to provide the DTLS/SRTP-EKTkey to the SIP server so that it can be signaled to the PBX within SDES/SDP. Similarly, the SIP server needs to provide the SDES key signaled by thePBX to the media server so that it can communicate this in DTLS/SRTP-EKT. Therefore the PBX, media server, SIP server and browser endpoint end up possessing the keys, which is less than ideal.

---

From: Michael Procter <[email-masked]>
Date: Wed, 19 Jun 2013 16:00:40 +0100

On 19 June 2013 14:46, Bernard Aboba <[email-masked]> wrote:
> Michael said:
> [BA] Since the PBX can only handle SDES, and the media server speaks
> DTLS/SRTP-EKT,  the media server needs to provide the DTLS/SRTP-EKT
> key to the SIP server so that it can be signaled to the PBX within SDES/SDP.
> Similarly, the SIP server needs to provide the SDES key signaled by the
> PBX to the media server so that it can communicate this in DTLS/SRTP-EKT.
> Therefore the PBX, media server, SIP server and browser endpoint
> end up possessing the keys, which is less than ideal.

Well indeed.  The point I was querying was Matthew's assertion that the keys
also needed to be available to the web server and the Javascript app in the
browser (and hence transferred over HTTPS), for both SDES and EKT approaches.

I don't see why this should be true for EKT, which therefore
highlights a fairly
significant (IMHO) difference in the security properties of an
EKT-based solution.

I'm not currently claiming a preference for one over the other, but I think this
difference should be considered in the context of the whole picture.

Regards,

Michael

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 14:27:54 -0400

> One of those drafts has been expired since February I would like to

You're just messing with me right?  You're pointing out the drafts are old, in response to a complaint the meeting's been delayed multiple times??  Might it be the drafts are old because the meeting's been delayed multiple times?!?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 15:23:27 -0400

Howdy,
per the email below, I formally request agenda time to discuss - and reach a conclusive vote on - whether to make SDES an MTI key exchange mechanism, or not.

I plan to present both sides of the argument with a set of pro/con slides.  I used to favor making SDES mandatory, but over time I've become less sure if its benefits outweigh its drawbacks.  Mostly though what I care about is making a *decision* one way or the other, and moving on.  

I do *not* plan to present on DTLS-EKT at all, not even as a potential alternative.  I only plan to present on whether SDES should be MTI or not for WebRTC implementations.

I think this will take an hour at least, possibly longer.  I can pretend to claim it will take 15 minutes, but we all know that simply isn't true unless someone disconnects the microphones in the room.  I also expect two or more other folks to want time to present on the same topic, so it'll likely take even longer in total time.

Lastly, I beg the chairs to make this agenda item topic (not necessarily my presentation, but the general topic) the *first* agenda topic for whichever meeting session it gets put in, so that we don't run out of time on other topics and delay an SDES decision once again.

-hadriel

On Jun 18, 2013, at 5:56 AM, Magnus Westerlund <[email-masked]> wrote:
> Please request agenda time for

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Jun 2013 14:37:15 -0700

Thanks for the request and for volunteering to provide input to the
discussion.  If there are others who would like to contribute to the
discussion with presentations, it would be good to let the chairs/working
group know now.

thanks,

Ted Hardie

On Wed, Jun 19, 2013 at 12:23 PM, Hadriel Kaplan
<[email-masked]>wrote:

>
> Howdy,
> per the email below, I formally request agenda time to discuss - and reach
> a conclusive vote on - whether to make SDES an MTI key exchange mechanism,
> or not.
>
> I plan to present both sides of the argument with a set of pro/con slides.
>  I used to favor making SDES mandatory, but over time I've become less sure
> if its benefits outweigh its drawbacks.  Mostly though what I care about is
> making a *decision* one way or the other, and moving on.
>
> I do *not* plan to present on DTLS-EKT at all, not even as a potential
> alternative.  I only plan to present on whether SDES should be MTI or not
> for WebRTC implementations.
>
> I think this will take an hour at least, possibly longer.  I can pretend
> to claim it will take 15 minutes, but we all know that simply isn't true
> unless someone disconnects the microphones in the room.  I also expect two
> or more other folks to want time to present on the same topic, so it'll
> likely take even longer in total time.
>
> Lastly, I beg the chairs to make this agenda item topic (not necessarily
> my presentation, but the general topic) the *first* agenda topic for
> whichever meeting session it gets put in, so that we don't run out of time
> on other topics and delay an SDES decision once again.
>
> -hadriel
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 Jun 2013 20:58:32 -0400

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) <
[email-masked]> 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.
>
>  browser <--(key that was received over HTTPS and then sent using EKT)-->
> media relay <--(key that was received via SDES)--> your pbx
>
>  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):
> 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 [[email-masked]]
> *Sent:* Tuesday, June 18, 2013 12:32 PM
> *To:* Matthew Kaufman (SKYPE)
> *Cc:* Magnus Westerlund; Hadriel Kaplan; [email-masked]
>
> *Subject:* Re: [rtcweb] No Interim on SDES at this juncture
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 20 Jun 2013 01:02:00 +0000

Please consider the case where the PBX does SDES only and cannot be upgraded to do EKT (common situation around here)

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 5:58 PM, "Richard Barnes" <[email-masked]<mailto:[email-masked]>> 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.

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

else DTLS-SRTP Scenario

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

On Tue, Jun 18, 2013 at 5:16 PM, Matthew Kaufman (SKYPE) <[email-masked]<mailto:[email-masked]>> 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.

Matthew Kaufman

________________________________
From: Richard Barnes [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, June 18, 2013 12:32 PM
To: Matthew Kaufman (SKYPE)
Cc: Magnus Westerlund; Hadriel Kaplan; [email-masked]<mailto:[email-masked]>

--Richard

Matthew Kaufman

Hadirel and WG,

Regards

Magnus Westerlund

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Jun 2013 20:05:50 -0700

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

It is not exactly as secure.  SDES requires giving the SRTP key to the web server; DTLS-SRTP (with EKT) does not.

In your later emails, you combined the web server's functionality with gatewaying to an SDES-only IP PBX.  This complicates the analysis and makes a fruitful discussion impossible.

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

Yes, because DTLS-SRTP is purposefully on the media path, which is what requires the media gateway be on path.

> 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 (lik…

Yes, I agree that wherever SDES is used, those weaknesses of SDES remain.

> 4. And DTLS-SRTP without EKT fails completely for the cases where the key needs to be set for interworking.

No, it doesn't completely fail.  It requires a decrypt/re-encrypt operation in one direction of the SRTP traffic (from the SDES side to the DTLS-SRTP side).  Perhaps that is what you mean by "fails completely", I don't know.

> 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)…

You're saying identity is not desirable, because of audio mixers?

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Jun 2013 20:07:24 -0700

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

Let's not.  Combining those two functions confuses SDES interworking with the security of everything else.  Yes, it is true that when doing SDES interworking that the security vulnerabilities of SDES are exposed on the SDES portion of the network.  The solution is to quit doing SDES, not more.

-d

> On Tue, Jun 18, 2013 at 3:02 PM, Matthew Kaufman (SKYPE)<[email-masked]> wrote:

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 03:11:09 -0400

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Jun 2013 09:30:59 +0200

On 2013-06-19 20:27, Hadriel Kaplan wrote:
>>>> 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.
> 
> You're just messing with me right?  You're pointing out the drafts
> are old, in response to a complaint the meeting's been delayed
> multiple times??  Might it be the drafts are old because the
> meeting's been delayed multiple times?!?

That is not my complaint. Yes, the meeting has been delayed. That has
caused the draft to expire. Thus, I personally would expect that
proponents that are interested in the topic at least re-submits the
draft so that it is available and easily findable for people.

Thus, I took that as part of the indications of uncertain interest. That
weighted in with several other factors that made us cancel the interim.

I can only state my personal view of factors that influenced my position
resulting in the chairs decision.

To be clear, I am also not happy with how this has developed. I
definitely hope this issue can be settled with the Berlin meeting.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Jun 2013 13:23:54 +0200

> Back on April 25th, I made some claims. I still believe these are true:

And I still believe enough of them are false that I don't have much 
faith in a conclusion drawn from those premises.

> 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.
I believe this is false. "Exactly as secure" doesn't hold when the 
holders of the keys for the two encrypted channels are different.

> 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 (lik…
Interworking with SDES requires that the key is carried in SDES, so this 
seems like a truism.
> 4. And DTLS-SRTP without EKT fails completely for the cases where the key needs to be set for interworking.
If you had said "requires decrypt/reencrypt at the gateway" rather than 
"fails completely", I would hold this statement to be true. As written, 
I believe this is false.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 20:52:47 +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.

Regards
Andy

> Sent: 20 June 2013 08:11
> > 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>
> >
> > -- 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.
> 
> 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.
> 
> 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
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Jun 2013 16:58:05 -0400

On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <
[email-masked]> 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.
>
> 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.
>
Not to play devil's advocate, but how is it any different then arguments to
support plain RTP? All the same things apply to RTP. On top of this SRTP is
no more secure then plain RTP when communicating with a server over plain
HTTP or communicating with untrusted server over HTTPS. If we decided that
RTP is unacceptable from security point of view, then how is SRTP
acceptable?
_____________
Roman Shpount

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 21:25:20 +0000

Communication with an untrusted server is always insecure, even if using DTLS-SRTP, it is surely the level of risk that is the issue and the problem to solve is how the browser indicates that to the user.

Using SRTP is always more secure than using plain RTP but again I think the problem to be solved is how the user is notified about the level of risk.

Regards
Andy

From: Roman Shpount [mailto:[email-masked]]
Sent: 20 June 2013 21:58
To: Hutton, Andrew
Cc: Hadriel Kaplan; Richard Barnes; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] No Interim on SDES at this juncture

On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> 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.

Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicating with a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable from security point of view, then how is SRTP acceptable?
_____________
Roman Shpount

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 18:24:03 -0400

On Thu, Jun 20, 2013 at 3:11 AM, Hadriel Kaplan
<[email-masked]>wrote:

> EKT.  After EKT, it just switches packets (it's basically a TURN server).
> >
> for SDES.  Your quantitative valuation of these benefits / costs may vary.
>
> can simply *be* the PBX, terminate DTLS-EKT and get the key and the browser
> user would never know it.

It's more secure in the sense that it makes a malicious web server do more
work: It forces the web server to act as the PBX and terminate DTLS,
instead of just pulling the key out of the SDP and decrypting media.  So
the browser user is (incrementally) better protected against the malicious
web server.

It's more secure in the sense that JS can't access the key, so an injected
script can't grab the key and exfiltrate it.  So the browser user is better
protected against XSS risks.

It's more secure in the sense that SDES has no end-to-end authentication
[1], so implementing SDES creates bid-down attacks.  If an attacker can't
get a valid identity, he just claims not to support DTLS-SRTP.  So the
browser user is better protected against bid-down attacks by remote users
(e.g., the malicious web server's PBX).

--Richard

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 18:25:16 -0400

> that any media gateway is going to be in cahoots with the webserver and has

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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Jun 2013 18:58:19 -0400

On Thu, Jun 20, 2013 at 5:25 PM, Hutton, Andrew <
[email-masked]> wrote:

>  Using SRTP is always more secure than using plain RTP but again I think
> the problem to be solved is how the user is notified about the level of
> risk.
>
>
>
Please explain how SRTP is more secure the plain RTP when communicating
with plain HTTP server? I can decode either from a simple packet capture.
After all, you did say always...
_____________
Roman Shpount

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 19:09:16 -0400

The path from end to end media path is not the same as the path from end to
middle (signaling path).  SRTP in general (without assumptions on key
management) protects against a passive attacker that is on the media path
but not on the signaling path.

If, in addition, the browser does not expose media keys to JS (as is
required for SDES), then even an active attacker who hijacks the HTTP
connection to inject scripts cannot access the media keys.

--Richard

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Jun 2013 19:31:50 -0400

On Thu, Jun 20, 2013 at 7:09 PM, Richard Barnes <[email-masked]> wrote:

> The path from end to end media path is not the same as the path from end
> to middle (signaling path).  SRTP in general (without assumptions on key

My point is that if I can intercept all the traffic from the end point and
the end point uses HTTP to send the keys I can decode everything sent over
SRTP. This means we have one very insecure point. The whole system is as
secure as the least secure portion of it. Thus SRTP with plain HTTP is
exactly as secure as plain RTP (ie not at all).

> connection to inject scripts cannot access the media keys

DTLS is only slightly more secure with plain HTTP and no identity, since I
would need to hijack the HTTP session and decode/encode media. A bit more
work but marginally so.

Following this logic, should not this group outlaw WebRTC sessions from not
HTTPS sources?
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Jun 2013 16:36:37 -0700

On 20 June 2013 14:25, Hutton, Andrew
<[email-masked]> wrote:
> Using SRTP is always more secure than using plain RTP but again I think the
> problem to be solved is how the user is notified about the level of risk.

I'm fairly sure that the levels of trust can be very easily enumerated:

Do you trust the site? (i.e., default access level on getUserMedia or
a session that uses SDES)

Do you trust some other guy?  Where the identity of the other guy is
provided. (peerIdentity/noaccess constraint on getUserMedia, and
DTLS-SRTP, and - if it isn't a domain name - an identity provider)

Given that either default access levels on gUM or use of SDES to be
equivalent, and I think that they are to a reasonable approximation,
then the security story for SDES isn't that weak.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Jun 2013 16:41:07 -0700

> connection to inject scripts cannot access the media keys.

That's only true if that attacker were not able to also set the keys.
I haven't had anyone explain what the API for EKT would look like, but
one possibility would permit that attacker to set keys (i.e., keying
would be write-only).  That possibility would be attractive from a
symmetry perspective - the non-browser can insert new keying, why
should the browser be prevented from doing so - but I can see how
implementation of EKT does not strictly require that possibility.
That would preclude some interesting browser-API-based scenarios
though.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 20:33:18 -0400

> Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicat…

I'm operating under the assumption we would only allow the Browser to use SDES if and only if it is also using HTTPS to the web server.  And I'm operating under the assumption that all browsers still MUST offer DTLS-SRTP, and choose it instead SDES if they receive such an offer.  

In such a model, any two browsers do DTLS-SRTP to each other unless the web-server/JS is malicious.  Ergo, unless the web-server/JS is malicious, only calls to/from a gateway use an SDES key.  The SDES key isn't sniffable on the browser-server HTTPS portion.  Obviously it's sniffable beyond the web server, if it gets sent in the clear somewhere else.  But we know that will also happen even with DTLS-SRTP, because the gateway will terminate DTLS-SRTP and use SDES or plain RTP on the other side.  So we're not losing anything.

So... in theory the danger is relegated to the malicious web-server case.  But a malicious web server can get your media anyway, even with DTLS-SRTP, because it can simply direct you to its own "gateway" to terminate DTLS-SRTP and record the media.  There is no practical way to prevent a malicious web-server from getting your media, no matter what we do, for common every-day users.

Frankly with a malicious web server you're screwed in so many other ways anyway, that making it just slightly harder for it to get your media is like putting on a scuba drysuit when jumping into a pool of molten lava.  Yes, you'll live for some fraction of a millisecond longer.  And then what?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 21:11:27 -0400

On Jun 20, 2013, at 6:24 PM, Richard Barnes <[email-masked]> wrote:

> It's more secure in the sense that it makes a malicious web server do more work: It forces the web server to act as the PBX and terminate DTLS, instead of just pulling the key out of the SDP and decrypting media.  So the browser user is (incrementally) better protected against the malicious web server.

Uh huh.  So, like, the only people who could afford to do that and would want to do that would be criminals, drug dealers, mobsters, casinos, news organizations, political parties, and governments then?  Phew!  And here I was being worried.

But wait a minute... I was under the distinct impression from people in this group that doing DTLS-SRTP termination on the gateways was no big deal for "modern" servers... that it was so cheap and trivial that your cell phone could do it for umpteen streams... that we shouldn't be worried about the overhead of it whatsoever.  Surely you can't be telling me that it's at all difficult for someone running a malicious web site to do it?!?
;)

> It's more secure in the sense that JS can't access the key, so an injected script can't grab the key and exfiltrate it.  So the browser user is better protected against XSS risks.

This part I'd like to understand better.  Can you explain it?  
If a Browser cannot determine what server the JS being executed for WebRTC API calls/callbacks came from, or cannot tell if it came from one over HTTPS in particular, then using SDES might be a real problem.  I was under the impression browsers did know those things (or at least that they're theoretically supposed to, ignoring that  there are "bugs" here and there).

> It's more secure in the sense that SDES has no end-to-end authentication [1], so implementing SDES creates bid-down attacks.  If an attacker can't get a valid identity, he just claims not to support DTLS-SRTP.  So the browser user is better protected against bid-down attacks by remote users (e.g., the malicious web server's PBX).

This is just another symptom of talking to a malicious web server, and basically a repeat of the argument that DTLS-EKT is "more secure" because a malicious web server has to do a little more work to steal everything.  It's like being stuck in a big cage with a man-eating lion and deciding to run around in circles in the hopes the lion isn't going to chase you.  If he's hungry at all, you're dead; chasing you down is not sufficiently more difficult for him to stay hungry.

-hadriel

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 22:14:22 -0400

On Thu, Jun 20, 2013 at 9:11 PM, Hadriel Kaplan
<[email-masked]>wrote:

> > It's more secure in the sense that it makes a malicious web server do
> more work: It forces the web server to act as the PBX and terminate DTLS,
> Uh huh.  So, like, the only people who could afford to do that and would
> want to do that would be criminals, drug dealers, mobsters, casinos, news
> organizations, political parties, and governments then?  Phew!  And here I
> was being worried.
>
> But wait a minute... I was under the distinct impression from people in
> this group that doing DTLS-SRTP termination on the gateways was no big deal
> for "modern" servers... that it was so cheap and trivial that your cell
> phone could do it for umpteen streams... that we shouldn't be worried about
> the overhead of it whatsoever.  Surely you can't be telling me that it's at
> all difficult for someone running a malicious web site to do it?!?
> ;)

Look, I said it was "incremental", right?  :)  At the very least, it keeps
out the script kiddies.   If you compromise my web site, you have to have
some other resources to compromise the users' voice sessions; you can't
just do it from the web server you've pwned.  You might not be up against a
tiger every time; sometimes, it's just a house cat.

> > It's more secure in the sense that JS can't access the key, so an
> injected script can't grab the key and exfiltrate it.  So the browser user
> is better protected against XSS risks.
>
> If a Browser cannot determine what server the JS being executed for WebRTC
> API calls/callbacks came from, or cannot tell if it came from one over
> HTTPS in particular, then using SDES might be a real problem.  I was under
> the impression browsers did know those things (or at least that they're
> theoretically supposed to, ignoring that  there are "bugs" here and there).

As with many things in the web security model, the answer is "It's
complicated".  The wikipedia article on XSS is pretty good.
<http://en.wikipedia.org/wiki/Cross-site_scripting>

The upshot is that your typical web page gets cobbled together out of many
pieces, often from different domains.  Scripts from multiple sources get
imported into the overall security context of the page.  This composition
can happen deliberately (e.g., mashups, JS libraries) or maliciously (XSS).
 Let me provide an example of each:

1. Suppose I use jQuery to do pretty layout on my page.  There's nothing
that actually constrains jQuery to only do layout.  If jQuery is out to get
me, it could do something like overwrite window.PeerConnection, so that all
of the page's WebRTC calls go through the jQuery library and are subject to
its control.  So if the PeerConnection API exposes keys, jQuery can steal
them.

2. Suppose the overall page is loaded over HTTPS, but one of the scripts is
loaded over HTTP.  Then the overall security context for the page is HTTPS,
but if an attacker can hijack that HTTP load to introduce a script, in
which case he can do the same bad stuff that jQuery could in the above
example.  (This is why we have the following sentence in
draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which
allow active mixed content nevertheless disable RTCWEB functionality in
mixed content settings."

There are mitigations to a lot of these sorts of issues, but some are still
being developed.  And of course, there's no guarantee that a given site
will follow all the best practices.  So it seems sensible to limit the
damage that an injected script can do.

--Richard

> This is just another symptom of talking to a malicious web server, and
> basically a repeat of the argument that DTLS-EKT is "more secure" because a
> malicious web server has to do a little more work to steal everything.
>  It's like being stuck in a big cage with a man-eating lion and deciding to
> run around in circles in the hopes the lion isn't going to chase you.  If
> he's hungry at all, you're dead; chasing you down is not sufficiently more
> difficult for him to stay hungry.
>
> -hadriel
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 22:18:10 -0400

> That would preclude some interesting browser-API-based scenarios

Good point.  I hadn't thought of that.  In order for SDES to work, though,
I would think you would need both getting and setting of keys.

What interesting scenarios do you have in mind?  I wonder whether the group
considers them critical for v1.

In any case, this seems like something where a conservative approach could
be taken at first, then a key access API added later.

--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 22:58:33 -0400

On Jun 20, 2013, at 10:14 PM, Richard Barnes <[email-masked]> wrote:

> As with many things in the web security model, the answer is "It's complicated".  The wikipedia article on XSS is pretty good.
> The upshot is that your typical web page gets cobbled together out of many pieces, often from different domains.  Scripts from multiple sources get imported into the overall security context of the page.  This composition can happen deliberately (e.g., mashups, JS libraries) or maliciously (XSS).  Let me provide an example of each:
> 
> 1. Suppose I use jQuery to do pretty layout on my page.  There's nothing that actually constrains jQuery to only do layout.  If jQuery is out to get me, it could do something like overwrite window.PeerConnection, so that all of the page's WebRTC calls go through the jQuery library and are subject to its control.  So if the PeerConnection API exposes keys, jQuery can steal them.

We've talked about that one before I think.  If jQuery is out to get you, it's game over.  It's essentially equivalent to a malicious web-server, except of course that the operator of the web-server isn't intending to be malicious (which is an important distinction).  But again, not only does jQuery have access to information such as who you're talking to and when, it can also redirect your media to a gateway of its choosing to terminate the DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff.

> 2. Suppose the overall page is loaded over HTTPS, but one of the scripts is loaded over HTTP.  Then the overall security context for the page is HTTPS, but if an attacker can hijack that HTTP load to introduce a script, in which case he can do the same bad stuff that jQuery could in the above example.  (This is why we have the following sentence in draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which allow active mixed content nevertheless disable RTCWEB functionality in mixed content settings."

Right, and I think we've talked about that before too in the context of SDES: I think people were ok with limiting it further for SDES with a statement saying it must not be used in mixed content settings if one of the scripts came in on HTTP. (although I could be wrong on whether any consensus was reached on that point - it was a long time ago and I have a memory leak)

> There are mitigations to a lot of these sorts of issues, but some are still being developed.  And of course, there's no guarantee that a given site will follow all the best practices.  So it seems sensible to limit the damage that an injected script can do.

Right, and I'm hoping the Browser vendors can tell us if browsers can safely know whether all the JS running on a given page is from HTTPS or not, and not allow SDES if the JS is not all from (signed) HTTPS.  If not, then I agree that's another negative downside for SDES.  In fact I think it's even a problem for DTLS-SRTP.  I don't know why we'd be ok with using HTTP at all, if we're *truly* concerned about MitM and malicious 3rd party JS attacks. 

-hadriel

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jun 2013 08:58:24 -0700

On 20 June 2013 18:11, Hadriel Kaplan <[email-masked]> wrote:
> criminals, drug dealers, mobsters, casinos, news organizations, political parties, and governments

I assume that large corporations fit in this list in several places,
so you chose to omit specific mention of those.  There seems to be a
fair amount of overlap in those categories as it stands.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jun 2013 09:05:54 -0700

On 20 June 2013 19:18, Richard Barnes <[email-masked]> wrote:
> What interesting scenarios do you have in mind?

I doubt that they are critical, but to give you some idea, Skype mixes
audio on a peer for group calls.  It avoids the need for a server or a
full mesh.  That's mixing, but it could also be switching (especially
if it were for video).  The the latter is something that CU-RTC-Web
could do, we didn't go to the extent of doing pass-through without
decrypt+decode, which is in optimization-land; I don't believe that
it's v1 critical, mainly because we've never discussed this before, so
it seems unlikely.

One of the major concerns with the current API surface is how it
precludes as many scenarios as it enables, and this is another... hang
on, sorry, wrong thread.

---

From: Dan Wing <[email-masked]>
Date: Fri, 21 Jun 2013 09:45:35 -0700

> We've talked about that one before I think.  If jQuery is out to get you, it's game over.  It's essentially equivalent to a malicious web-server, except of course that the operator of the web-serve…

For the attacker to succeed with the redirection of DTLS-SRTP to a server it controls, the attacker would also need to modify the SDP's a=fingerprint line which is as  trivial as the attacker's other SDP modifications.  To prevent the attacker from succeeding with such modification, we need cryptographic identity (to protect the From/To/Date/a=fingerprint and other fields), and need the browser (not JS) to verify the identity using an external service (e.g., local disk, IdP separate from the web server providing us the (compromised) JS and the SDP).  While it is true that today we don't have a way today to provide that cryptographic identity (RFC4474 does not work, draft-wing-rtcweb-identity-media written by me and Hadriel was met with silence) DTLS-SRTP creates the foundation to build cryptographic identity which can be verified by the browser itself.  Such cryptographic identity protects from this specific attack, and DTLS-SRTP protects from other attacks.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 12:56:32 -0400

On Jun 21, 2013, at 11:58 AM, Martin Thomson <[email-masked]> wrote:

> so you chose to omit specific mention of those.  

Yes I chose to omit them.  Not because I think large corporations are angels, but because I think there are fairly effective mechanisms in place to keep large corporations from being malicious in terms of recording audio/video you don't expect to be recorded: laws, law suits and brand reputation.

That's why I think even direct competitors of Cisco are willing to use WebEx - and my last 4 employers all used WebEx and were all direct competitors of Cisco - not because we think it's impossible for the WebEx server to do it, nor because we believe they don't store keys or whatever, but rather because we know if they got caught doing it on purpose for malicious use then they'd be sued for blood, and the reputation of WebEx would be so tarnished as to be put out of existence.

Obviously there are some large corporations I won't name that my employers probably feel couldn't be held accountable or in-check in those ways - but we would never trust such large corporations no matter what key-exchange mechanism WebRTC uses.  In fact, even if WebRTC could provide a key-exchange that no malicious MITM could bypass, we still wouldn't trust such corporations - because the information in the JSON is almost as important as the conversation audio/video: it identifies who's communicating with whom, for how long, from where, and often even on what subject.  That's one of the reasons I was saying the other day: if the web-server or JS is truly malicious or compromised, it's game over.

> There seems to be a

I get the impression each one might not be a criminal in some country-or-other's perspective.
Arguably for some countries, *all* of them are "criminals". ;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 13:14:49 -0400

> For the attacker to succeed with the redirection of DTLS-SRTP to a server it controls, the attacker would also need to modify the SDP's a=fingerprint line which is as  trivial as the attacker's oth…

I agree - when we have such a thing, using DTLS-SRTP will have much more meaning.  But (1) there is no such thing yet, and (2) it won't make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway scenarios we're talking about, since the DTLS isn't going end-to-end.  I.e., none of the calls would successfully authenticate using such an out-of-band mechanism, even the good ones.

[note though I'm not saying DTLS-SRTP is useless today - quite the contrary, I hummed in favor of making it MTI back when that was decided, and I still think it should be MTI]

-hadriel

---

From: Dan Wing <[email-masked]>
Date: Fri, 21 Jun 2013 10:59:52 -0700

> [note though I'm not saying DTLS-SRTP is useless today - quite the contrary, I hummed in favor of making it MTI back when that was decided, and I still think it should be MTI]

Will the existence of SDES prevent WebRTC from building this more secure system with strong identity?  That is, when we add cryptographic identity will that be effective to prevent a bid-down attack from DTLS-SRTP to SDES?  I am thinking right now that when we add identity we can prevent that bid-down, so at that time SDES could become a proper second-class citizen.

-d

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jun 2013 11:16:26 -0700

> Will the existence of SDES prevent WebRTC from building this more secure system with strong identity?  That is, when we add cryptographic identity will that be effective to prevent a bid-down attac…

I have thought about this a little and I can't work out a practical
bid-down.  That is, aside from the human factors/social engineering
problems, which exist in all cases.

---

From: Max Jonas Werner <[email-masked]>
Date: Sun, 23 Jun 2013 14:51:43 +0200

> On Jun 20, 2013, at 7:58 PM, Hadriel Kaplan <[email-masked]> wrote:
[...]
>> We've talked about that one before I think.  If jQuery is out to
>> get you, it's game over.  It's essentially equivalent to a
>> malicious web-server, except of course that the operator of the
>> web-server isn't intending to be malicious (which is an important
>> distinction).  But again, not only does jQuery have access to
>> information such as who you're talking to and when, it can also
>> redirect your media to a gateway of its choosing to terminate the
>> DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff.
> 
> For the attacker to succeed with the redirection of DTLS-SRTP to a
> server it controls, the attacker would also need to modify the SDP's
> a=fingerprint line which is as  trivial as the attacker's other SDP
> modifications.  To prevent the attacker from succeeding with such
> modification, we need cryptographic identity (to protect the
> From/To/Date/a=fingerprint and other fields), and need the browser
> (not JS) to verify the identity using an external service (e.g.,
> local disk, IdP separate from the web server providing us the
> (compromised) JS and the SDP).  While it is true that today we don't
> have a way today to provide that cryptographic identity (RFC4474 does
> not work, draft-wing-rtcweb-identity-media written by me and Hadriel
> was met with silence) DTLS-SRTP creates the foundation to build
> cryptographic identity which can be verified by the browser itself.
> Such cryptographic identity protects from this specific attack, and
> DTLS-SRTP protects from other attacks.

draft-ietf-rtcweb-security-arch-06, section 5.6 talks quite clearly
about verifying peer identities (without concentrating on a signalling
protocol like SIP) so if you would want to have secure communication
(even with a signalling server you don't trust) _and_ verified peers a
combination of DTLS-SRTP and the mentioned peer authentication mechanism
in draft-ietf-rtcweb-security-arch-06 would be a must.

As far as I understand it, SDES cannot provide the same level of
end-to-end security under the assumption that you don't trust the
signalling server.

Max

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 27 Jun 2013 22:26:03 +0530

Dan,

I'm wondering whether any identity is mandatory all for WebRTC session. I'm
asking this query as lot of WebRTC demo works well without any identity. For
example: it is possible to pass URL like
https://apprtc.appspot.com/?r=06095338 and ask the participant to join the
session.

Thanks
Partha

> Behalf Of Dan Wing
> Sent: Friday, June 21, 2013 11:30 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> get you, it's game over.  It's essentially equivalent to a malicious
> web-server, except of course that the operator of the web-server isn't
> intending to be malicious (which is an important distinction).  But
> again, not only does jQuery have access to information such as who
> you're talking to and when, it can also redirect your media to a
> gateway of its choosing to terminate the DTLS-SRTP and record it, by
> fiddling with the JSON/SDP stuff.
> 
> >>
> From/To/Date/a=fingerprint and other fields), and need the browser (not
> JS) to verify the identity using an external service (e.g., local disk,
> IdP separate from the web server providing us the (compromised) JS and
> the SDP).  While it is true that today we don't have a way today to
> provide that cryptographic identity (RFC4474 does not work, draft-wing-
> rtcweb-identity-media written by me and Hadriel was met with silence)
> DTLS-SRTP creates the foundation to build cryptographic identity which
> can be verified by the browser itself.  Such cryptographic identity
> protects from this specific attack, and DTLS-SRTP protects from other
> attacks.
> >
> > I agree - when we have such a thing, using DTLS-SRTP will have much
> more meaning.  But (1) there is no such thing yet, and (2) it won't
> make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway
> scenarios we're talking about, since the DTLS isn't going end-to-end.
> I.e., none of the calls would successfully authenticate using such an
> out-of-band mechanism, even the good ones.
> >
> > [note though I'm not saying DTLS-SRTP is useless today - quite the
> contrary, I hummed in favor of making it MTI back when that was
> decided, and I still think it should be MTI]
> 
> Will the existence of SDES prevent WebRTC from building this more
> secure system with strong identity?  That is, when we add cryptographic
> identity will that be effective to prevent a bid-down attack from DTLS-
> SRTP to SDES?  I am thinking right now that when we add identity we can
> prevent that bid-down, so at that time SDES could become a proper
> second-class citizen.
> 
> -d
>

---

From: Max Jonas Werner <[email-masked]>
Date: Thu, 27 Jun 2013 19:42:02 +0200

Partha,

> https://apprtc.appspot.com/?r=06095338 and ask the participant to join the

whether an application makes use of the identity API is up to the
developer as far as I unterstand the specs. This is why
http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity states:

"WebRTC offers and answers (and hence the channels established by
RTCPeerConnection objects) can be authenticated"

I just recently gave a talk on WebRTC security and in the part about
identity I stated that anonymity is a very useful tool to ensure user's
privacy. That's why the identity services should always be optional.

Max