Subject: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Apr 2013 09:57:17 -0600

The working groups committed some time ago to have a further discussion on whether SDP Security Descriptions (RFC 4568 aka SDES) would be usable as a keying method for WebRTC.  As we prepare for that discussion, we'd like to have expressions of interest or support for that approach which indicate the general outlines of support proposed.  If you wish to make such an expression of support, please send it to the chairs or the list.

Cullen, Magnus, & Ted <The Chairs>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 25 Apr 2013 12:39:30 -0400

I'm not a fan of SDES. However, I've come to believe that we need it for two reasons. 

1. There is a backwards compatibility reason. There are deployed systems of SRTP that use SDES or a key agreement that easily maps to it. Just as we allowed G.711 for these systems, it seems reasonable to allow SDES as well. When combined with ICE Lite in a media gateway, this is a scalable interop approach. 

2. We need it or something like it for API reasons. There are cases where the JavaScript needs to tell the browser what SRTP key to use. Since JSEP uses SDP for this API surface, SDES works for this. Obviously it is a bad idea to send this key over unsecured channels, but this is separate from this API issue. 

And just to be clear, browser to browser should use DTLS-SRTP, and only thus mode should be considered "secure" using whatever user interface a browser chooses. 

- Alan -

On Apr 25, 2013, at 11:57 AM, Cullen Jennings <[email-masked]> wrote:

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Apr 2013 11:10:48 -0700

I agree with Alan. At this point, at least one implementation supports both SRTP/SDES as well as DTLS/SRTP and I think this approach is probably the best way forward.

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Thu, 25 Apr 2013 16:20:41 -0400

We would like to support the use of SDES as a keying method for WebRTC.

Kalyani Bogineni
Verizon

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 25 Apr 2013 20:27:51 +0000

I agree. The ability to set the cipher suite and keys from JavaScript is critical for certain applications. SDES is the best we'll get with SDP as the API. DTLS-SRTP-only would be unacceptably limiting.

Matthew Kaufman

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bogineni, Kalyani
> Sent: Thursday, April 25, 2013 1:21 PM
> To: 'Cullen Jennings'; [email-masked]
> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> 
> The working groups committed some time ago to have a further discussion
> on whether SDP Security Descriptions (RFC 4568 aka SDES) would be usable
> as a keying method for WebRTC.  As we prepare for that discussion, we'd like
> to have expressions of interest or support for that approach which indicate
> the general outlines of support proposed.  If you wish to make such an
> expression of support, please send it to the chairs or the list.
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 25 Apr 2013 21:55:20 +0000

I also agree that we should support SDES in addition to DTLS-SRTP.

This raises a further question about SCTP/DTLS for DataChannels.  It seems that if we support SDES-SRTP, don't we also need to provide an SDES keying mechanism for DataChannels?  Ekr: What is needed to realize this?

Richard Ejzak

> Behalf Of Matthew Kaufman (SKYPE)
> Sent: Thursday, April 25, 2013 3:28 PM
> To: Bogineni, Kalyani; 'Cullen Jennings'; [email-masked]
> I agree. The ability to set the cipher suite and keys from JavaScript
> is critical for certain applications. SDES is the best we'll get with
> SDP as the API. DTLS-SRTP-only would be unacceptably limiting.
> 
> Matthew Kaufman
> 
> > Behalf Of Cullen Jennings
> > The working groups committed some time ago to have a further
> > discussion on whether SDP Security Descriptions (RFC 4568 aka SDES)
> > would be usable as a keying method for WebRTC.  As we prepare for
> that
> > discussion, we'd like to have expressions of interest or support for
> > that approach which indicate the general outlines of support
> proposed.
> > If you wish to make such an expression of support, please send it to
> the chairs or the list.
> >

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 25 Apr 2013 18:06:11 -0400

+1 (From someone who had proposed this, as an option, 100,000 messages 
before)

Igor
>> Cullen, Magnus,&  Ted<The Chairs>
>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 15:11:11 -0700

> This raises a further question about SCTP/DTLS for DataChannels.  It seems that if we support SDES-SRTP, don't we also need to provide an SDES keying mechanism for DataChannels?  Ekr: What is neede…

Data channels use the DTLS record layer, so using SDES for those would
be harder than I think you want.

Data channels can continue to use DTLS even though media is encrypted
using keys provided by security descriptions.

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Apr 2013 15:14:55 -0700

> 1. There is a backwards compatibility reason. There are deployed systems of SRTP that use SDES or a key agreement that easily maps to it. Just as we allowed G.711 for these systems, it seems reason…

Interworking at scale can be accomplished without SDES on WEBRTC, as I explained at IETF83 in slides 27-35 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf.

> 2. We need it or something like it for API reasons. There are cases where the JavaScript needs to tell the browser what SRTP key to use.

DTLS-SRTP with EKT can also perform that function, and does it without disclosing the SRTP key to all the SIP proxies and all the web servers on the signaling path.

> Since JSEP uses SDP for this API surface, SDES works for this. Obviously it is a bad idea to send this key over unsecured channels, but this is separate from this API issue. 
> 

But is there a secure mechanism to differentiate browser-to-browser calls from browser-to-non-browser calls, so we don't have to worry over SDES downgrade attacks?  And for the use-cases where JavaScript has to set the key, those will often be browser-to-browser calls, meaning that we will have to support browser-to-browser SDES, contrary to your desire that browser-to-browser use DTLS-SRTP?  DTLS-SRTP with EKT permits the application to set the SRTP key, and more securely than SDES.

-d

---

From: Mandeep Singh <[email-masked]>
Date: Thu, 25 Apr 2013 22:19:11 +0000

I believe SDES (besides DTLS-SRTP) is good idea for backward compatibility and interoperability reason.
However for browser to browser communication, DTLS-SRTP should be preferred.

Mandeep Singh

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Apr 2013 17:20:17 -0500

> using keys provided by security descriptions.

The arguments for SDES fall into two categories, AFAICT: (1) Those 
required for interop with legacy devices, and (2) those which we are 
prohibited by RFC 2804 from considering. And there is no possible way 
DataChannels are going to interop with legacy devices.

I agree with Alan that we shouldn't make accommodations to use SDES for 
the brower-to-browser case. By implication, this means that the presence 
of DataChannels necessarily means that we're using DTLS-SRTP for the 
whole session. Given those assumptions, the mixed-session scenario you 
describe does not arise.

/a

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 15:22:34 -0700

On 25 April 2013 15:20, Adam Roach <[email-masked]> wrote:
> The arguments for SDES fall into two categories, AFAICT: (1) Those required
> for interop with legacy devices, and (2) those which we are prohibited by
> RFC 2804 from considering. And there is no possible way DataChannels are
> going to interop with legacy devices.

That isn't an exhaustive list.  I intend to write down a couple of
other items to add to that list.

> I agree with Alan that we shouldn't make accommodations to use SDES for the
> brower-to-browser case. By implication, this means that the presence of
> DataChannels necessarily means that we're using DTLS-SRTP for the whole
> session. Given those assumptions, the mixed-session scenario you describe
> does not arise.

Regardless of the outcome of above, that's a constraint I'd be willing
to tolerate.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 25 Apr 2013 22:39:53 +0000

Legacy devices support more than just audio and video media.  We will need to occasionally transport protocols like T.140, MSRP, BFCP, and/or RTSP in some cases, and the primary options are to transport them over DataChannels or WebSockets.  A network server will be needed to do transport level interworking, of course.  It would be useful in these cases to have an SDES option for DataChannels.  Not essential, but useful.  End-to-end security is not even an issue in this case due to the need for transport level interworking.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, April 25, 2013 5:20 PM
> To: Martin Thomson
> Cc: Ejzak, Richard P (Richard); [email-masked]
> the brower-to-browser case. By implication, this means that the
> presence of DataChannels necessarily means that we're using DTLS-SRTP
> for the whole session. Given those assumptions, the mixed-session
> scenario you describe does not arise.
> 
> /a

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 16:01:30 -0700

The case for SDES has thus far been summarized as (borrowing Adam's words):

(1) Those required for interop with legacy devices, and
(2) those which we are prohibited by RFC 2804 from considering.

Reason (1) is a fairly big deal.  There are other reasons:

Performance - A DTLS handshake takes a fair bit of CPU time,
especially on the passive (server) peer, and two round trips.  The CPU
cost might not be that big of a deal (SBC vendors may disagree), but
round trips hurt.

Conferencing Scenarios - Ensuring that streams can be mixed,
translated and still decoded for a multi-leg conference is just easier
with security descriptions.

It's true that conferencing scenarios can be addressed by EKT, but EKT
has similar 2804 properties as security descriptions.  It would not be
permissible to use EKT for a peer identity bound session because it
makes the media accessible to signaling intermediaries (read: the web
site).

As long as you are in that state, EKT doesn't really provide that
much.  Bid-down protection seems lame when the site has access to the
keys.

Practical Matters of Security - You aren't necessarily more secure
because you are using DTLS-SRTP.  The complete security story requires
not just DTLS-SRTP, but also that both peers use identity assertions.
Otherwise its security properties are basically the same as security
descriptions.

The default mode of operation for getUserMedia is to return media that
is accessible to the web site.  The same for RTCPeerConnection.  That
means that the site can see and modify your media in your browser,
even if it can't tamper with it on the network.

I'm sympathetic to having DTLS-SRTP available to enable these secure
scenarios.  That's not at issue.  But the reasons for DTLS-SRTP only
largely come down to just having less code. And seriously, it's not
even that much less.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Apr 2013 16:19:21 -0700

On Thu, Apr 25, 2013 at 4:01 PM, Martin Thomson <[email-masked]>wrote:
[snip]

I think we've discussed most of the topics Martin raises already and I'm
not sure I have much to add (which isn't to say I necessarily agree).

However, I think the below is incorrect and I'm not sure I have made
that point before.

> even if it can't tamper with it on the network.

It's certainly true that the site has access to the media with DTLS if you
don't use identity assertions/isolated streams. However, what it doesn't
have is *invisible* access. I.e., it must do something that is user visible,
which allows for the detection of cheating by the site. By contrast, if
SDES is used
then the site can simply passively monitor all your traffic, or at least
any that goes through its network and you can't detect it.

-Ekr

---

From: Randell Jesup <[email-masked]>
Date: Thu, 25 Apr 2013 19:33:58 -0400

On 4/25/2013 7:19 PM, Eric Rescorla wrote:
> On Thu, Apr 25, 2013 at 4:01 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
> [snip]
>
> which allows for the detection of cheating by the site. By contrast, 
> if SDES is used

Or they can simply store off the key to be used to offline-decrypt raw 
traffic captured at an ISP, at their leisure.  SDES is basically 
"protect against WiFi sniffers" encryption.  Ironically, Apple's 
messaging stuff apparently uses strong end-to-end encryption (the 
wonders of not caring about legacy interop).

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 16:34:06 -0700

> not sure I have much to add (which isn't to say I necessarily agree).

I just wanted them on the record.

> which allows for the detection of cheating by the site. By contrast, if SDES
> is used

That's a fair point, and one I missed.  My bad.  But it's only
relevant to the extent that it is possible to observe that the
provided certificate is a phony.  It's not like the server is
obligated to provide a particular CN, so it's mostly down to just
looking at fingerprints.

It's also hard to retroactively audit due to the way (current)
implementations mint new certificates for every interaction.  I'm
fairly sure that (current) implementations don't make this
particularly easy to examine in browser chrome, but even if they did
it's hard to imagine a good usability story for accessing the
information.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 25 Apr 2013 19:40:31 -0400

> I agree. The ability to set the cipher suite and keys from JavaScript is critical for certain applications. SDES is the best we'll get with SDP as the API. DTLS-SRTP-only would be unacceptably limi…

So, the problems with SDES (discussed to a fare-the-well every 3 months 
for the last 1.75 years or more, so there's nothing really new here):

It exposes security keys directly to the application (or takes them from 
there).  Basically, you're back in "all your media is totally in trust 
to the application and website".  The keys aren't even end-2-end 
encrypted or even authenticated.  And even if you expose SDES bid-downs 
to the user, they don't know what they mean or how to process this 
information.

SDES basically means to me "secure against random WiFi sniffers at the 
coffeeshop", and little more than that.  I realize carriers and others 
like SDES because they make certain uses and obligations easy for them 
to meet, and interop with legacy devices and systems easier (though many 
such legacy interop systems will perforce need gateways anyways, and 
those gateways can convert from DTLS-SRTP to SDES.

Yes, some gateway scenarios might be cheaper/easier with SDES, but I see 
the primary use-cases for WebRTC to be browser-to-browser, not 
browser-legacy.  Certainly some large organizations are built around the 
VoIP/net to legacy equipment/PSTN/PBX use-case, and certainly they would 
find SDES easier.

But I think we need to weigh that against the longer term, and the 
interests of the users (not the providers) -- the users aren't generally 
at this table; the IETF is full of people who almost by definition work 
for the companies that provide data and services. (Not everyone, but most.)

I realize there are some (many) who have 
business/organizational/political reasons to avoid end-2-end 
encryption.  However, per IETF norms (RFC 2084) we should not be letting 
that decide this issue.

It's tough to find a way to allow SDES in the "connect to a gateway that 
will decrypt anyways" case, while also avoid bid-down attacks on 
browser-browser communication.  (and EKT has some of the same key 
control issues)

We can say "we enforce DTLS-SRTP only for secure, authenticated" calls 
like ekr presented (with media tainting, etc) - but that mode isn't the 
default and really can't be/won't be for many users and applications, 
making it at best an obscure option for most people. An app (or browser 
chrome) could put a "renegotiate/re-encrypt NOW with only DTLS-SRTP" 
button up, but I doubt most apps would bother, and it might be a 
struggle to get all browsers to include such an option I suspect.  And 
even that might/would be hard to convey to users.  But maybe that's the 
best we can do.  If so, it's a sad day we can't collectively figure out 
something better.

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 16:40:47 -0700

On 25 April 2013 16:33, Randell Jesup <[email-masked]> wrote:
> SDES is basically "protect against WiFi sniffers" encryption.

I wondered when this characterization would resurface.  It's a really
bad one.  SDES protects your communications from everyone except the
website and anyone they choose to send it to.  It's no different to
using DTLS-SRTP to send data directly to a server that presents the
sites domain certificate.  It's exactly equivalent to allowing
getUserMedia with peerIdentity constraint (and that other one I can't
ever remember the name of).

Whether this is acceptable depends on your threat model.

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Apr 2013 17:28:35 -0700

> cost might not be that big of a deal (SBC vendors may disagree), but

Yes.  But major web sites seem to accept the performance penalty of the TLS handshake, both CPU hit and round trips.

> makes the media accessible to signaling intermediaries (read: the web

To the contrary -- EKT is protected by the DTLS-SRTP key, which is not known to the web site (or SIP proxies).

> much.  Bid-down protection seems lame when the site has access to the

Yes, it is lame if the site has access to the keys.  That is why I don't want Security Descriptions used with RTCWEB.

> Otherwise its security properties are basically the same as security

Agreed.  And DTLS-SRTP provides the foundation to build such a system.  Security Descriptions does not provide a foundation to build such a system.

-d

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Apr 2013 17:36:09 -0700

> obligated to provide a particular CN, so it's mostly down to just

Or storing fingerprints into an addressbook (similar to HTTPS key pinning), cooperatively comparing fingerprints (similar to http://perspectives-project.org), and the rest of the state of the art and emerging state of the art for certificate validation.

> implementations mint new certificates for every interaction.  

That is probably done for privacy, because otherwise the client and the server's identities are shown in the media path during the DTLS certificate exchange.  That needs to be wrapped with a separate key or, as you have seen, new certificates have to be generated for each session if identity privacy is important.

-d

> I'm

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Apr 2013 18:00:57 -0700

> implementations mint new certificates for every interaction.

This is a limitation of current implementations. Expect it to change in the
relatively
near-term.

-Ekr

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:03:24 -0700

> using keys provided by security descriptions.

Or, even better, data channels can just not be used in this case.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:16:02 -0700

> DTLS-SRTP with EKT can also perform that function, and does it without disclosing the SRTP key to all the SIP proxies and all the web servers on the signaling path.

1. Are you suggesting that we also mandate EKT?
2. Do you believe that an evil web server would do something other than 
negotiate DTLS-SRTP with the mixer it is in cahoots with?

The only advantage I can see is that if we mandate cipher suites that 
have PFS, then you get PFS... which helps until the evil web site's 
mixer records all the cleartext and saves it indefinitely as well. But 
it does help in the case where the partially-evil website only tells 
people the keys it logs. And then not, when the partially-evil website's 
mixer or gateway uses EKT and then only tells people the keys it issued.

So my conclusions (and correct me if I'm wrong):
  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.

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

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.

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

And finally, to get the browser-to-browser security guarantees you want 
you 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 what it is talking to)

> But is there a secure mechanism to differentiate browser-to-browser calls from browser-to-non-browser calls, so we don't have to worry over SDES downgrade attacks?

This is provably impossible.

>   And for the use-cases where JavaScript has to set the key, those will often be browser-to-browser calls, meaning that we will have to support browser-to-browser SDES, contrary to your desire that browser-to-browser use DTLS-SRTP?

Yes, of course.

>   DTLS-SRTP with EKT permits the application to set the SRTP key, and more securely than SDES.

See above. I don't believe that it is "more securely". The path is 
different. Whether that path is more secure or equivalently secure is 
debatable.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:21:02 -0700

> any that goes through its network and you can't detect it.

That really depends on what you mean by "user visible" doesn't it? If 
you mean "the user is watching to see that all their packets go to what 
they know is the verified IP address of their buddy" then sure. But if 
you mean "the user is looking at their web browser user interface" or 
even "the user was worried mid-call so checked to see where the packets 
were going" then I think not, as all that needs to happen is for the 
call to be set up with a middlebox in the path that the site claims is 
necessary for the call to work (meets the UI test), keys set with EKT, 
and then a little ICE renegotiation and the middlebox goes away from the 
path (meets even the second test).

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:27:35 -0700

On 4/25/2013 4:40 PM, Randell Jesup wrote:
> So, the problems with SDES (discussed to a fare-the-well every 3 
> months for the last 1.75 years or more, so there's nothing really new 
> here):
>
> It exposes security keys directly to the application (or takes them 
> from there).  Basically, you're back in "all your media is totally in 
> trust to the application and website".  The keys aren't even end-2-end 
> encrypted or even authenticated.  And even if you expose SDES 
> bid-downs to the user, they don't know what they mean or how to 
> process this information.

This is true anyway, because even if we only allow DTLS-SRTP, we will 
allow cases like (as an example) Google Hangouts... which will no doubt 
be implemented by having the box in the middle be who you're calling and 
doing the DTLS exchange with. And then yes, you're trusting the 
application and website and its mixer with your media.

> to meet, and interop with legacy devices and systems easier (though 
> many such legacy interop systems will perforce need gateways anyways, 
> and those gateways can convert from DTLS-SRTP to SDES.

They can, but gateways that do the ICE connectivity check only were 
already an annoyance that makes interop harder than we'd like. Now we're 
going to force those gateways to also do DTLS-SRTP and EKT? Is the goal 
here to put up as many roadblocks as possible to RTCWEB developers who 
want to access networks outside of the browser-to-browser case?

>
> Yes, some gateway scenarios might be cheaper/easier with SDES, but I 
> see the primary use-cases for WebRTC to be browser-to-browser, not 
> browser-legacy.

Just because the charter was mistakenly written that way doesn't mean it 
is true. Think of all the C2B use cases, where the agents in the call 
center probably won't be on browsers... and even if they are, those 
browsers will be behind systems that do things like supervisor 
monitoring and barge-in, audit recording, etc.

> Certainly some large organizations are built around the VoIP/net to 
> legacy equipment/PSTN/PBX use-case, and certainly they would find SDES 
> easier.

And many upstarts in the space are leveraging the large legacy VoIP and 
PSTN networks to give developers a reason to put their RTCWEB-based 
services into their browser experiences, too.

> interests of the users (not the providers) -- the users aren't 
> generally at this table; the IETF is full of people who almost by 
> definition work for the companies that provide data and services. (Not 
> everyone, but most.)
>
> encryption.  However, per IETF norms (RFC 2084) we should not be 
> letting that decide this issue.
>
>
> It's tough to find a way to allow SDES in the "connect to a gateway 
> that will decrypt anyways" case, while also avoid bid-down attacks on 
> like ekr presented (with media tainting, etc) - but that mode isn't 
> the default and really can't be/won't be for many users and 
> applications, making it at best an obscure option for most people. An 
> app (or browser chrome) could put a "renegotiate/re-encrypt NOW with 
> only DTLS-SRTP" button up, but I doubt most apps would bother, and it 
> might be a struggle to get all browsers to include such an option I 
> suspect.  And even that might/would be hard to convey to users.  But 
> maybe that's the best we can do.  If so, it's a sad day we can't 
> collectively figure out something better.
>

We could do much better security-wise... If we really wanted nobody to 
use this stuff.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:31:35 -0700

> Yes.  But major web sites seem to accept the performance penalty of the TLS handshake, both CPU hit and round trips.

The people who build the boxes that were going to just have to do the 
ICE front-end for legacy systems would probably tell you that the cost 
of the TLS handshake is a lot higher for them than it is for web servers.

I'm not one of them, but I'm sure we have one on the list.

> To the contrary -- EKT is protected by the DTLS-SRTP key, which is not known to the web site (or SIP proxies).

Unless of course the web site has anything to do with the box you've 
negotiated DTLS with... in which case not only does the web site know 
the EKT key, it also knows what DTLS key was negotiated to protect it!

> Yes, it is lame if the site has access to the keys.  That is why I don't want Security Descriptions used with RTCWEB.

So you're going to argue against EKT, and require browsers to somehow 
prove that they are browsers and prevent browsers from talking to 
anything that isn't. I believe this would A) break a lot of the use 
cases and B) be technically infeasible.

> Agreed.  And DTLS-SRTP provides the foundation to build such a system.  Security Descriptions does not provide a foundation to build such a system.

Yes, and we are providing DTLS-SRTP. So how does SDES not providing such 
a foundation matter in your argument?

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Apr 2013 21:32:54 -0700

> Or storing fingerprints into an addressbook (similar to HTTPS key pinning), cooperatively comparing fingerprints (similar to http://perspectives-project.org), and the rest of the state of the art a…

Yes. And so it'll learn that everyone calls everyone else via Google's 
server. How does that help with people's media staying secure from 
interception exactly?

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Apr 2013 07:19:24 +0200

> The working groups committed some time ago to have a further discussion on whether SDP Security Descriptions (RFC 4568 aka SDES) would be usable as a keying method for WebRTC.  As we prepare for th…

Sorry, I got lost in the levels of support.

Are you asking for indications of support for the idea of supporting 
SDES (in which case you should also be asking for indications of support 
for the idea of NOT supporting SDES), or are you asking for indications 
of support for the idea of having a discussion about supporting SDES?

             Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Apr 2013 07:25:07 +0200

On 04/26/2013 06:27 AM, Matthew Kaufman wrote:
>>> I agree. The ability to set the cipher suite and keys from 
>>> JavaScript is critical for certain applications. SDES is the best 
>>> we'll get with SDP as the API. DTLS-SRTP-only would be unacceptably 
>>> limiting.
>>
>> trust to the application and website".  The keys aren't even 
>> end-2-end encrypted or even authenticated.  And even if you expose 
>> SDES bid-downs to the user, they don't know what they mean or how to 
> allow cases like (as an example) Google Hangouts... which will no 
> doubt be implemented by having the box in the middle be who you're 
> calling and doing the DTLS exchange with. And then yes, you're 
> trusting the application and website and its mixer with your media.

Strictly speaking, you're trusting the mixer with your media.

You trust the website to serve up the application, and you trust the 
application to choose the mixer. This offers up an easy attack for any 
website that has a mixer it coordinates with - but it's the mixer you 
trust with your media.

It's nice to be precise.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 26 Apr 2013 01:54:02 -0400

> trusting the application and website and its mixer with your media.

No argument: if you're calling into a mixer, all bets are off (it's 
secure only until it gets the data to the server/mixer).  And even 
person-to-person, without identity assertions it is MITM-able, though 
not completely undetectably - you can examine the IP addresses of the 
packet (and if you have identity assertions you have to check the 
identities, or have something to flag that there was a fingerprint/key 
change).

>
>>
>> SDES basically means to me "secure against random WiFi sniffers at 
>> the coffeeshop", and little more than that.  I realize carriers and 
>> others like SDES because they make certain uses and obligations easy 
>> for them to meet, and interop with legacy devices and systems easier 
>> (though many such legacy interop systems will perforce need gateways 
>> anyways, and those gateways can convert from DTLS-SRTP to SDES.
>
> already an annoyance that makes interop harder than we'd like. Now 
> we're going to force those gateways to also do DTLS-SRTP and EKT? Is 
> the goal here to put up as many roadblocks as possible to RTCWEB 
> developers who want to access networks outside of the 
> browser-to-browser case?

I agree it's inconvenient to have these requirements - I spent a bunch 
of brain cycles and some phone chats with Cullen trying to figure out a 
way to enable PSTN gateway calls to avoid needing to use ICE and avoid 
needing DTLS-SRTP, and failed.  With DNSSec it's almost possible.

> Just because the charter was mistakenly written that way doesn't mean 
> it is true. Think of all the C2B use cases, where the agents in the 
> call center probably won't be on browsers... and even if they are, 
> those browsers will be behind systems that do things like supervisor 

I don't count that as legacy - or if it is, that's fine - the call can 
be confirmed secure to the company's gateway and the gateway can 
identify itself as the company.

>> legacy equipment/PSTN/PBX use-case, and certainly they would find 
>> SDES easier.
>
> And many upstarts in the space are leveraging the large legacy VoIP 
> and PSTN networks to give developers a reason to put their 
> RTCWEB-based services into their browser experiences, too.
>
>>
>> definition work for the companies that provide data and services. 
>> (Not everyone, but most.)
>>
>> We can say "we enforce DTLS-SRTP only for secure, authenticated" 
>> calls like ekr presented (with media tainting, etc) - but that mode 
>> isn't the default and really can't be/won't be for many users and 

That's always the problem with strong security...  It has to be 
unobtrusive-but-functional in the "normal" cases to get widely used.  
Green-field encryption can be fairly easily strong because of lack of 
needing to interop.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Apr 2013 22:55:20 -0700

On Thu, Apr 25, 2013 at 9:27 PM, Matthew Kaufman <[email-masked]> wrote:

> O
> is true.

I remind you that the actual title of the group is:

"Real-Time Communication in WEB-browsers (rtcweb)".  While you may disagree
with the charter, please remember that it's not fundamentally a prediction
about what the eventual balance of flows will be.  It's a statement about
where the balance of effort in the group should go.   To me as an
individual, it implies that we should not make trade-offs that optimize a
non-browser use case at the expense of the browser use case except in
pretty extraordinary circumstances.

regards,

Ted Hardie

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Apr 2013 23:08:31 -0700

On Thu, Apr 25, 2013 at 9:21 PM, Matthew Kaufman <[email-masked]> wrote:

> That really depends on what you mean by "user visible" doesn't it? If you
> mean "the user is watching to see that all their packets go to what they
> know is the verified IP address of their buddy" then sure. But if you mean
> "the user is looking at their web browser user interface" or even "the user
> was worried mid-call so checked to see where the packets were going" then I
> think not, as all that needs to happen is for the call to be set up with a
> middlebox in the path that the site claims is necessary for the call to
> work (meets the UI test), keys set with EKT, and then a little ICE
> renegotiation and the middlebox goes away from the path (meets even the
> second test).

What I mean is that you can use fingerprint checks (admittedly
inconvenient) to
detect active attacks. Obviously, current browser UIs don't support that,
but
I expect them to eventually.

-Ekr

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 26 Apr 2013 07:55:05 +0000

Also agree that we should support SDES in additional to DTLS-SRTP.

Regards
Andy

> Behalf Of Ejzak, Richard P (Richard)
> Sent: 25 April 2013 22:55
> To: [email-masked]
> This raises a further question about SCTP/DTLS for DataChannels.  It
> seems that if we support SDES-SRTP, don't we also need to provide an
> SDES keying mechanism for DataChannels?  Ekr: What is needed to realize
> this?
> 
> Richard Ejzak
>

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 26 Apr 2013 10:49:43 +0200

+1 for supporting SDES as a keying method for WebRTC

Cheers,

Xavier

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 12:11:11 +0100

> Reason (1) is a fairly big deal.  There are other reasons:

I don't buy the interop argument.
There are (as we have all now discovered) no legacy devices that do SRTP (SDES only) and Ice/STUN/rtcp-mux/bundle
as required to consume the UDP that chrome (for example) generates. We will _always_ need a media gateway in front of
any current legacy devices to de-ice/de-mux/ etc the media streams from webRTC.

(Note: I refuse to take into account the oxymoronic 'future legacy' devices that current legacy providers may build at some point in the future).

So the question is how heavy does that media gateway have to be? 
Does adding DTLS as a key exchange method make they exorbitant to build? 
It turns out that it doesn't. 

Remembering that DTLS is only used here as a key-exchange 
protocol you can just put a DTLS filter in your UDP layer (alongside the ICE /demux code) and pop the SRTP keys out of it. 
Those keys can then be used by current SRTP hardware and software. 

So the overhead is limited to the key-exchange itself. It will make call set-up mor expensive, but as someone pointed out there are
a few websites that seem to cope with https - so I dare say we will learn to live with it.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 13:35:33 +0200

SDES is obviously requested for legacy interop at RTP layer. Why do we need
SDES in DataChannel if this is a complete new technology?

--
Iñaki Baz Castillo
<[email-masked]>
El 25/04/2013 23:55, "Ejzak, Richard P (Richard)" <
[email-masked]> escribió:

> This raises a further question about SCTP/DTLS for DataChannels.  It seems
> that if we support SDES-SRTP, don't we also need to provide an SDES keying
> mechanism for DataChannels?  Ekr: What is needed to realize this?
>
> Richard Ejzak
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 13:37:43 +0200

Such a solution requires a very expensive gateway. Good for vendors but bad
for all the rest.

--
Iñaki Baz Castillo
<[email-masked]>
El 26/04/2013 00:14, "Dan Wing" <[email-masked]> escribió:

> > 1. There is a backwards compatibility reason. There are deployed systems
> of SRTP that use SDES or a key agreement that easily maps to it. Just as we
> allowed G.711 for these systems, it seems reasonable to allow SDES as well.
> When combined with ICE Lite in a media gateway, this is a scalable interop
> approach.
>
> Interworking at scale can be accomplished without SDES on WEBRTC, as I
> explained at IETF83 in slides 27-35 of
> http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf.
>
> > 2. We need it or something like it for API reasons. There are cases
> where the JavaScript needs to tell the browser what SRTP key to use.
>
> DTLS-SRTP with EKT can also perform that function, and does it without
> disclosing the SRTP key to all the SIP proxies and all the web servers on
> the signaling path.
>
> > Since JSEP uses SDP for this API surface, SDES works for this. Obviously
> it is a bad idea to send this key over unsecured channels, but this is
> separate from this API issue.
> >
> > And just to be clear, browser to browser should use DTLS-SRTP, and only
> thus mode should be considered "secure" using whatever user interface a
> browser chooses.
>
> But is there a secure mechanism to differentiate browser-to-browser calls
> from browser-to-non-browser calls, so we don't have to worry over SDES
> downgrade attacks?  And for the use-cases where JavaScript has to set the
> key, those will often be browser-to-browser calls, meaning that we will
> have to support browser-to-browser SDES, contrary to your desire that
> browser-to-browser use DTLS-SRTP?  DTLS-SRTP with EKT permits the
> application to set the SRTP key, and more securely than SDES.
>
> -d
>
>
> >
> > - Alan -
> >
> >
> >
> on whether SDP Security Descriptions (RFC 4568 aka SDES) would be usable as
> a keying method for WebRTC.  As we prepare for that discussion, we'd like

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 14:16:52 +0100

On 26 Apr 2013, at 12:37, Iñaki Baz Castillo wrote:

> Such a solution requires a very expensive gateway. Good for vendors but bad for all the rest.
> 

I don't understand why the DTLS gateway would be so expensive. It is _exactly_ the same 
(conceptually) as the ICE processing - you filter off a few UDP packets from the stream, do some
stuff, send replies then once you are happy you punt some dynamic settings back up to the (s)rtp 
layer.

T.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 15:19:23 +0200

The problem is when EKT is also used and the gateway must send SIP reINVITE
by itself as the proposed "solution diagram" shows. That is not just a
media gateway.

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

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 26 Apr 2013 06:24:03 -0700

> settings back up to the (s)rtp

The CPU-seconds of cryptography required are markedly different, 
especially on low-end processors used by some of the distributed gateway 
solutions.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 26 Apr 2013 06:25:55 -0700

On 4/25/2013 11:08 PM, Eric Rescorla wrote:
>
>
> On Thu, Apr 25, 2013 at 9:21 PM, Matthew Kaufman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         which allows for the detection of cheating by the site. By
>         contrast, if SDES is used
>     That really depends on what you mean by "user visible" doesn't it?
>     If you mean "the user is watching to see that all their packets go
>     to what they know is the verified IP address of their buddy" then
>     sure. But if you mean "the user is looking at their web browser
>     user interface" or even "the user was worried mid-call so checked
>     to see where the packets were going" then I think not, as all that
>     needs to happen is for the call to be set up with a middlebox in
>     the path that the site claims is necessary for the call to work
>     (meets the UI test), keys set with EKT, and then a little ICE
>     renegotiation and the middlebox goes away from the path (meets
>     even the second test).
>
>
> detect active attacks. Obviously, current browser UIs don't support 
> that, but

Unless you are in a Hangouts-like scenario, where every call goes to a 
mixer and so the fingerprints for all calls look the same, whether 
you're being intercepted or not.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 26 Apr 2013 06:29:01 -0700

> website that has a mixer it coordinates with - but it's the mixer you 

But all must be trusted. The application can send you to an evil mixer, 
the website can serve up an application or tamper with the signaling in 
order to send you to an evil mixer, and the mixer can itself be evil. 
And the application can use GetUserMedia to capture a second copy of 
your media and send it somewhere else, or the website can modify the 
application (or in some cases, the signaling) to do that as well.

You're trusting everything to not do something that results in your 
media being intercepted.

Matthew Kaufman

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 14:29:13 +0100

On 26 Apr 2013, at 14:24, Matthew Kaufman wrote:

> The CPU-seconds of cryptography required are markedly different, especially on low-end processors used by some of the distributed gateway solutions.

True, but only at call set-up time, not for the life of the call. I'd want to see numbers on this before we select to adopt even 
more complexity for the sake of a theoretical legacy interop requirement.

T.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 26 Apr 2013 06:31:50 -0700

> Green-field encryption can be fairly easily strong because of lack of 

Even that isn't true. See, for instance, Zooko's triangle [1]. Getting 
strong encryption with useful authentication that protects a naive user 
from evil applications and signaling services is very very hard, even if 
you ignore interop.

Matthew Kaufman

[1] http://en.wikipedia.org/wiki/Zooko's_triangle 
<http://en.wikipedia.org/wiki/Zooko%27s_triangle>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Apr 2013 15:33:03 +0200

> settings back up to the (s)rtp

So you're saying that the gateway doesn't have to decrypt and re-encrypt 
the packets?

I think EKT may be a problem, as Inaki pointed out, but I have less 
qualms about supporting DTLS and making it optional to use EKT on some 
calls than I have about mandating support for SDES.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 26 Apr 2013 06:34:00 -0700

On 4/25/2013 10:55 PM, Ted Hardie wrote:
> On Thu, Apr 25, 2013 at 9:27 PM, Matthew Kaufman <[email-masked] 
>         Yes, some gateway scenarios might be cheaper/easier with SDES,
>         but I see the primary use-cases for WebRTC to be
>         browser-to-browser, not browser-legacy.
>
>
>     Just because the charter was mistakenly written that way doesn't
>     mean it is true.
>
>
> "Real-Time Communication in WEB-browsers (rtcweb)".  While you may 
> disagree with the charter, please remember that it's not fundamentally 
> a prediction about what the eventual balance of flows will be.  It's a 
> statement about where the balance of effort in the group should go.   
> To me as an individual, it implies that we should not make trade-offs 
> that optimize a non-browser use case at the expense of the browser use 
> case except in pretty extraordinary circumstances.
>

Adding SDES helps a non-browser use case with no expense to the browser 
use cases except for the small amount of additional code.

If you don't believe that (because you think it reduces the 
browser-to-browser security) then I will point you to  browser use cases 
include multi-party scenarios that will require EKT, and then show how 
the security of EKT is nearly equivalent.

Matthew Kaufman

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 14:43:22 +0100

On 26 Apr 2013, at 14:33, Harald Alvestrand wrote:

> So you're saying that the gateway doesn't have to decrypt and re-encrypt the packets?

It depends where it is a gateway to. I'm claiming that the huge majority of the legacy side endpoints
are going to be wanting plain RTP anyhow, so no need to re-encrypt.
Another chunk of functionality is local processing (conference mixing, call recording, ivr etc) where 
the device (or it's cluster) is the endpoint, so again no need to re- encrypt.

The decryption can be handled by existing SRTP components, which just need to be fed the keys
generated by the DTLS exchange.

(And I'd add that we got into this mess by sticking with O/A semantics. )

T.

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 14:47:55 +0100

On 26 Apr 2013, at 14:34, Matthew Kaufman wrote:

>> Yes, some gateway scenarios might be cheaper/easier with SDES, but I see the primary use-cases for WebRTC to be browser-to-browser, not browser-legacy.
>> 
>> Just because the charter was mistakenly written that way doesn't mean it is true.
>> 
>> "Real-Time Communication in WEB-browsers (rtcweb)".  While you may disagree with the charter, please remember that it's not fundamentally a prediction about what the eventual balance of flows will be.  It's a statement about where the balance of effort in the group should go.   To me as an individual, it implies that we should not make trade-offs that optimize a non-browser use case at the expense of the browser use case except in pretty extraordinary circumstances.
>> 
> 
> Adding SDES helps a non-browser use case with no expense to the browser use cases except for the small amount of additional code.

I don't agree, it further complicates the existing hideous mess that is the SDP in the browser. Given where we are, we should be looking for ways to simplify that, not complicate it.

If anyone still thinks that SDP is just a blob not an API surface, take a look at the 'reference implementation' of browser to browser interop.
https://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/index.html

I count around 100 lines of javascript munging the SDP.

T.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Apr 2013 06:48:14 -0700

On Fri, Apr 26, 2013 at 6:25 AM, Matthew Kaufman <[email-masked]> wrote:

> On Thu, Apr 25, 2013 at 9:21 PM, Matthew Kaufman <[email-masked]>wrote:
>
>> they know is the verified IP address of their buddy" then sure. But if you
>> mean "the user is looking at their web browser user interface" or even "the
>> user was worried mid-call so checked to see where the packets were going"
>> then I think not, as all that needs to happen is for the call to be set up
>> with a middlebox in the path that the site claims is necessary for the call
>> to work (meets the UI test), keys set with EKT, and then a little ICE
> mixer and so the fingerprints for all calls look the same, whether you're
> being intercepted or not.
>

Of course. However, if you want to have a call where you know you are
secure from monitoring by the site, you avoid such scenarios.

-Ekr

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Apr 2013 06:53:08 -0700

> more complexity for the sake of a theoretical legacy interop requirement.

Right - only at call setup and only when keys change.  The SRTP packets themselves are not decrypted/encrypted.

-d

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Apr 2013 06:56:57 -0700

> So you're saying that the gateway doesn't have to decrypt and re-encrypt the packets?

Correct - the gateway does not have to decrypt and re-encrypt the SRTP packets.  The gateway only has to interwork the signaling between SDES and DTLS-SRTP-EKT.  Such signaling interworking is necessary when the call is initially set up and when the SRTP key is changed (e.g., a new person joins a call using their own key, or the SRTP key is exhausted [pretty unlikely, even with video]).  This was summarized in http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

> 
> I think EKT may be a problem, as Inaki pointed out, but I have less qualms about supporting DTLS and making it optional to use EKT on some calls than I have about mandating support for SDES.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 16:02:17 +0200

> If anyone still thinks that SDP is just a blob not an API surface, take a
look at the 'reference implementation' of browser to browser interop.
> I count around 100 lines of javascript munging the SDP.

IMHO the WG should really consider the above mess due to the usage of SDP
as an API surface. It is just terrible.

---

From: Oscar Ohlsson <[email-masked]>
Date: Fri, 26 Apr 2013 14:56:47 +0000

I'm also in favour of supporting SDES (no big surprise). But we need to analyze how SDES should be enabled and how it can be negotiated in SDP. If people are concerned with bidding down attacks then we could add a separate JavaScript instruction for enabling SDES. If SDES is not enabled then it wouldn't be offered or accepted.

Regards,

Oscar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Marjou
Sent: den 26 april 2013 10:50
To: [email-masked]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

On Fri, Apr 26, 2013 at 9:55 AM, Hutton, Andrew <[email-masked]> wrote:
Also agree that we should support SDES in additional to DTLS-SRTP.

Regards
Andy

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Apr 2013 08:58:36 -0600

Uh, rereading that paragraph, the word "support" got used a lot of times - my apologies. 

We had previously deferred the WG discussion about SDP Security Descriptions but we would like to try and resolve that issue. What we are asking for is for people to suggest what they want the drafts to say on this topic and why. Exactly the sort of discussion we have seen from the people that replied to this thread was the type of thing we where hoping for. 

Answers inline below ...

On Apr 25, 2013, at 11:19 PM, Harald Alvestrand <[email-masked]> wrote:

> Are you asking for indications of support for the idea of supporting SDES (in which case you should also be asking for indications of support for the idea of NOT supporting SDES),

yes, glad to hear about both of these. I'd view "MUST NOT ever do SDES or even talk about. If you receive SDP with SDES in in the browser MUST reformat the hard drive and send a report to the EFF" as one level of "support" we could choose. (OK not one I would support but you get the idea)  

> or are you asking for indications of support for the idea of having a discussion about supporting SDES?

No, we did not mean to ask that, we were just presumptively starting the discussion. If no one wants to talk about it I assumed there would be silence on the list or push back on that. It's currently listed as an open issues in the WG draft.

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 26 Apr 2013 09:36:13 -0700

Tim,

   I disagree with the argument on the interop that  a media gateway is
always required. Cisco for example have been shipping devices that work
fine with webrtc browsers that do H.264 without needing a media gateway. I
am sure this is true for examples other than Cisco.

Thanks
Suhas Nandakumar

On Fri, Apr 26, 2013 at 4:11 AM, Tim Panton <[email-masked]> wrote:

> as required to consume the UDP that chrome (for example) generates. We
> will _always_ need a media gateway in front of
> (Note: I refuse to take into account the oxymoronic 'future legacy'
> devices that current legacy providers may build at some point in the
> future).
>
> protocol you can just put a DTLS filter in your UDP layer (alongside the
> ICE /demux code) and pop the SRTP keys out of it.
> So the overhead is limited to the key-exchange itself. It will make call
> set-up mor expensive, but as someone pointed out there are

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 18:41:38 +0200

And is it so hard for Cisco to make those new WebRTC capable devices DTLS
aware? Is that really harder than the ICE/bundle/SAVPF stuff already
implemented in those devices?

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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 26 Apr 2013 11:53:30 -0500

What about the API considerations?

If two browsers have a source of keying material, such as a preshared key,
or material derived from something else (i.e. keys on flash drives), the
API needs to be able to give this key to the browser to use.  This API
issue is orthogonal to whether the key has been shared over an insecure
signaling channel or not.

- Alan -

On Thu, Apr 25, 2013 at 5:20 PM, Adam Roach <[email-masked]> wrote:

> the brower-to-browser case. By implication, this means that the presence of
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2013 12:53:55 -0400

Have anybody tried an international call with ICE and DTLS enabled? The
call setup delay introduced by the combination of the two is long enough to
go from being simply annoying to the point of other person hanging up
assuming the call is not working. Right now the only workaround is using
SDES.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 18:23:34 +0100

On 26 Apr 2013, at 17:36, Suhas Nandakumar wrote:

> Tim, 
> 
>    I disagree with the argument on the interop that  a media gateway is always required. Cisco for example have been shipping devices that work fine with webrtc browsers that do H.264 without needing a media gateway. I am sure this is true for examples other than Cisco.

That's not a legacy device then.
So they can just add DTLS support in the next release and they are still good.

T.

---

From: "DRUTA, DAN" <[email-masked]>
Date: Fri, 26 Apr 2013 17:26:50 +0000

I would like to see the user-agent support for SDES as a "MUST" for RTCWeb. 
I don't think I need to restate why. One additional point though is that it will make interop easier, expand and accelerate the adoption for RTCWeb/WebRTC. Isn't this the ultimate goal?  
In regards to security considerations I would challenge the group to come up with ways to identify and convey the risks back to the end user through the user-agent implementation in a very simple and easy to understand UI (if necessary). I know this could be a big rat hole and I can hear already arguments that it's already too confusing but as the Web is becoming more of a platform and browser complexity increases we should acknowledge it with better transparency rather than with restrictions and limitations. Users make their own decisions in the end.

Best Regards,
Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar Ohlsson
Sent: Friday, April 26, 2013 7:57 AM
To: [email-masked]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Regards,

Oscar

Regards
Andy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 Apr 2013 19:36:54 +0200

Adding DTLS is a little effort compared to adding ICE / bundle / SAVPF to a
device. I could understand the latency problem argument however, but not
the "easy interop" argument which has become a headache and forced the SDP
API adoption which makes WebRTC much harder than it could be.

--
Iñaki Baz Castillo
<[email-masked]>
El 26/04/2013 19:27, "DRUTA, DAN" <[email-masked]> escribió:

> I don't think I need to restate why. One additional point though is that
> it will make interop easier, expand and accelerate the adoption for
> RTCWeb/WebRTC. Isn't this the ultimate goal?
> In regards to security considerations I would challenge the group to come
> up with ways to identify and convey the risks back to the end user through
> the user-agent implementation in a very simple and easy to understand UI
> (if necessary). I know this could be a big rat hole and I can hear already
> arguments that it's already too confusing but as the Web is becoming more
> of a platform and browser complexity increases we should acknowledge it
> with better transparency rather than with restrictions and limitations.
> Users make their own decisions in the end.
>
> Best Regards,
> Dan
>
>
> I'm also in favour of supporting SDES (no big surprise). But we need to
> analyze how SDES should be enabled and how it can be negotiated in SDP. If
> people are concerned with bidding down attacks then we could add a separate
> JavaScript instruction for enabling SDES. If SDES is not enabled then it
> wouldn't be offered or accepted.
>
> Regards,
>
> Oscar
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2013 13:59:34 -0400

On Fri, Apr 26, 2013 at 1:36 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> Adding DTLS is a little effort compared to adding ICE / bundle / SAVPF to
> a device. I could understand the latency problem argument however, but not
> I would argue that SDP adoption made WebRTC harder to interop, but there
is already consensus that SDP should be used, so there is no point to talk
about it anymore.

The arguments why SDES is required in some cases instead of DTLS are:

1. Additional call setup delay caused by DTLS

2. High computational load on each call setup. This can be significant with
high number of short calls being setup. This would be especially
significant for any sort of server interfacing WebRTC or WebRTC to SIP
gateway.

3. High complexity -- you are doubling or tripling amount of code you need
in your SRTP stack to support DTLS negotiations. Most of the code in
readily available libraries is not needed and represents no functional
value (certificate support, unneeded encryption methods, compression,
streaming, etc), but will require a significant amount of support effort
and can be a security risk (I am talking about something like OpenSSL or
GnuTLS which ends up in the media processing stack).

As it stands right now, I would prefer never to use DTLS-SRTP with any
client to server communication applications, since it has no security value
in such scenarios (server can access media anyway) and will cause
significant usability, performance, and support issues.
_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 26 Apr 2013 18:07:47 +0000

> I count around 100 lines of javascript munging the SDP.

Could you just summarize what the 100 lines do and which theses would be needed for browsers that implemented the drat standards? I'm trying to dig into what we need to fix.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Apr 2013 12:23:40 -0600

> "Real-Time Communication in WEB-browsers (rtcweb)".  While you may disagree with the charter, please remember that it's not fundamentally a prediction about what the eventual balance of flows will…

Ted, I think rtcweb is about a web brewer being able to communicate to lots of things, not just one currently very small island. Our uses and discussion from well before this WG was chartered have recognized that to be successful, rtrcweb endpoints were going to need to be able to call things other than web browsers. You were one of the people that pushed hard on the non browser (but also not legacy) uses. 

I agree with your point that the design of any new communication system has to deal with the tradeoff between how it work with previous system and how easy it is to build. However, in the case here, I tend towards trying to make the a new system that can take advantage of an early network effect by being able to talk to lots of existing things. I don't believe that Skype would have reach the penetration it currently has without PSTN interoperability. I think the same can be said for Google Voice and WebEx.

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 19:31:12 +0100

> Could you just summarize what the 100 lines do and which theses would be needed for browsers that implemented the drat standards? I'm trying to dig into what we need to fix. 

The bulk of it seems to be there to coerce the browsers to use the 'best' codec. 
I see code to remove CN and re-write the m= line to get opus as the first element.

I think this represents a class of problem where the web programmer will want to assert their 
preferences, and currently SDP munging is the only available API.

I personally doubt that any level of standardisation of the SDP will remove the need for such tweaks.

Tim.

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 19:42:32 +0100

> 1. Additional call setup delay caused by DTLS

This is a serious problem - made worse by the O/A semantics - I think we will find that in real usage
sites will pre-warm a DTLS connection so it is ready to go when the user clicks connect.

> 
> 2. High computational load on each call setup. This can be significant with high number of short calls being setup. This would be especially significant for any sort of server interfacing WebRTC or WebRTC to SIP gateway.

I would dispute this - remember exactly the same users have almost certainly logged into an https:// portal - indeed only a small 
percentage of them will start a DTLS session for during any given web session. The web seems to still be working.

> 
> 3. High complexity -- you are doubling or tripling amount of code you need in your SRTP stack to support DTLS negotiations. Most of the code in readily available libraries is not needed and represents no functional value (certificate support, unneeded encryption methods, compression, streaming, etc), but will require a significant amount of support effort and can be a security risk (I am talking about something like OpenSSL or GnuTLS which ends up in the media processing stack).

That's true to an extent, but it only applies to devices that don't already do TLS for something else. 
Webservers, web browsers, Sip/xmpp engines, anything offering an https management interface, will already have that code
in use for other purposes. The DTLS specific code is quite small. 

> 
> As it stands right now, I would prefer never to use DTLS-SRTP with any client to server communication applications, since it has no security value in such scenarios (server can access media anyway) and will cause significant usability, performance, and support issues.

There I also disagree. The ability to offer a DTLS connection that presents a browser checkable x509 certificate for yourbank.com over the
media path in a call to a bank's authorized call center agents might be a significant advantage.

T.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Apr 2013 12:47:54 -0600

> I personally doubt that any level of standardisation of the SDP will remove the need for such tweaks.

I think that both Firefox and Chrome would agree with was a bug to prefer narrowband codecs over wideband codecs. I'd be shocked to actually see them prefer narrowband over G.711. 

I think the older version of Chrome prefer some non standard codec over opus but that could change. Allowing an application to change preference in that case is a valid reason to munge SDP but not one that most applications will probably care about. If we want to avoid this type of SDP munging, we could easily add a constraint to the API that allowed the application to provide codec preferences along the lines of how openssl allows one to provide crypto preferences. I would like to point out that this code makes opus always the preferred which is really bad for future interoperability. When we come out with opus2, and all the browsers support it, this code will still be using opus1. So in my opinion, this code would be better if it did not do this and just let offer /answer negotiation pick a codec but I digress. 

If the browsers can't process the SDP with the CN and ignore it, that seems like a bug.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2013 15:45:04 -0400

> sites will pre-warm a DTLS connection so it is ready to go when the user
Pre-warming connection before user consent has some security implications
as well. I would much rather see a mechanism to do ICE setup and DTLS key
exchange at the same time. Should we look into extending ICE/STUN to carry
public/private key exchange?

>
> 2. High computational load on each call setup. This can be significant
> with high number of short calls being setup. This would be especially
> I would dispute this - remember exactly the same users have almost
> certainly logged into an https:// portal - indeed only a small
> percentage of them will start a DTLS session for during any given web
> session. The web seems to still be working.
>

Do you dispute that DTLS key exchange represent additional CPU load? If you
dispute that this is additional load is significant, then we can look at
what percentage of the CPU load associated with the call it represents. For
short calls (10 sec or less) it is going to be a significant portion. This
is additional load on the component that is dealing with media, and the
fact that client have already done key exchange with the server is not
relevant.

> Webservers, web browsers, Sip/xmpp engines, anything offering an https
> management interface, will already have that code

Once again you are talking about signaling/web interfaces that do
not necessarily run on the some network components, ie TLS can be handled
by web server and then signaling sent over some other protocol to the media
server which will need to support DTLS. Also, in case of web servers there
is a way to do the key exchange once per session and reuse TLS connection
and exchanged keys for multiple requests between the same client and
server. I am not sure there is a mechanism in place to do the same with
DTLS key exchanges in media connection.

> There I also disagree. The ability to offer a DTLS connection that
> presents a browser checkable x509 certificate for yourbank.com over the
Do web servers currently validate the remote certificate on DTLS
connections? I assume they do not, so there is no way to validate x509
certificate on the media connection. As far as I know we are not even
supposed to pass DNS names in SDP, so I am not sure what we will be
validating there in the first place.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Fri, 26 Apr 2013 21:10:32 +0100

On 26 Apr 2013, at 20:45, Roman Shpount wrote:

> Pre-warming connection before user consent has some security implications as well. I would much rather see a mechanism to do ICE setup and DTLS key exchange at the same time. Should we look into extending ICE/STUN to carry public/private key exchange?

That's interesting, I'd have to have a _long_ talk with ekr about the security risks in that.

> Do you dispute that DTLS key exchange represent additional CPU load? If you dispute that this is additional load is significant, then we can look at what percentage of the CPU load associated with the call it represents. For short calls (10 sec or less) it is going to be a significant portion. This is additional load on the component that is dealing with media, and the fact that client have already done key exchange with the server is not relevant.

Sorry , I wasn't clear. My point was that there exists a class of application that sets up more TLS connections per second and finds the cpu load 
acceptable. - Webservers. 

> Once again you are talking about signaling/web interfaces that do not necessarily run on the some network components, ie TLS can be handled by web server and then signaling sent over some other protocol to the media server which will need to support DTLS.

Again I wasn't clear. I was talking about your concern about adding large swathes of new code to the device's codebase just for DTLS. 
My point was that if the device has a secure management interface then the huge bulk of that code is probably already on there
- being used to set up TLS connections.
I wasn't thinking about reuse of the data or keys, just the compiled code.

> Also, in case of web servers there is a way to do the key exchange once per session and reuse TLS connection and exchanged keys for multiple requests between the same client and server. I am not sure there is a mechanism in place to do the same with DTLS key exchanges in media connection.

Again, that is an interesting optimization that should probably be applied - how long should a DTLS session be kept around on the off-chance that
the same connection will be re-made? 

> Do web servers currently validate the remote certificate on DTLS connections? I assume they do not, so there is no way to validate x509 certificate on the media connection. As far as I know we are not even supposed to pass DNS names in SDP, so I am not sure what we will be validating there in the first place.

The browser could validate the certificate that was offered over the media channel. That validation would be based on it's existing CA roots. (as used 
to validate TLS certs - but in this case the cert is offered by the media server, not the web server). 

Tim.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 13:20:48 -0700

On 26 April 2013 13:10, Tim Panton <[email-masked]> wrote:
>> Pre-warming connection before user consent has some security implications as
>> well. I would much rather see a mechanism to do ICE setup and DTLS key

That the essence of http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00

In theory, it's possible to squash ICE and DTLS to save round trips.
In practice, it mucks with software layering in nasty ways.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Apr 2013 07:40:54 +0800

On Apr 27, 2013, at 0:53, Roman Shpount <[email-masked]> wrote:

> Have anybody tried an international call with ICE and DTLS enabled? The call setup delay introduced by the combination of the two is long enough to go from being simply annoying to the point of other person hanging up assuming the call is not working. 
> _____________

Funny you should ask. I'm in Taipei now and did a call to Texas from my hotel this morning and call setup time was fine.

With that said I have seen wildly varying call setup times with the same machines and software on the same network setup, so no doubt there are still some lurking bugs. If you can capture traces of long setup times with Firefox or Chrome I would certainly be interested in investigating.

Ekr

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 27 Apr 2013 17:01:01 +0300

I am also puzzled about the request for SDES also in DataChannel.

/Salvatore

On 4/26/13 2:35 PM, Iñaki Baz Castillo wrote:
>
> SDES is obviously requested for legacy interop at RTP layer. Why do we 
> need SDES in DataChannel if this is a complete new technology?
>
> --
> Iñaki Baz Castillo
> <[email-masked] <mailto:[email-masked]>>
>
> El 25/04/2013 23:55, "Ejzak, Richard P (Richard)" 
> <[email-masked] 
> <mailto:[email-masked]>> escribió:
>
>     This raises a further question about SCTP/DTLS for DataChannels.
>      It seems that if we support SDES-SRTP, don't we also need to
>     provide an SDES keying mechanism for DataChannels?  Ekr: What is
>     needed to realize this?
>
>     Richard Ejzak
>
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     <mailto:[email-masked]>
>     JavaScript
>     > > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > > To: 'Cullen Jennings'; [email-masked] <mailto:[email-masked]>
>     > > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > > To: [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Apr 2013 14:17:15 +0000

Hi,

As I've mentioned before, we should really try to avoid solutions that require intermediaries to send reINVITEs - or, more general, send SDP offers.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: IÃ±aki Baz Castillo [[email-masked]]
To: Tim Panton [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

The problem is when EKT is also used and the gateway must send SIP reINVITE by itself as the proposed "solution diagram" shows. That is not just a media gateway.

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

El 26/04/2013 15:16, "Tim Panton" <[email-masked]<mailto:[email-masked]>> escribió:

T.

---

From: Tim Panton <[email-masked]>
Date: Sun, 28 Apr 2013 13:07:50 +0100

> As I've mentioned before, we should really try to avoid solutions that require intermediaries to send reINVITEs - or, more general, send SDP offers.

If you stick to that rule, you'd want rid of ICE, SRTP, BUNDLE and all the other things an intermediary may have to add 
to a plain legacy device's offer in order for it to be acceptable to a browser. 
 
Or in other words: Why is the DTLS re-write especially irksome . ?

T.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 28 Apr 2013 14:14:40 +0200

The problem is not DTLS (which can be handled by a pure media gateway) but
DTLS+EKT which means that the server should generate a reINVITE for legacy
interop (so the gateway would become a complex media+signaling B2BUA).

--
Iñaki Baz Castillo
<[email-masked]>
El 28/04/2013 14:07, "Tim Panton" <[email-masked]> escribió:

> As I've mentioned before, we should really try to avoid solutions that
> require intermediaries to send reINVITEs - or, more general, send SDP
> offers.
>
> Regards,
>
> Christer
>
>
> If you stick to that rule, you'd want rid of ICE, SRTP, BUNDLE and all the
> other things an intermediary may have to add

---

From: <[email-masked]>
Date: Sun, 28 Apr 2013 19:39:00 +0000

Hi,

I prefer having SDES as a possible keying method for WebRTC, mainly for easier interop with non-WebRTC systems. I see a lot of people working on that type of use cases, i.e. a "browser client access" to an existing communication service. 

Markus

---

From: Binod <[email-masked]>
Date: Mon, 29 Apr 2013 10:50:34 +0530

I have been reading the discussion on this topic and I prefer
supporting SDES as a keying method for WebRTC.

Not having SDES will have non trivial impact on interop. With
EKT, there is a signalling complexity of sending re-INVITEs, which
make the gateway complex. Without EKT, you need per-packet
crypto  for media exchange, which is CPU intensive.

The fingerprint verification and all other additional DTLS-SRTP
advantages can still be leveraged when both side support DTLS-SRTP.
And then if a gateway really do not want to use SDES, it can support
DTLS/SDES gateway anyway.

thanks,
Binod.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 Apr 2013 10:29:30 +0200

Would it be possible to get real data on 1) and 2) here, so that we can 
stop talking about "slow" and instead talk about "N milliseconds"?

> sites will pre-warm a DTLS connection so it is ready to go when the 

Can someone create a call setup test that tells us how long it takes to 
set up DTLS?
I'd like to see this statement translated into milliseconds - just 
having the number of milliseconds with current code on a loopback 
interface should give us a lower bound of the issue; we can then make 
things more complex by inserting a non-zero RTT into the mix (should be 
easy if we can coerce our setup to be TURN-server-only).

>
>>
>> 2. High computational load on each call setup. This can be 
>> significant with high number of short calls being setup. This would 
>> be especially significant for any sort of server interfacing WebRTC 
>> or WebRTC to SIP gateway.
>

Can someone translate this statement in to CPU-milliseconds per call setup?

---

From: Tim Panton <[email-masked]>
Date: Mon, 29 Apr 2013 11:30:02 +0100

> crypto  for media exchange, which is CPU intensive.

I've seen this asserted more than once, but I'd love to see a _current_ example where 
you really have an existing network of SRTP/ICE/BUNDLE/RTCP-MUX capable
legacy endpoints that you want to connect to webRTC without a media-level SBC or 
call recording. 

My fear is that people are just basing anti-DTLS opinions on the perceived difficulty of 
building such a network in the future. 

I'm ok with legacy interop as a secondary goal of this WG , but putative-future-legacy interop
is going too far IMHO, especially since it further complicates the already tricky problem of
defining interoperable SDP.

If it is a choice between adding complexity in a legacy gateway or every browser
I'd rather add it in the gateway.

T.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 29 Apr 2013 13:38:05 +0200

On 29.04.13, 12:30, Tim Panton wrote:
> legacy endpoints

Well, in all fairness it would only have to be SRTP/ICE, bundle and
rtcp-mux being optional, wouldn't it?

The above is already a more common combination.

Besides, ICE is easily handled by a light-weight gateway that would only
add a relayed candidate and that doesn't need to understand any sort of
encryption.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Apr 2013 13:49:06 +0200

> I'd rather add it in the gateway.

Hi Tim, let's please separate DTLS and DTLS+EKT:

- DTLS-SRTP:  I agree with you. It seems that people consider it a
barrier for legacy interop (while it seems not so hard as implementing
ICE, bundle, rtcp-mix....). Anyhow a media gateway would do the job,
exactly as when using SDES-SRTP.

- DTLS-EKT-SRTP:  This requires a gateway sending like "re-INVITE" for
common operations as multimedia session transfer, which involves the
gateway becoming both a media gateway and a complex signaling B2BUA
(and we hate that, right?).

So please let's separate DTLS and DTLS+EKT since they are really
different options.

Best regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2013 12:17:25 +0000

Hi,

An intermediary doesn't have to do BUNDLE, and the intremediary can act as ICE lite, and things will still work fine with the rtcweb client.

Regards,

Christer

________________________________________
From: Tim Panton [[email-masked]]
Sent: Sunday, 28 April 2013 3:07 PM
To: Christer Holmberg
Cc: IÃ±aki Baz Castillo; rtcweb_ietf.org
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Hi,

Regards,

Christer

T.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Apr 2013 08:08:02 -0700

Hi Cullen,

Sorry for the delay in replying; it was a long transit back from
Australia.  Some comments in-line.

On Fri, Apr 26, 2013 at 11:23 AM, Cullen Jennings <[email-masked]> wrote:

> disagree with the charter, please remember that it's not fundamentally a
> prediction about what the eventual balance of flows will be.  It's a
> statement about where the balance of effort in the group should go.   To me
> as an individual, it implies that we should not make trade-offs that
> optimize a non-browser use case at the expense of the browser use case
> except in pretty extraordinary circumstances.
> >
> > regards,
>
> Ted, I think rtcweb is about a web brewer being able to communicate to
> lots of things, not just one currently very small island. Our uses and
> discussion from well before this WG was chartered have recognized that to
> be successful, rtrcweb endpoints were going to need to be able to call
> things other than web browsers. You were one of the people that pushed hard
> on the non browser (but also not legacy) uses.
>
>
The non-browser, non-legacy case I believe we need to be particularly aware
of is the mobile application case.  While many of those are based on web
technologies, they are distributed as stand-alone apps.  That means they
can be WebRTC "protocol native" without have the same chrome as a browser.
Mostly that means we can't depend on the *browser* as distinct element just
because we're using web protocols.

That is significantly different from the legacy use case.  I also think it
is different from the "future legacy" use case that others have referred to.

> I agree with your point that the design of any new communication system
> has to deal with the tradeoff between how it work with previous system and
> how easy it is to build. However, in the case here, I tend towards trying
> to make the a new system that can take advantage of an early network effect
> by being able to talk to lots of existing things.

So, this is trade-off that I suspect we disagree on.  I recognize that
interop with existing systems gets you early traction, but it also tends to
force the new system to match the odd angles and corners of whatever
existing system you choose to align with.  Having watched what happened to
SIP with the focus on PSTN interoperability, I think that too much focus on
that legacy interoperability can lose you generality.  Once that's lost
(even in perception among the developer community), it's very difficult to
get back.

It think the system we're building now potentially has useful general
properties, so I don't want to over-optimize to a legacy use case that
limits that generality (by reducing its security or in other terms).

YMMV,

Ted

---

From: Dan Wing <[email-masked]>
Date: Mon, 29 Apr 2013 22:12:47 -0700

> (and we hate that, right?).

That re-INVITE is necessary because Security Descriptions changed the SRTP key, and Security Descriptions needs to send that re-INVITE.  It is not the fault of DTLS-SRTP-EKT, because it doesn't send a re-INVITE when the SRTP key changes (EKT handles key changes).  

If the objection is the re-INVITE when SRTP keys change, the solution is eliminating Security Descriptions.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Apr 2013 16:51:43 +0200

> If the objection is the re-INVITE when SRTP keys change, the solution is eliminating Security Descriptions.

The "solution" cannot be a media gateway that also must behave as a
complex signaling B2BUA originating re-INVITEs by itself, since that
means that a simple signaling pure proxy scenario is unfeasible.

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

---

From: Dan Wing <[email-masked]>
Date: Tue, 30 Apr 2013 08:25:30 -0700

> means that a simple signaling pure proxy scenario is unfeasible.

Webrtc has already made decisions that make a pure proxy unfeasible with most legacy SIP networks:  ICE-Lite, RTP/RTCP multiplexing on the same port, and bundling. Those are trade-offs against interoperability but in favor of a better webrtc design.
 
I would rather the complexity and security weakness of Security Descriptions be confined to the interworking device, rather than exist forever in webrtc.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Apr 2013 18:09:11 +0200

2013/4/30 Dan Wing <[email-masked]>:
> Webrtc has already made decisions that make a pure proxy unfeasible with most legacy SIP networks:  ICE-Lite, RTP/RTCP multiplexing on the same port, and bundling.

ICE / rtcp-mux / bundle does not require sending a reINVITE by an
intermediary signaling server *at all*, but just a media gateway.

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

---

From: Dan Wing <[email-masked]>
Date: Tue, 30 Apr 2013 09:23:13 -0700

> intermediary signaling server *at all*, but just a media gateway.

Agreed, they work differently.  

But ICE and RTP/RTCP multiplexing require participation on the media path (that is, an SBC or SBC-like function), and cannot be accomplished with a SIP proxy.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Apr 2013 18:29:04 +0200

> But ICE and RTP/RTCP multiplexing require participation on the media path (that is, an SBC or SBC-like function), and cannot be accomplished with a SIP proxy.

Of course, but a SIP proxy (which cannot generate a reINVITE by
itself) is really different than a B2BUA (which breaks pure signaling
scenarios). DTLS+EKT requires a B2BUA so that's not good.

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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 1 May 2013 05:10:21 +0000

On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <[email-masked]> wrote:

> Would it be possible to get real data on 1) and 2) here, so that we can stop talking about "slow" and instead talk about "N milliseconds"?
> 

I did try and round up a bunch of data for ping times from India to Singapore as some people were suggesting these were 1500ms. 

I got measurements from both home DSL and more business class from a range of sources in India. It seems that anywhere one could run video, you can ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than 250 ms one way. If someone has an actually link that is getting 1500 ms out of India, I'd love to get the info so I can see what I can learn (the buffer bloat folks want to hear about this :-)