Subject: [rtcweb] Draft agenda for IETF 87

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Jul 2013 09:51:06 -0700

Greetings,

Below is an initial draft agenda for the upcoming meeting.   Since we have
not yet reached the draft deadline (which is the 15th), there may be new
drafts or updates that result in changes.  We did already receive requests
for NAT/Firewall traversal discussion, and the chairs will be working with
the document authors to get them considered in the appropriate groups.

As folks have probably noticed, we are meeting Thursday and Friday, after
the MMUSIC sessions are complete (they are Tuesday and Wednesday). This
should allow us to discuss the results on our first day.

Please send feedback or change proposals to the list.

thanks,

Ted and Cullen

Day 1:

Should SDES be part of  WebRTC security practice and, if so, how?
Presentations: 30 minutes
Discussion:  40 minutes

Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents
Presentation: 30 minutes
Discussion: 30 minutes

Security document updates
Presentation: 10 minutes
Discussion: 10 minutes

Day 2:

Chair Discussion:  10 minutes

Use Case Requirements updates:
Issues list presentation: 20 minutes
Discussion: 20 minutes

Data channel:
Issues list presentation:  45 minutes
Discussion: 45 minutes

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Jul 2013 19:35:34 +0200

Hey Ted,

I am sorry I must have missed your call for presentations.

In you last mail on the subject you mentioned that we will be discussing No
Plan in Berlin together with plans A and B. Could we please add this to the
agenda?

Emil

--sent from my mobile
On Jul 11, 2013 6:51 PM, "Ted Hardie" <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jul 2013 11:08:08 -0700

I can see some implied outcomes for some of the items.  Would it help
to list some (aspirational) goals.

> Presentations: 30 minutes

Are the chairs confident that this topic can be resolved in this time?
 We managed to fritter a similar amount of time away without
conclusion in the past.  I can see how you plan to accommodate
overruns, but that just opens the possibility more time-wasting.  How
do we ensure that this discussion actually concludes?

> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents

How are you planning to prepare for this?  Do you have presenter
candidates lined up?

> Chair Discussion:  10 minutes

I'm curious how you intend to spend this time.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 11 Jul 2013 18:24:49 +0000

inline 

> do we ensure that this discussion actually concludes?

Thought on how to make that happen? Time needed ?

> How are you planning to prepare for this?  Do you have presenter

This is a very draft agenda - part of the issues is we are not even at the -00 draft deadline yet so I expect that by next week we should be able to figure out more details. We have scheduled the MMUSIC meetings before the RTCWeb meetings in Berlin so at some level, some of this may change after the MMUSIC meetings happen. Anyways, expect more details after we get to read all the drafts and expect us to be a bit dynamic on this given what happens in the MMUSIC meeting. 

> I'm curious how you intend to spend this time.

We would like to inform folks of a few things happening in other WG (TURN, NAT, BEHAVE etc) but we would also like to have a discussion about what it takes to get to "Done" for the first iteration of all this stuff. We need to get WG feedback on what work is left and what needs to be prioritized.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jul 2013 12:03:23 -0700

> Thought on how to make that happen? Time needed ?

There are two aspects of this that I, personally, want to see resolved
before I'm happy that we can conclude on this:
 - a story for the gateway-to-other-stuff scenarios (where other-stuff
is mostly just all-the-existing-stuff)
 - a story for conference scenarios

The first two could conclude that we need to re-encrypt at these
points, but that would require some justification.  Or we could
conclude that we need SDES, or maybe that DTLS-SRTP+EKT is the right
answer.

I'm stretching my recall capacity, but I recall promises from several
people to present on various aspects.  If those presentations cover
the ground well enough, then we can go into a discussion
well-prepared.  Time needed will then depend on the time that each
presenter needs.

If we can get to the point where the space is well-enough understood,
we should be able to conclude.  That does require a modest amount of
time for each participant to make an impassioned plea at the mic.  And
pontification takes time.

We may need to consider the alternative decision making process here.

> This is a very draft agenda - part of the issues is we are not even at the -00 draft deadline yet so I expect that by next week we should be able to figure out more details. We have scheduled the M…

You'd best have some candidates lined up to produce some discussion
material in short order.

> We would like to inform folks of a few things happening in other WG (TURN, NAT, BEHAVE etc) but we would also like to have a discussion about what it takes to get to "Done" for the first iteration…

Thanks.  That helps.  That might be too short a time for that list.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 11 Jul 2013 19:04:52 +0000

On Jul 11, 2013, at 10:35 AM, Emil Ivov <[email-masked]>
 wrote:

> In you last mail on the subject you mentioned that we will be discussing No Plan in Berlin together with plans A and B. Could we please add this to the agenda?
> 
> Emil
> 
> 

No. We believe that conversation needs to happen in the W3C WebRTC WG. I expect to see a message from W3C chairs on this at some point.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jul 2013 12:37:49 -0700

> No. We believe that conversation needs to happen in the W3C WebRTC WG. I expect to see a message from W3C chairs on this at some point.

I'm a little nervous about this.  Where does the decision on the
separation of responsibilities (API vs. SDP) get made?

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Jul 2013 14:46:46 -0500

> separation of responsibilities (API vs. SDP) get made?

Jointly by the chairs of RTCWEB and WebRTC, based on 
<http://www.w3.org/2011/04/webrtc-charter.html> and 
<http://tools.ietf.org/wg/rtcweb/charters>, one would presume.

/a

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jul 2013 13:18:15 -0700

> <http://tools.ietf.org/wg/rtcweb/charters>, one would presume.

To be perfectly clear, that's precisely what makes me nervous.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 11 Jul 2013 19:06:29 -0500

> To be perfectly clear, that's precisely what makes me nervous.

[MB] Me too. [/MB]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Jul 2013 00:55:44 +0000

>> To be perfectly clear, that's precisely what makes me nervous.

One might read this to imply that this was chair decision about the scope, but in this case, I don't think the chairs have very much to do with if the no-plan draft happens to be in scope of this WG or not.  As the authors explained it, it is purely an API change with no changes to anything on the wire. Everyone in this WG seems to agree on where API works happens and I have not heard any disagreement on that. Of course that not surprising that there is not disagreement on this as the charters of WebRTC and RTCWeb seem relatively clear on this.

On the decision of what to put on a draft agenda before the -00 deadline, of course Ted and I take responsibility for the current draft agenda.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 12 Jul 2013 07:35:00 +0000

On 7/11/13 9:38 PM, Martin Thomson wrote:
>>> In you last mail on the subject you mentioned that we will be
>>> discussing No Plan in Berlin together with plans A and B. Could
>>> we please add this to the agenda?
>>
>> No. We believe that conversation needs to happen in the W3C WebRTC
>> WG. I expect to see a message from W3C chairs on this at some
>> point.
>

(I have not been able to confer with any of the other chairs, so this is 
just my personal opinion):

To me it seems pretty straightforward to a certain point:

* The SDP (if we opt to continue using SDP for this purpose) that goes
on the signaling wire between the browsers is defined by IETF (and by
the rtcweb WG I presume even though MMUSIC seems to have some stake)

* JS APIs to:
** Apply an SDP (e.g. received on the signaling channel) to the browser
** Hand an SDP generated by the browser over to the application (for
transmission over the signaling wire presumably)
** Influencing/modifying the contents of the SDP
* All belongs to the W3C WebRTC

What seems unclear to me is where we define what modifications to the
SDP that are allowed - and when. Even though the ambition is to have
APIs that makes SDP mangling an exception, we will still see that
happening.

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 12 Jul 2013 09:01:05 +0000

Regarding the FW traversal discussion then I still think we need a discussion in the RTCWEB WG and I hope to persuade the chairs that this is the case.

We have requirements in the use case draft and charter items that need solutions and this is a real issue impacting RTCWeb trials today.

Regards
Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 11 July 2013 17:51
To: [email-masked]
Cc: Cullen Jennings
Subject: [rtcweb] Draft agenda for IETF 87

Greetings,

Below is an initial draft agenda for the upcoming meeting.   Since we have not yet reached the draft deadline (which is the 15th), there may be new drafts or updates that result in changes.  We did already receive requests for NAT/Firewall traversal discussion, and the chairs will be working with the document authors to get them considered in the appropriate groups.

As folks have probably noticed, we are meeting Thursday and Friday, after the MMUSIC sessions are complete (they are Tuesday and Wednesday). This should allow us to discuss the results on our first day.

thanks,

Ted and Cullen

Day 1:

Day 2:

Data channel:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Jul 2013 11:11:02 +0200

> * All belongs to the W3C WebRTC

I've never seen an API in which the application requests some data to
the core, and then mangles such a data before sending it to the peer.
This is like if I ask the browser to send video, the browser gives me
a media description (I will not assume SDP) with ptime=20, and I
mangle the media description to set ptime=50, while at the same time I
have no idea whether my browser can send RTP with ptime=50 or not.
It's just awesome.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 12 Jul 2013 10:34:08 +0000

> have no idea whether my browser can send RTP with ptime=50 or not.

I think this is not at all the way it should be done; if people think 
there is a need to define a specific ptime there should be an API that 
allows for that (and that has means of letting the app know what the 
allowed ranges are, or at least what is actually used). Let's go and do 
that in the WebRTC WG.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Jul 2013 12:41:15 +0200

2013/7/12 Stefan Håkansson LK <[email-masked]>:
> allowed ranges are, or at least what is actually used).

That looks a real JS Object based API, right? ;)

> Let's go and do

Sure.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Jul 2013 15:09:05 +0000

Can you get specific about exactly what you want to discuss? The current solution ins the specs uses ICE, STUN, TURN and works thorough many firewalls but not all. What change would you like to see?

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Jul 2013 15:16:46 +0000

Andy, sorry … ignore this. I see you provided what I was asking for on another thread.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 12 Jul 2013 15:17:49 +0000

What we want to discuss is a solution to the HTTP (Proxy) only FW use case as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11#section-3.2.3. This is not solved by the current specs. 

The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01 proposes a solution based on using HTTP Connect and some other related browser best practice requirements but also discusses alternatives.

We want to discuss solving this use case and hopefully get this draft adopted.

Andy

> -----Original Message-----
> From: Cullen Jennings (fluffy) [mailto:[email-masked]]
> Sent: 12 July 2013 16:09
> To: Hutton, Andrew
> Cc: Ted Hardie; [email-masked]
> Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues
> 
> 
> Can you get specific about exactly what you want to discuss? The
> current solution ins the specs uses ICE, STUN, TURN and works thorough
> many firewalls but not all. What change would you like to see?
> 
> > Regarding the FW traversal discussion then I still think we need a
> discussion in the RTCWEB WG and I hope to persuade the chairs that this
> is the case.
> >
> > We have requirements in the use case draft and charter items that
> need solutions and this is a real issue impacting RTCWeb trials today.
> >
> > Regards
> > Andy
> >
> >
> >
> > Below is an initial draft agenda for the upcoming meeting.   Since we
> have not yet reached the draft deadline (which is the 15th), there may
> be new drafts or updates that result in changes.  We did already
> receive requests for NAT/Firewall traversal discussion, and the chairs
> will be working with the document authors to get them considered in the
> appropriate groups.
> >
> > As folks have probably noticed, we are meeting Thursday and Friday,
> after the MMUSIC sessions are complete (they are Tuesday and
> Wednesday). This should allow us to discuss the results on our first
> day.
> >

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Jul 2013 15:30:36 +0000

So section 3.3.1 of draft-hutton-rtcweb-nat-firewall-considerations provides a brief sketch of an extension to TURN clients to use a HTTP proxy. 

I would be shocked to see anyone in this WG tell you not to do that, it's been discussed many times in the past. But in the end this WG will either say we like it, take it to BEHAVE, or it will say we hate it in which case as and individual draft you will still probably take it to BEHAVE. You probably want to keep an eye on HTTP2 stuff and implications to this too. 

We had not much list discussion on this draft. We have an agenda very full of WG items that are very controversial. We could put it at the end of the agenda with "time permitting" but to be honest, I sort of doubt we would get to it. Is there some question you think you want feedback from this group on that we could start on this list or something? 

I'm just trying to be realistic about the outcomes of this draft - we could discuss it in RTCWeb for 3 meetings before proposing a  TURN extension in behave but in the end I suspect we could just short circuit all that.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 12 Jul 2013 16:44:14 +0000

I totally don't follow this argument.

What we need is for RTCWEB browsers to behave in a standardized way in environments where there is a FW requiring the flow to come from a HTTP Proxy. Defining this is clearly within the scope of RTCWEB and if we move the work to BEHAVE we still need a RTCWEB specification to say what rtcweb implementations are required to implement.

The charter states the wg will.

"Define the solution - protocols and API requirements - for firewall and NAT traversal".

It also states:

"This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG".

We have not so far identified any missing protocol or functionality so why do you ask the work to be moved to a different group?

With regard to the full agenda I for one think we can find time for this rather than again circling through the endless discussion on some of the other topics. I am not sure also why we need 40 mins to discuss the use case updates time would be better spent finding solutions for the existing use cases.

If you think that nobody will object then surely we can get this over very quickly.

Agree there has not been enough discussion on the draft but I have received only positive feedback including some comments off list.

Regards
Andy

> Sent: 12 July 2013 16:31
> Cc: [email-masked]
> So section 3.3.1 of draft-hutton-rtcweb-nat-firewall-considerations
> provides a brief sketch of an extension to TURN clients to use a HTTP
> proxy.
> 
> I would be shocked to see anyone in this WG tell you not to do that,
> it's been discussed many times in the past. But in the end this WG will
> either say we like it, take it to BEHAVE, or it will say we hate it in
> which case as and individual draft you will still probably take it to
> BEHAVE. You probably want to keep an eye on HTTP2 stuff and
> implications to this too.
> 
> We had not much list discussion on this draft. We have an agenda very
> full of WG items that are very controversial. We could put it at the
> end of the agenda with "time permitting" but to be honest, I sort of
> doubt we would get to it. Is there some question you think you want
> feedback from this group on that we could start on this list or
> something?
> 
> I'm just trying to be realistic about the outcomes of this draft - we
> could discuss it in RTCWeb for 3 meetings before proposing a  TURN
> extension in behave but in the end I suspect we could just short
> circuit all that.
> 
> 
> > What we want to discuss is a solution to the HTTP (Proxy) only FW use
> case as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use-
> cases-and-requirements-11#section-3.2.3. This is not solved by the
> current specs.
> >
> > The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-
> firewall-considerations-01 proposes a solution based on using HTTP
> Connect and some other related browser best practice requirements but
> also discusses alternatives.
> >
> >> On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew"
> <andrew.hutton@siemens-
> >> enterprise.com>
> >> wrote:
> >>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 12 Jul 2013 10:19:06 -0700

> * All belongs to the W3C WebRTC

Would it make sense to change this list to say the following?

* JS APIs to:
** Apply a SessionDescription (created by SDP; eg received on the signaling
channel or built by JS) to the browser
** Hand a SessionDescription (serializable to SDP) generated by the browser
over to the application (for
transmission over the signaling wire presumably or for immediately applying
with setLocalDescription for some local effect)
** Influencing/modifying the contents of the SessionDescription (and thus,
SDP, when serialized to SDP)
* All belongs to the W3C WebRTC

My changes highlight a few things:
1.  The API (setLocalDescripiton, setRemoteDescription, creatOffer, etc)
doesn't work with SDP directly.  It works with RTCSessionDescription
objects.  It just happens to be that currently the only way to interact
with RTCSessionDescription objects is through SDP.  I think it's worth
remembering that distinction.

2.  SDP does not necessarily go over the wire.   It only necessarily goes
through the API between JS and browser.   I think it's worth remembering
that distinction.

3.  Calling setLocalDescription with a new SessionDescription object can
have purely local effects that don't need to be sent over the wire.  I
think it's worth remembering those cases.

> APIs that makes SDP mangling an exception, we will still see that

I think advanced JS apps are going to use every control knob they can get
to, whether it's anticipated and well-supported or not.    I think there's
a good chance that a a popular WebRTC web app will use some SDP mangling
that wasn't anticipated, but happened to work, but then the browser can't
remove it because it will break certain websites.  It could get even worse
if someone writes a popular WebRTC wrapper library that uses tricky SDP
mangling that is then used by lots of websites.  Certain SDP mangling
techniques might end up becoming a defacto standard API that can't be
removed, even if it was originally a bug.  Or worse, one browser will have
to implement the SDP mangling or even the bugs of another, because WebRTC
apps have come to rely on them.

In fact, it's already the case that Chrome and Firefox support far
different SDP manglings.  I don't think any web apps rely on that yet, but
it's only a matter of time before someone figures out "hey, if I mangle the
SDP on this browser this way and on that browser that way, I can do things
I couldn't do otherwise".  Or worse, an advanced web app developer says
"hey, I can make this work well on browser X via SDP mangling, but not on
browser Y, so I'll put a 'best used with Browser X' icon on my website".
Then that someone writes an abstraction on top of that, and then maybe
shares that with others, and it goes from there.

I think we're in a race with web developers to see if they'll figure out
SDP mangling before we provide a way to avoid SDP mangling.   Who do you
think moves faster?

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jul 2013 20:00:13 -0400

> do we ensure that this discussion actually concludes?

I can't guarantee that we'll conclude of course, but I'm hopeful we will get to a hum/vote one way or the other.  In my presentation I plan to propose a compromise, for example.  I think those against SDES will be ok with the compromise, but I'm not sure about those who want SDES.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 13 Jul 2013 14:07:17 -0400

Howdy,
Someone's asked me to explain the compromise I plan on presenting in Berlin now, so we have more time to argue over it or chew on it.  The reason I was going to wait is because I wanted to explain how I got to the point of thinking such a compromise would make sense.  So I'll try to do that in this email, which will make this email long.  Nothin' much I can do about that.

Obviously this is all my personal opinion, not that of my employer, and not a statement claiming to be objective fact, etc.

Background:
I think many people would agree that SDES has some benefits compared to DTLS for those of us wishing to interface to the SIP world.  Some of those benefits are commercial/cost factors, some are more tangible like reducing early media clipping.  Whether you agree with such benefits or not, so long as WebRTC could support SDES in a sufficiently-secure manner, there'd be less concern over having it.  Most of the arguments against SDES have been directed at whether it could in fact be "sufficiently secure".  Personally I find most of the arguments against it being secure enough to be essentially FUD, and/or also apply to DTLS-SRTP.

On the flip-side, I think the commercial/cost factor for SDES is not a strong cause, because I believe the market will bear whatever the extra cost may be. (I wasn't sure of this 2 years ago when this all started, but I'm fairly confident of it now)  And I think having only DTLS-SRTP as MTI would have a marketing benefit for WebRTC as a technology, which I value highly.

Given those personal feelings, I didn't much care either way, so long as a decision was made - although I still preferred having SDES to avoid the early media clipping problem.  So when I was going to present on this topic back in the Vancouver meeting, my last slide basically said: "If we support SDES and it turns out later we were wrong, we can always rescind it".  This was based on the notion that browsers get updated all the time, especially for security issues.

But later it occurred to me that's actually the Achilles' heel of supporting SDES in WebRTC, for those of us wanting to gateway this stuff to SIP.  Imagine if it turns out we were wrong, and some expected-or-unexpected vulnerability is exploited against some large WebRTC service provider, and makes the news/slashdot.  Browser vendors would instantly have new code removing SDES support, and browsers in devices would be updated virtually overnight - some users may take a long time to upgrade their specific browsers on their specific devices - but many of them would do so within days.  That would be untenable for a WebRTC service provider.  Even the smaller Enterprises take a long time to upgrade code on their servers, so even for them changing their gateways to suddenly support DTLS-SRTP would be unrealistic.  Imagine what it would be for larger providers, who might even have to deploy more servers to handle the sudden additional overhead of DTLS-SRTP.  Meanwhile a growing percentage of their users can no longer use the service.  That's bad mojo.

The things that a WebRTC-to-SIP service provider can control, and arguably the much larger use-case for this stuff to begin with, are not really true "browsers" anyway - they're web-based-framework device Apps, provided by the service provider to begin with.  I.e., the apps they build using web application framework things like PhoneGap/Cordova, Appcelerator Titanium, etc.  I mean using a real Browser is nice for ad-hoc stuff, like being able to click on a "talk to a rep" button on a website, or a webex/meetecho type thing; but for real communication "service", whether it be as a subscriber of a traditional carrier, or Skype, or an employee of an Enterprise, or a call-center attendant, or whatever - for those most people would never want to have to open a browser just to receive/make calls.  They'd give you an app to use instead.

So it's the app use-case that would benefit the most from SDES, especially for issues like media clipping.  And the app use-case doesn't have the security concerns nor concerns for unforeseen overnight updates.

The Compromise:
So given that background, I was planning to propose that the security doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a statement that web-based application frameworks SHOULD also support SDES. (with text about why and how, etc.)

I don't think this is too controversial, because web-based frameworks are never beholden to following browser behavior anyway - they're used to build a native application, and native applications have a very different security/threat model in practice.  They're written for a specific purpose, and installed by users from known sources for that known purpose.  Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any requirements/mandates for native applications anyway - an app maker would just ignore something they don't think applies to them - but I think web-based frameworks do generally try to follow W3C models for Javascript APIs, and will likely read the IETF RFCs for the media-layer stuff too.  So I think having this SHOULD statement would be beneficial.

Or if the WG prefers, we could even write a separate doc on what a web-based framework maker should consider supporting/not-supporting. (I can imagine a few other things they might want to offer that a browser can't)

-hadriel

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 13 Jul 2013 18:39:16 +0000

On 7/12/13 7:19 PM, Peter Thatcher wrote:
>
>
>
> On Fri, Jul 12, 2013 at 12:35 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      > On 11 July 2013 12:04, Cullen Jennings (fluffy) <[email-masked]
>     <mailto:[email-masked]>>
>      > wrote:
>      >> On Jul 11, 2013, at 10:35 AM, Emil Ivov <[email-masked]
>     <mailto:[email-masked]>>
> ** Apply a SessionDescription (created by SDP; eg received on the
> signaling channel or built by JS) to the browser
> ** Hand a SessionDescription (serializable to SDP) generated by the
> browser over to the application (for
> transmission over the signaling wire presumably or for immediately
> applying with setLocalDescription for some local effect)
> ** Influencing/modifying the contents of the SessionDescription (and
> thus, SDP, when serialized to SDP)

That might well be a better way to put it.

> 2.  SDP does not necessarily go over the wire.   It only necessarily
> goes through the API between JS and browser.   I think it's worth
> I think advanced JS apps are going to use every control knob they can
> get to, whether it's anticipated and well-supported or not.    I think
> there's a good chance that a a popular WebRTC web app will use some SDP
> mangling that wasn't anticipated, but happened to work, but then the
> browser can't remove it because it will break certain websites.  It
> could get even worse if someone writes a popular WebRTC wrapper library
> that uses tricky SDP mangling that is then used by lots of websites.
>   Certain SDP mangling techniques might end up becoming a defacto
> standard API that can't be removed, even if it was originally a bug.  Or
> worse, one browser will have to implement the SDP mangling or even the
> bugs of another, because WebRTC apps have come to rely on them.
>
> different SDP manglings.  I don't think any web apps rely on that yet,
> but it's only a matter of time before someone figures out "hey, if I
> mangle the SDP on this browser this way and on that browser that way, I
> can do things I couldn't do otherwise".  Or worse, an advanced web app
> developer says "hey, I can make this work well on browser X via SDP
> mangling, but not on browser Y, so I'll put a 'best used with Browser X'
> icon on my website". Then that someone writes an abstraction on top of
> that, and then maybe shares that with others, and it goes from there.
>

Let's go over to the public-webrtc W3C space and work on this.

>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Jul 2013 14:02:29 -0700

Hadriel --
I think you've brought up a critical point, which is very worth keeping in mind throughout the discussions in IETF RTCWEB.  That is that WebRTC is really two distinct innovations -- one, a profile of "RAI 2.0" functionality, defining a core set of RTP functionality developed over the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and the other, a set of Javascript APIs for Web browsers defined by the W3C.   IMHO,  the "RAI 2.0" aspect is likely to prove more important (and long-lived) than the W3C WEBRTC API aspect.  
Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to live on way beyond the useful life of the W3C WEBRTC APIs, it is critical that the protocol profiles not be distorted so as to cater to API concerns that will be difficult to justify, let alone remember, a decade from now.   If the damage brought about by an SDP-based API could be restricted solely to Web browsers without reflecting itself in expected "on the wire" behavior, I would care a lot less about it.  After all, the Internet knows how to deal with bad designs -  it just "treats them as damage and routes around them".    So to the extent that IETF RTCWEB can contain the SDP API swamp we'll all be better off -- and the swamp will be that much easier to drain down the road once it becomes clear to all that nobody really wants to live in that part of town anyway.  
As you state, the vast majority of customers I talk to are interested primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at all, in the W3C JS APIs.  Given the displacement of feature phones by smartphones, the growth in availability of wireless data as well as the increasing availability of connectivity that can support interactive video (all areas of very rapid growth over the next few years), the focus of realtime communications app developers I talk to is not on browser, but on the development of native applications.  And unless HTML5-based approaches such as Firefox OS gain traction, that focus is likely to remain.   
Given this, the most frequent request I hear is for a usable mobile SDK that can offer protocol compatibility with WebRTC implementations on browsers.  To succeed, that mobile SDK had better not look anything like the W3C WEBRTC API, and it also better support extensibility.  In reality, all that the IETF RTCWEB profile defines is the core set of functionality -- that set of features that MUST be supported to enable interoperability.  However, there is a lot more that a developer might want to have available for their particular application.  That might include a codec (such as AMR-NB) or a security variant such as SDES/SRTP.   Since as you note many developers aren't going to be using the W3C WEBRTC APIs anyway, whether those additional functions are supported in the W3C APIs is largely irrelevant - and so are discussions about whether this or that additional feature needs to be a "SHOULD" or a "MAY".

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 14 Jul 2013 06:58:33 +0000

On 7/13/13 11:02 PM, Bernard Aboba wrote:
> Hadriel --
>
> I think you've brought up a critical point, which is very worth keeping
> in mind throughout the discussions in IETF RTCWEB.  That is that WebRTC
> is really two distinct innovations -- one, a profile of "RAI 2.0"
> functionality, defining a core set of RTP functionality developed over
> the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF,
> etc.), and the other, a set of Javascript APIs for Web browsers defined
> by the W3C.IMHO,  the "RAI 2.0" aspect is likely to prove more
 > important (and long-lived) than the W3C WEBRTC API aspect.

I think that the Javascript APIs are going to be very important, but I 
fully agree that the "RAI 2.0" profile defined will be used beyond 
browsers. And I think that the more self contained (i.e. not dependent 
on other signaling during operation) we can make that RAI 2.0 profile 
the better.

So I am again arguing for pushing things like pause/resume signaling to 
RTP/RCTP, and not depend on out of band exchanges of signaling messages.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 14 Jul 2013 10:38:10 -0400

> on other signaling during operation) we can make that RAI 2.0 profile
This point, even though valid, might have unintended consequences. For
instance, if support for RTP based real time text in web browsers is
questionable, due to other ways to implement it via existing communications
channels, it should probably be part of "RAI 2.0". I think there are going
to be quite a few features, which will not be part of core webrtc
functionality which will fall into "RAI 2.0" category. Discussing these
features can slow down this group even more then it already is, and is most
likely be outside of this group charter.

Furthermore, according to the same logic, Hadriel's compromise can be
boiled down to not supporting SDES in WebRTC, with all the other language
essentially discussing things that will not controlled by WebRTC drafts and
lay outside this group charter.
_____________
Roman Shpount

---

From: Hrishikesh Kulkarni <[email-masked]>
Date: Sun, 14 Jul 2013 22:33:29 +0530

Very interesting discussion and important thread. I have a comment on JS
API's.

On Sun, Jul 14, 2013 at 2:32 AM, Bernard Aboba <[email-masked]>wrote:

> Hadriel --
>
> .....
>
> As you state, the vast majority of customers I talk to are interested
> primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at
> all, in the W3C JS APIs.  Given the displacement of feature phones by
> smartphones, the growth in availability of wireless data as well as the
> increasing availability of connectivity that can support interactive video
> (all areas of very rapid growth over the next few years), the focus of
> realtime communications app developers I talk to is not on browser, but on
> the development of native applications.  And unless HTML5-based approaches
> such as Firefox OS gain traction, that focus is likely to remain.
>
>
WebRTC JS API's has the potential to make video/audio based web apps the
first class citizens of internet. Focus on interop at the media plane and
signaling plane is important. But it is critical to focus and bring better
JS API's to browser and browser frameworks. I am startup and many customers
I talk to are asking for video web apps on Internet explorer which
unfortunately is lacking as compared to Chrome and Firefox (both of which
are available on mobile too).

regards,
Rishi
OneKlikStreet.com

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 15 Jul 2013 05:46:34 -0700

On Sat, Jul 13, 2013 at 2:02 PM, Bernard Aboba <[email-masked]>wrote:

> Hadriel --
>
> I think you've brought up a critical point, which is very worth keeping in
> mind throughout the discussions in IETF RTCWEB.  That is that WebRTC is
> really two distinct innovations -- one, a profile of "RAI 2.0"
> functionality, defining a core set of RTP functionality developed over the
> last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and
> the other, a set of Javascript APIs for Web browsers defined by the W3C.   IMHO,
>  the "RAI 2.0" aspect is likely to prove more important (and long-lived)
> than the W3C WEBRTC API aspect.
>
> Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to
> live on way beyond the useful life of the W3C WEBRTC APIs, it is critical
> that the protocol profiles not be distorted so as to cater to API concerns
> that will be difficult to justify, let alone remember, a decade from now.
> If the damage brought about by an SDP-based API could be restricted
> solely to Web browsers without reflecting itself in expected "on the wire"
> behavior, I would care a lot less about it.  After all, the Internet
> knows how to deal with bad designs -  it just "treats them as damage and
> routes around them".    So to the extent that IETF RTCWEB can contain the
> SDP API swamp we'll all be better off -- and the swamp will be that much
> easier to drain down the road once it becomes clear to all that nobody
> really wants to live in that part of town anyway.
>
>

> Given this, the most frequent request I hear is for a usable mobile SDK
> that can offer protocol compatibility with WebRTC implementations on
> browsers.  To succeed, that mobile SDK had better not look anything like
> the W3C WEBRTC API, and it also better support extensibility.
>

Chrome's implementation of WebRTC, which can be found at webrtc.org, has a
mobile SDK that can be used to build mobile apps (Android and iOS, at
least).  Some well-known and popular RTC mobile apps are in large part
built on that code and can interop to a degree with browsers.  So in some
sense, you already have what you want.

The big problem is that the high-level API offered by that SDK exactly
matches the one in the browser, which means it's the gross SDP-based one.
 And none of the mobile apps I know, beyond an example app, use that API,
or have plans to, precisely because it's gross.  Instead, as far as I know,
they dig deeper into the code and avoid that part. (why jam everything
through SDP if you don't have to?).

I think the optimal scenario for us to target is to define a good API that
is the same between mobile and web browsers.  I think that would help
developers the most.  Making such a "web and mobile" API is probably out of
scope for any WG, but I think that if we defined a good (non SDP-based) API
for the browser, it could easily be exposed as a native SDK (just like it
is now), but be much less gross and more usable.

I don't know if such a thing (a good API for both mobile and web) can
realistically ever happen, but in the meantime, you can at least pick up
the code at webrtc.org and make a mobile app.  It's open source, too, so if
you want to make a better API than what's there, go ahead and write one :).

In reality, all that the IETF RTCWEB profile defines is the core set of
> functionality -- that set of features that MUST be supported to enable
> interoperability.  However, there is a lot more that a developer might want
> to have available for their particular application.  That might include a
> codec (such as AMR-NB) or a security variant such as SDES/SRTP.   Since as
> you note many developers aren't going to be using the W3C WEBRTC APIs
> anyway, whether those additional functions are supported in the W3C APIs is
> largely irrelevant - and so are discussions about whether this or that
> additional feature needs to be a "SHOULD" or a "MAY".
>

FYI, the code at webrtc.org supports SDES/SRTP, and while it doesn't have
support for AMR-NB (as far as I know), it does have a system for adding new
codecs, so you could theoretically take an implementation of AMR-NB and
compile it in yourself to make a mobile app.  It may not be very easy, but
it is possible.

>
>
> > So given that background, I was planning to propose that the security
> doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a
> statement that web-based application frameworks SHOULD also support SDES.
> (with text about why and how, etc.)
> >
> > I don't think this is too controversial, because web-based frameworks
> are never beholden to following browser behavior anyway - they're used to
> build a native application, and native applications have a very different
> security/threat model in practice. They're written for a specific purpose,
> and installed by users from known sources for that known purpose.
> Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have
> any requirements/mandates for native applications anyway - an app maker
> would just ignore something they don't think applies to them - but I think
> web-based frameworks do generally try to follow W3C models for Javascript
> APIs, and will likely read the IETF RFCs for the media-layer stuff too. So
> I think having this SHOULD statement would be beneficial.
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 15 Jul 2013 13:46:21 -0700

Hello Chairs

  I was wondering if we could add "RTCWeb SDP Examples" draft to the Agenda
that shows several SDP examples for the most common WebRTC Use-cases.

The draft location is :
http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-02

Thanks
Suhas

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 16 Jul 2013 13:22:30 +0000

> On: 13 July 2013 19:07 Hadriel Kaplan Wrote:
> To: [email-masked]
> Subject: [rtcweb] A compromise for SDES
> 
> Howdy,
> Someone's asked me to explain the compromise I plan on presenting in
> Berlin now, so we have more time to argue over it or chew on it.  The
> reason I was going to wait is because I wanted to explain how I got to
> the point of thinking such a compromise would make sense.  So I'll try
> to do that in this email, which will make this email long.  Nothin'
> much I can do about that.
> 
> Obviously this is all my personal opinion, not that of my employer, and
> not a statement claiming to be objective fact, etc.
> 
> Background:
> I think many people would agree that SDES has some benefits compared to
> DTLS for those of us wishing to interface to the SIP world.  Some of
> those benefits are commercial/cost factors, some are more tangible like
> reducing early media clipping.  Whether you agree with such benefits or
> not, so long as WebRTC could support SDES in a sufficiently-secure
> manner, there'd be less concern over having it.  Most of the arguments
> against SDES have been directed at whether it could in fact be
> "sufficiently secure".  Personally I find most of the arguments against
> it being secure enough to be essentially FUD, and/or also apply to
> DTLS-SRTP.
> 
> On the flip-side, I think the commercial/cost factor for SDES is not a
> strong cause, because I believe the market will bear whatever the extra
> cost may be. (I wasn't sure of this 2 years ago when this all started,
> but I'm fairly confident of it now)  And I think having only DTLS-SRTP
> as MTI would have a marketing benefit for WebRTC as a technology, which
> I value highly.

There is a significant cost factor in scenarios where a large percentage of sessions have to be interworked and whether the market will bear this or not it is certainly a cost that it would be good to avoid. 

> 
> Given those personal feelings, I didn't much care either way, so long
> as a decision was made - although I still preferred having SDES to
> avoid the early media clipping problem.  So when I was going to present
> on this topic back in the Vancouver meeting, my last slide basically
> said: "If we support SDES and it turns out later we were wrong, we can
> always rescind it".  This was based on the notion that browsers get
> updated all the time, especially for security issues.
> 
> But later it occurred to me that's actually the Achilles' heel of
> supporting SDES in WebRTC, for those of us wanting to gateway this
> stuff to SIP.  Imagine if it turns out we were wrong, and some
> expected-or-unexpected vulnerability is exploited against some large
> WebRTC service provider, and makes the news/slashdot.  Browser vendors
> would instantly have new code removing SDES support, and browsers in
> devices would be updated virtually overnight - some users may take a
> long time to upgrade their specific browsers on their specific devices
> - but many of them would do so within days.  That would be untenable
> for a WebRTC service provider.  Even the smaller Enterprises take a
> long time to upgrade code on their servers, so even for them changing
> their gateways to suddenly support DTLS-SRTP would be unrealistic.
> Imagine what it would be for larger providers, who might even have to
> deploy more servers to handle the sudden additional overhead of DTLS-
> SRTP.  Meanwhile a growing perc
>  entage of their users can no longer use the service.  That's bad mojo.
> 
> The things that a WebRTC-to-SIP service provider can control, and
> arguably the much larger use-case for this stuff to begin with, are not
> really true "browsers" anyway - they're web-based-framework device
> Apps, provided by the service provider to begin with.  I.e., the apps
> they build using web application framework things like
> PhoneGap/Cordova, Appcelerator Titanium, etc.  I mean using a real
> Browser is nice for ad-hoc stuff, like being able to click on a "talk
> to a rep" button on a website, or a webex/meetecho type thing; but for
> real communication "service", whether it be as a subscriber of a
> traditional carrier, or Skype, or an employee of an Enterprise, or a
> call-center attendant, or whatever - for those most people would never
> want to have to open a browser just to receive/make calls.  They'd give
> you an app to use instead.
> 
> So it's the app use-case that would benefit the most from SDES,
> especially for issues like media clipping.  And the app use-case
> doesn't have the security concerns nor concerns for unforeseen
> overnight updates.
> 
> The Compromise:
> statement that web-based application frameworks SHOULD also support
> SDES. (with text about why and how, etc.)

I don't think we can or should say that SDES SHOULD be implemented by one type of framework but not another we just need to say something consistent for all. I agree with most of what is stated in the reasoning above and given that there is a strong commercial incentive for SDES support I think keeping DTLS-SRTP as the MTI and making SDES a SHOULD would be a good compromise. 

> are never beholden to following browser behavior anyway - they're used
> to build a native application, and native applications have a very
> different security/threat model in practice.  They're written for a
> specific purpose, and installed by users from known sources for that
> known purpose.  Technically, afaik, nothing we do in RTCWEB WG or W3C's
> WEBRTC group have any requirements/mandates for native applications
> anyway - an app maker would just ignore something they don't think
> applies to them - but I think web-based frameworks do generally try to
> follow W3C models for Javascript APIs, and will likely read the IETF
> RFCs for the media-layer stuff too.  So I think having this SHOULD
> statement would be beneficial.
> 
> Or if the WG prefers, we could even write a separate doc on what a web-
> based framework maker should consider supporting/not-supporting. (I can
> imagine a few other things they might want to offer that a browser
> can't)
> 
> -hadriel
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 16 Jul 2013 16:06:15 +0200

> I don't think we can or should say that SDES SHOULD be implemented by one type of framework but not another we just need to say something consistent for all. I agree with most of what is stated in…
I also agree with most of what Hadriel stated in his long mail;
however I don't like the idea we start to make difference between what 
kind of webrtc you can do
with a browser and what you can do on a web-based application framework
(btw I also share the Andrew concern about the fact that we can/should 
say what to do or not to do
in each type of framework)

/Salvatore

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 17 Jul 2013 20:48:55 +0000

Hadriel Kaplan:
> Berlin now, so we have more time to argue over it or chew on it.  The reason
> I was going to wait is because I wanted to explain how I got to the point of
> thinking such a compromise would make sense.  So I'll try to do that in this
> email, which will make this email long.  Nothin' much I can do about that.
> 
> Obviously this is all my personal opinion, not that of my employer, and not a
> statement claiming to be objective fact, etc.

Likewise, in this reply where, though I like you, I don't like your proposal.

> DTLS for those of us wishing to interface to the SIP world.  Some of those
> benefits are commercial/cost factors, some are more tangible like reducing
> early media clipping.  Whether you agree with such benefits or not, so long as
> WebRTC could support SDES in a sufficiently-secure manner, there'd be less
> concern over having it.  Most of the arguments against SDES have been
> directed at whether it could in fact be "sufficiently secure".  Personally I find
> most of the arguments against it being secure enough to be essentially FUD,
> and/or also apply to DTLS-SRTP.

I believe that once the entire system is considered, any system that allows EKT shares the same security properties as one that allows SDES, and one that does not allow EKT requires a decrypt/re-encrypt phase at the gateway that is costly.

> 
> On the flip-side, I think the commercial/cost factor for SDES is not a strong
> cause, because I believe the market will bear whatever the extra cost may
> be. (I wasn't sure of this 2 years ago when this all started, but I'm fairly
> confident of it now)  And I think having only DTLS-SRTP as MTI would have a
> marketing benefit for WebRTC as a technology, which I value highly.

The market might bear the extra cost, but it doesn't mean that it isn't extra cost (and extra environmental damage through the extra energy consumed).

> 
> Given those personal feelings, I didn't much care either way, so long as a
> decision was made - although I still preferred having SDES to avoid the early
> media clipping problem.  So when I was going to present on this topic back in
> the Vancouver meeting, my last slide basically said: "If we support SDES and it
> turns out later we were wrong, we can always rescind it".  This was based on
> the notion that browsers get updated all the time, especially for security
> issues.
> 
> But later it occurred to me that's actually the Achilles' heel of supporting SDES
> in WebRTC, for those of us wanting to gateway this stuff to SIP.  Imagine if it
> turns out we were wrong, and some expected-or-unexpected vulnerability is
> exploited against some large WebRTC service provider, and makes the
> news/slashdot.  Browser vendors would instantly have new code removing
> SDES support, and browsers in devices would be updated virtually overnight -
> some users may take a long time to upgrade their specific browsers on their
> specific devices - but many of them would do so within days.  That would be
> untenable for a WebRTC service provider. 

I can't imagine such a scenario that couldn't also happen with DTLS-SRTP, especially DTLS-SRTP + EKT.

Plus there's lots of counterexamples where major sites have been compromised in ways that could have been fixed browser-side, and yet browsers didn't bother to update.

And finally, what makes you think that the browser vendors would do something like that if the service really was popular? I guess if Google and Mozilla wanted everyone using Skype to switch to Internet Explorer they could pull such a stunt, but why? (In a hypothetical future where IE has webrtc support and Skype supports webrtc-equipped browsers as a platform for calling, of course)

> Even the smaller Enterprises take
> a long time to upgrade code on their servers, so even for them changing their
> gateways to suddenly support DTLS-SRTP would be unrealistic.  Imagine what
> it would be for larger providers, who might even have to deploy more
> servers to handle the sudden additional overhead of DTLS-SRTP.  Meanwhile
> a growing perc  entage of their users can no longer use the service.  That's
> bad mojo.

I argue that it'd never happen.

> 
> The things that a WebRTC-to-SIP service provider can control, and arguably
> the much larger use-case for this stuff to begin with, are not really true
> "browsers" anyway - they're web-based-framework device Apps, provided
> by the service provider to begin with.  I.e., the apps they build using web
> application framework things like PhoneGap/Cordova, Appcelerator
> Titanium, etc.  I mean using a real Browser is nice for ad-hoc stuff, like being
> able to click on a "talk to a rep" button on a website, or a webex/meetecho
> type thing; but for real communication "service", whether it be as a
> subscriber of a traditional carrier, or Skype, or an employee of an Enterprise,
> or a call-center attendant, or whatever - for those most people would never
> want to have to open a browser just to receive/make calls.  They'd give you
> an app to use instead.
> 
> So it's the app use-case that would benefit the most from SDES, especially for
> issues like media clipping.  And the app use-case doesn't have the security
> concerns nor concerns for unforeseen overnight updates.

And will probably support SDES.

> 
> The Compromise:
> So given that background, I was planning to propose that the security doc
> keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a

Disagree. That leads immediately to half (approximately) of the browser ecosystem not supporting SDES. That increases my cost for no true security benefit to anyone.

> 
> I don't think this is too controversial, because web-based frameworks are
> never beholden to following browser behavior anyway - they're used to
> security/threat model in practice.  They're written for a specific purpose, and
> installed by users from known sources for that known purpose.  Technically,
> afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any
> requirements/mandates for native applications anyway - an app maker
> APIs, and will likely read the IETF RFCs for the media-layer stuff too.  So I
> think having this SHOULD statement would be beneficial.
> 
> imagine a few other things they might want to offer that a browser can't)

They might be able to turn ICE off, even!

Matthew Kaufman

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 17 Jul 2013 16:43:28 -0500

On Wed, Jul 17, 2013 at 3:48 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> reason
> not a
> those
> I believe that once the entire system is considered, any system that
> allows EKT shares the same security properties as one that allows SDES, and
> one that does not allow EKT requires a decrypt/re-encrypt phase at the
> gateway that is costly.
>
> >
> strong
> The market might bear the extra cost, but it doesn't mean that it isn't
> extra cost (and extra environmental damage through the extra energy
> consumed).
>
> >
> supporting SDES
> Plus there's lots of counterexamples where major sites have been
> compromised in ways that could have been fixed browser-side, and yet
> browsers didn't bother to update.
>
> And finally, what makes you think that the browser vendors would do
> something like that if the service really was popular? I guess if Google
> and Mozilla wanted everyone using Skype to switch to Internet Explorer they
> could pull such a stunt, but why? (In a hypothetical future where IE has
> webrtc support and Skype supports webrtc-equipped browsers as a platform
> for calling, of course)
>
> arguably
> especially for
> Disagree. That leads immediately to half (approximately) of the browser
> ecosystem not supporting SDES. That increases my cost for no true security
> benefit to anyone.
>
> >

Amen.  I think ICE will be the first barrier to initiating communications
with legacy equipment anyways... Anybody that can get past the ICE step
will then be allowed to deal with the problems of the mandatorily included
encryption mechanisms as a next step.

I don't know if there is very much "legacy" equipment that will be able to
interop with WebRTC media sessions without some sort of translation.

Matthew Fredrickson

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Jul 2013 12:24:22 -0400

> I can't imagine such a scenario that couldn't also happen with DTLS-SRTP, especially DTLS-SRTP + EKT.

Yes, I considered that as well - but if there's only one key-exchange mechanism, and it's the one used between browsers and everyone, then even the browser vendors wouldn't want to update the browsers in such a way that it's removed overnight.  They'd be braking media interop even between browsers.

For example, assume we only have DTLS-SRTP as MTI and some security vulnerability is discovered for it, which some new thing called "ETLS-SRTP" fixes.  They couldn't just remove DTLS-SRTP in favor of ETLS-SRTP overnight; they'd have to support both for some transition period - a period only constrained by the rate at which most browsers get updated.  After that it could be disabled by default and require the user to enable, or pop up some warning thingy to approve; and ultimately removed altogether someday.

But with SDES, we're basically asking the browsers to implement something they don't need to implement for browser-to-browser uses. (in fact, we'd define it in such a way that SDES wouldn't be used for browser-to-browser cases)  Unless some major service like Skype uses SDES, browsers vendors have no real market force keeping them supporting it.  The ones involved in this WG have already said they don't consider the WebRTC-SIP use case very important in the grand scheme of things.

> Plus there's lots of counterexamples where major sites have been compromised in ways that could have been fixed browser-side, and yet browsers didn't bother to update.

Some browsers won't update, for sure - but that's the problem with these things: it's a lowest-common-denominator model, because having media work is not an optional feature.  If you want to support all (major) browsers, you need to do what all of them can do.  You'd have to support DTLS-SRTP somehow, if even one of the major browser vendors only do DTLS-SRTP.

Sure you can save some cost by tracking how many people use what browsers, and deploying for the ratio of DTLS-SRTP vs. SDES you expect, etc.  And that will work for some operators of WebRTC sites/gateways (though not all).  But it still detracts from the arguments I and others have been making about what the benefits of having SDES would be.

> And finally, what makes you think that the browser vendors would do something like that if the service really was popular? I guess if Google and Mozilla wanted everyone using Skype to switch to Int…

If there's a really popular service using SDES, like let's say Skype, I would expect the browser vendors to keep SDES support optional with a configuration thingy; or to keep it by default but only until Skype switched away from SDES.[1]  And I bet Skype would switch away quickly, if a security vulnerability made the press/slashdot.  

My point wasn't that it would literally happen in 24 hours - it was more that such a change is uncontrollable by all the operators of WebRTC sites/gateways.  Skype might be big enough to keep browsers from removing SDES, but that just moves the problem around: now all the other WebRTC sites/gateways have to change to using DTLS-SRTP when Skype changes.  Either way, they can't control their own destiny.

> They might be able to turn ICE off, even!

Yup.  That would be #2 on the list of things an app should be able to do, right after using SDES. (or maybe the priority should even be swapped)

-hadriel
[1] having said that, there have been cases where the market power of a browser overcame the market power of a really popular service - like Apple's iOS-based Safari's lack of Flash support, with respect to YouTube service.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 20 Jul 2013 01:22:52 +0530

Hi Hadriel & all,

I agree with Hadriel that DTLS-SRTP as MTI has market benefit but still I'm
not seeing much difference in terms of end-user security. I was supporting
DTLS-SRTP earlier as MTI as WebRTC signaling may takes place in HTTP. In
reality, HTTPS is expected by webrtc operator as they are worried about Web
signaling Security (on-path attack). In case of HTTPS based WebRTC signaling
traffic is used, I'm not seeing any difference between DTLS-SRTP & SDES
because it is possible to intercept the traffic by web provider (signaling
server) in case the web provider is intended to do so as mentioned in Sec
5.7.1. of draft-ietf-rtcweb-security-arch-07. Dr.Evil website shall design
as follows:

     -----Web Server & IdP-----
    |            |             |
Browser------B2BMGW------Browser

Back to back media gateway (B2BMGW) has the capability to terminate and
originate DTLS-SRTP webrtc media traffic without informing browser. Please
look into http://www.webrtc2sip.org/ for how easy to design such B2BMGW. 

The identity is not mandatory in WebRTC. Webrtc session request using HTTPS
URL like https://apprtc.appspot.com/?r=80112689 works well and it has good
web application like conference link. So, there is no much difference
between DTLS-SRTP & SDES-SRTP in case of no identity scenario. Even if the
identity is mandated using Idp, Dr.Evil provider shall mandate authoritative
Idp as (@drevil.com) which helps to intercept the media in B2BMGW. I could
not understand why Dr.Evil web provider will provide the mechanism for
establishing webrtc session using third party identity provider. As of now,
I'm not very clear how webrtc security trust model with DTLS-SRTP really
benefit browser user in terms of security whereas SDES-SRTP compromise the
security.

I see the difference between SDES-SRTP & DTLS-SRTP in case HTTP origin. So
apart of Hadriel compromise plan, some of the SDES compromise plan could be 

1) forbid HTTP origin when SDES is requested by API
2) forbid HTTP origin entirely and allow SDES-SRTP as one of the security
key mechanism. Let application selects its preferred security key mechanism.

Thanks
Partha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Saturday, July 13, 2013 11:37 PM
> To: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 27 Jul 2013 15:59:47 +0200

I'm a bit confused about your proposal. 

From a RTCWeb WG point of view, it seems that the key question is what are we suggesting that things that implement WebRTC (including browsers) do? Are you proposing that SDES in browsers be optional, mandatory, or not allowed?

On Jul 13, 2013, at 11:07 AM, Hadriel Kaplan <[email-masked]> wrote:

> But later it occurred to me that's actually the Achilles' heel of supporting SDES in WebRTC, for those of us wanting to gateway this stuff to SIP.  Imagine if it turns out we were wrong, and some expected-or-unexpected vulnerability is exploited against some large WebRTC service provider, and makes the news/slashdot.  Browser vendors would instantly have new code removing SDES support, and browsers in devices would be updated virtually overnight - some users may take a long time to upgrade their specific browsers on their specific devices - but many of them would do so within days.  That would be untenable for a WebRTC service provider.  Even the smaller Enterprises take a long time to upgrade code on their servers, so even for them changing their gateways to suddenly support DTLS-SRTP would be unrealistic.  Imagine what it would be for larger providers, who might even have to deploy more servers to handle the sudden additional overhead of DTLS-SRTP.  Meanwhile a growing perc