Subject: [rtcweb] SDES draft posted

From: Oscar Ohlsson <[email-masked]>
Date: Tue, 24 Jan 2012 14:04:36 +0100

Hi,

I've submitted a draft that explains the benefits of allowing SDES as an optional keying mechanism in WebRTC. It also attempts to address the security concerns that have been raised on this mailing list and in the security draft.

http://www.ietf.org/id/draft-ohlsson-rtcweb-sdes-support-00.txt

The purpose of the draft is to collect all arguments into one place and try to stimulate discussion so that a decision can be reached.

Best regards,

Oscar Ohlsson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Jan 2012 08:54:44 -0800

Hi Oscar.

Thanks for writing this up.

I'm not sure I 100% agree about the security claims you make in Section 3,
but I think that Section 2.1-2.2 is a good summary of the relevant interop
issues.

A big question for me is to what extent existing SIP systems are prepared
to do SDES-SRTP in practice. If the answer is, as you suggest, that
most are, then it sure makes SDES-SRTP look like an attractive option
for interop with those endpoints, especially if we can use it in lieu of
RTP.

Best,
-Ekr

On Tue, Jan 24, 2012 at 5:04 AM, Oscar Ohlsson
<[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Jan 2012 11:47:56 -0600

> for interop with those endpoints, especially if we can use it in lieu of

I believe SRTP with SDES keying is the most commonly deployed method 
today. That doesn't mean it's supported by any large percentage of SIP 
endpoints, but it's a large percentage of those that support SRTP :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Jan 2012 10:24:09 -0800

On Tue, Jan 24, 2012 at 9:47 AM, Kevin P. Fleming <[email-masked]> wrote:
> I believe SRTP with SDES keying is the most commonly deployed method today.
> That doesn't mean it's supported by any large percentage of SIP endpoints,
> but it's a large percentage of those that support SRTP :-)

I'm sure that's true. It's deployment of the fraction of SIP endpoints that
is the question I think is most interesting.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Jan 2012 13:24:46 -0500

If we allow SRTP to improve the interop while disregarding the associated
security concerns, why won't we allow RTP as well? It would address a much
wider set of interop concerns. To be honest, anything (including SRTP-DTLS)
is insecure without end-to-end identity verification, so we should either
make DTLS-SRTP with identity verification mandatory or allow insecure
communications.
_____________
Roman Shpount

On Tue, Jan 24, 2012 at 8:04 AM, Oscar Ohlsson
<[email-masked]>wrote:

> Hi,
>
> I've submitted a draft that explains the benefits of allowing SDES as an
> optional keying mechanism in WebRTC. It also attempts to address the
> security concerns that have been raised on this mailing list and in the
> security draft.
>
> The purpose of the draft is to collect all arguments into one place and
> try to stimulate discussion so that a decision can be reached.
>
> Best regards,
>
> Oscar Ohlsson

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Jan 2012 13:24:51 -0600

On 01/24/2012 12:24 PM, Eric Rescorla wrote:
> On Tue, Jan 24, 2012 at 9:47 AM, Kevin P. Fleming<[email-masked]>  wrote:

SIPit 29 - 80% of endpoints.
SIPit 28 - 56% of endpoints.
SIPit 27 - 60% of endpoints.

I'd say it's a fair bet that at least 50% of the SIP UA implementations 
available on the market (by market share, not count of implementations) 
support SRTP with SDES.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Jan 2012 11:29:09 -0800

On Jan 24, 2012, at 11:24 , Kevin P. Fleming wrote:

> I'd say it's a fair bet that at least 50% of the SIP UA implementations available on the market (by market share, not count of implementations) support SRTP with SDES.

Got any feel for what the percentages of ports on gateways to the PSTN support SDES/SRTP ?

My feel is it also pretty high but obviously I end up with a sample set pretty skewed towards Cisco equipment.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jan 2012 17:23:49 -0800

The majority of PSTN gateways I see at customer sites (enterprise models)
support SDES/SRTP now. 

There are still some interop bugs here and there, but they are getting
cleaned up. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Tuesday, January 24, 2012 11:29 AM
To: Kevin P. Fleming
Cc: [email-masked]
Subject: Re: [rtcweb] SDES draft posted

Got any feel for what the percentages of ports on gateways to the PSTN
support SDES/SRTP ?

My feel is it also pretty high but obviously I end up with a sample set
pretty skewed towards Cisco equipment.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 25 Jan 2012 08:27:03 +0100

24 jan 2012 kl. 18:47 skrev Kevin P. Fleming:

> I believe SRTP with SDES keying is the most commonly deployed method today. That doesn't mean it's supported by any large percentage of SIP endpoints, but it's a large percentage of those that support SRTP :-)

While everyone knows that DTLS is the way to go, they haven't developed the support for it yet, everyone is waiting for everyone else (like we discussed before). From what I hear from OpenSSL and GnuTLS developers, the code is there and ready to use now. 

I don't think we should use this as a reference for making any decisions in rtcweb. Distributing keys in the open is not something I want to see in the web space too. Hopefully we can move away from it in the SIP world.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 25 Jan 2012 08:29:54 +0100

> I'd say it's a fair bet that at least 50% of the SIP UA implementations available on the market (by market share, not count of implementations) support SRTP with SDES.

This is NOT the installed base - it's available on the market. The installed base has a very low amount of SRTP implementations that are interoperable.

/O

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 25 Jan 2012 08:55:13 +0100

The PSTN gateways I see also support SDES/SRTP now. So I also support SDES.

On Wed, Jan 25, 2012 at 2:23 AM, Bernard Aboba <[email-masked]>wrote:

> The majority of PSTN gateways I see ... support SDES/SRTP now.
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 14:04:19 -0700

On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote:

> This is NOT the installed base - it's available on the market. The installed base has a very low amount of SRTP implementations that are interoperable

Uh, I pretty much disagree with that thought I don't have hard stats I can point you at. A large percentage of the deployed endpoints and gateways do work with SRTP and I don't see a lot of bugs logged against them.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 27 Jan 2012 14:25:25 +0100

Also I don't have hard stats but of course SDES is what is implemented today in endpoints and gateways that have a requirement for SRTP which I think is a large percentage and growing. SDES is also pretty much interoperable between implementations the main issues that arise are around best effort SRTP and that fact that sdp-neg (RFC 5939) is not widely implemented.

So if SDES, DTLS-SRTP and possibly even RTP are going to be options in RTCWEB the issue that needs to be clearly specified is the negotiation mechanism be it RFC 5939 or something else. I don't believe that a fallback mechanism based on failure and re-try would be acceptable.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: 26 January 2012 21:04
> To: Olle E.Johansson
> Cc: [email-masked]
> >> I'd say it's a fair bet that at least 50% of the SIP UA
> implementations available on the market (by market share, not count of
> implementations) support SRTP with SDES.
> >
> > This is NOT the installed base - it's available on the market. The
> installed base has a very low amount of SRTP implementations that are
> interoperable
> 
> Uh, I pretty much disagree with that thought I don't have hard stats I
> can point you at. A large percentage of the deployed endpoints and
> gateways do work with SRTP and I don't see a lot of bugs logged against
> them.
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 27 Jan 2012 13:51:25 +0000

Andy,

Even though the discussion is to provide RTP, SDES, DTLS-SRTP,
till now I didn't see anybody ask for fallback mechanism within these 
mechanism as it will lead to bid-down attack. I agree with you that 
any fallback mechanism makes the implementation Complex and unacceptable. 

Also, I could not see the point in supporting both SDES and DTLS-SRTP.
In case WebRTC webserver is always trusted, SDES is the solution and
Webserver is not trusted, DTLS-SRTP is the solution. 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Hutton, Andrew
>Sent: Friday, January 27, 2012 6:55 PM
>To: Cullen Jennings; Olle E.Johansson
>Cc: [email-masked]
>Also I don't have hard stats but of course SDES is what is implemented
>today in endpoints and gateways that have a requirement for SRTP which I
>think is a large percentage and growing. SDES is also pretty much
>interoperable between implementations the main issues that arise are
>around best effort SRTP and that fact that sdp-neg (RFC 5939) is not
>widely implemented.
>
>So if SDES, DTLS-SRTP and possibly even RTP are going to be options in
>RTCWEB the issue that needs to be clearly specified is the negotiation
>mechanism be it RFC 5939 or something else. I don't believe that a
>fallback mechanism based on failure and re-try would be acceptable.
>
>Regards
>Andy
>
>
>
>> gateways do work with SRTP and I don't see a lot of bugs logged
>> against them.
>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Jan 2012 19:37:35 -0800

> So if SDES, DTLS-SRTP and possibly even RTP are going to be options in RTCWEB the issue that needs to be clearly specified is the negotiation mechanism be it RFC 5939 or something else. I don't bel…

[BA] I agree that multiple rounds of offer/answer is undesirable.  However, I am not convinced that RFC 5939 is the solution,  based on the (lack of) deployment. 

This seems to point to a reduction in the number of potential options.  From the discussion that has occurred so far I believe that we can probably dispense with RTP, except for debugging and require SRTP both be implemented and used. 

This leaves us with SAVP(F) as the profile, with SDES and/or DTLS/SRTP as the offered keying mechanism.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Jan 2012 10:31:45 -0700

Uh, just for the record ... with my chair hat on. 

There are clearly some people that want more than just DTLS-SRTP and they want fallback negotiation. I'm not making any consensus call, and I'm not saying there is consensus for one thing or another - I'm just pointing out there are people that want this.

Cullen <rtcweb co-chai>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 29 Jan 2012 15:06:13 +0100

See below.

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 27 January 2012 13:51
> To: Hutton, Andrew; Cullen Jennings; Olle E.Johansson
> Cc: [email-masked]
> Subject: RE: [rtcweb] SDES draft posted
> 
> Andy,
> 

[AndyH] - I did not say it had to be complex or that any fallback mechanism would be unacceptable. 

> Webserver is not trusted, DTLS-SRTP is the solution.

[AndyH] - I don't think the choice can be made on the basis of whether the webserver is as trusted DTLS-SRTP may be desirable over SDES even when the webserver is trusted. It could be for example that SDES is used as an interim solution until a gateway is updated with support for DTLS-SRTP and after upgrading the gateway DTLS-SRTP should just work. 

> Behalf

---

From: Randell Jesup <[email-masked]>
Date: Sun, 29 Jan 2012 09:27:47 -0800

> [AndyH] - I don't think the choice can be made on the basis of whether the webserver is as trusted DTLS-SRTP may be desirable over SDES even when the webserver is trusted. It could be for example t…

Right, but that brings in the entire bid-down (to SDES) issue, and 
complexity in signalling this.

My opinion is we first have to decide if we will talk *directly* to 
legacy endpoints, without a WebRTC-compliant gateway.  This means 
requiring support for ICE and a security mechanism (SDES or DTLS-SRTP, 
and Cullen indicates some endpoints do support DTLS-SRTP apparently) or 
unsecured RTP.  We can assume the JS will take the ROAP or JSEP offer 
and translate it into SIP/SDP (or the server will).  Note that ICE is 
required as part of the "don't be a DDOS element" requirement.

Next we have to decide what's the minimum security level required - RTP, 
SDES, or DTLS-SRTP.

Next we have to decide how bid-down attacks would be dealt with, 
especially if you don't trust the server.   While in some/many cases we 
would trust the server, there are other use-cases where we certainly 
don't (and having multiple levels of security will invoke our having to 
decide how to show this (understandably!) to users in browser chrome, 
since we can't allow the app to control showing security).

A proposal for supporting legacy devices must answer all of these (in 
some manner) to be a viable candidate for consideration.

My personal (and Mozilla's opinion) is strongly in favor of strong 
privacy & security guarantees, and in particular requiring DTLS-SRTP 
between WebRTC clients.  If a solution to the above issues without 
compromising WebRTC<->WebRTC security can be found, I'm open.  I haven't 
heard one yet, and so lean towards hard security guarantees and 
requiring a gateway to talk to legacy.  So if you do know how to do the 
entire package, we need that proposal on the table ASAP.

-- 
Randell Jesup
[email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 30 Jan 2012 05:54:21 +0100

On 1/29/2012 17:28am Randell wrote

> > [AndyH] - I don't think the choice can be made on the basis of
> whether the webserver is as trusted DTLS-SRTP may be desirable over
> SDES even when the webserver is trusted. It could be for example that
> SDES is used as an interim solution until a gateway is updated with
> support for DTLS-SRTP and after upgrading the gateway DTLS-SRTP should
> just work.
> 
> 

[AndyH] - Agreed we need to way up the pros and cons however I don't think choosing SDES over DTLS-SRTP based on whether the webserver is trusted is the way forward. I see arguments that actually fallback to SDES would not really be a bid-down but if it is considered to be such by the security experts then I don't see a way forward for SDES.

> legacy endpoints, without a WebRTC-compliant gateway.  

[AndyH] - I don't see this as a decision we need to make we have to assume that gateways are going to be needed in some scenarios. We should not do anything that prevents a media gateway being deployed.

>This means

[AndyH] - Agreed the whole issue for me relates to whether SDES is considered to be significantly lower security level to DTLS-SRTP or not.

> since we can't allow the app to control showing security).
[AndyH] - If fallback to SDES is really a bid-down attack then I don't see how SDES can be offered in the 1st place. What I don't want to see is a decision to offer SDES being made on the basis that the server is trusted. However it might be possible to offer both SDES and DTLS-SRTP only in the case when the server is trusted. 

> entire package, we need that proposal on the table ASAP.
[AndyH] Actually I am tending to agree with you my original post was only stating that if both SDES and DTLS-SRTP are offered then we must specify the fallback method.  

> >>> today in endpoints and gateways that have a requirement for SRTP
> which
> >> I
> >>>> implementations available on the market (by market share, not
> count
> >> of
> >>>> Uh, I pretty much disagree with that thought I don't have hard
> stats
> >> I

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Jan 2012 06:44:26 +0000

<snip> [AndyH] - If fallback to SDES is really a bid-down attack then I don't see how SDES can be offered in the 1st place. </snip>

The real question is "fallback to SDES is really bid-down attack" as the webserver has the access to the crypto keys and possible to intercept the media without trace. Based on IETF-82 security presentation and the mailing discussion, I'm convinced that SDES will lead to bid-down attack. Sec 3.2.1 of draft-ohlsson-rtcweb-sdes-support-00 also indicates the same. 

" If both users read their respective fingerprint values over the voice channel then they can detect if the
   conversation is being intercepted.  However, it is very unlikely that the average user would bother doing this."

Please note with the above statement that SRTP-DTLS is the only mechanism even for the power-user to identify whether the data is intercepted or not and it is not possible in SDES. 

In case there is no requirement to identify whether the webserver intercept or not, SRTP-DTLS is not required and SDES will sufficient for WebRTC. If the discussion is between different key mechanism like ZRTP, SRTP-DTLS, then it is key mechanism negotiation and not fallback. So Still, I didn't see the need for fallback mechanism between SRTP-DTLS to SDES within WebRTC. 

Thanks
Partha

>Sent: Monday, January 30, 2012 10:24 AM
>To: Randell Jesup; [email-masked]
>> >> Even though the discussion is to provide RTP, SDES, DTLS-SRTP, till
>> >> now I didn't see anybody ask for fallback mechanism within
>> these
>> >> In case WebRTC webserver is always trusted, SDES is the solution
>> >> and Webserver is not trusted, DTLS-SRTP is the solution.
>[AndyH] - Agreed we need to way up the pros and cons however I don't
>think choosing SDES over DTLS-SRTP based on whether the webserver is
>trusted is the way forward. I see arguments that actually fallback to
>SDES would not really be a bid-down but if it is considered to be such
>by the security experts then I don't see a way forward for SDES.
>
>>
>[AndyH] - I don't see this as a decision we need to make we have to
>assume that gateways are going to be needed in some scenarios. We should
>not do anything that prevents a media gateway being deployed.
>
>>This means
>> Next we have to decide what's the minimum security level required -
>> RTP, SDES, or DTLS-SRTP.
>>
>
>[AndyH] - Agreed the whole issue for me relates to whether SDES is
>considered to be significantly lower security level to DTLS-SRTP or not.
>
>
>>
>[AndyH] - If fallback to SDES is really a bid-down attack then I don't
>see how SDES can be offered in the 1st place. What I don't want to see
>is a decision to offer SDES being made on the basis that the server is
>trusted. However it might be possible to offer both SDES and DTLS-SRTP
>only in the case when the server is trusted.
>
>[AndyH] Actually I am tending to agree with you my original post was
>only stating that if both SDES and DTLS-SRTP are offered then we must
>specify the fallback method.
>
>
>> >
>> >> Thanks
>> >> Partha
>> >>
>> >>> So if SDES, DTLS-SRTP and possibly even RTP are going to be
>options
>> in

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Jan 2012 01:13:11 -0800

On 1/29/2012 10:44 PM, Ravindran, Parthasarathi wrote:
> <snip>  [AndyH] - If fallback to SDES is really a bid-down attack then I don't see how SDES can be offered in the 1st place.</snip>
>

Correct.  There's no doubt that SDES is less secure than DTLS-SRTP, 
though the added security of DTLS-SRTP may be minor if there's no way to 
authenticate whom you're connected to (i.e. detect MITM attacks).  We 
should be able to do identity validation, however, so the added security 
is significant.  I have a good usecase ("pokerstars.net") where this 
added security is really important, where the central server being used 
may have been compromised by someone wanting to listen in on you 
planning strategy/bluffs/etc with another player while waiting for your 
round.  There are other ones involving political movements.

> Please note with the above statement that SRTP-DTLS is the only mechanism even for the power-user to identify whether the data is intercepted or not and it is not possible in SDES.

Exactly.

-- 
Randell Jesup
[email-masked]