Subject: [rtcweb] Final plea about SRTP

From: Roman Shpount <[email-masked]>
Date: Wed, 2 May 2012 12:03:46 -0400

I know there was a consensus call on this list that SRTP shall be used for
all the calls in WebRTC, but I still do not understand the justification
for this requirement for WebRTC applications delivered over HTTP with no
identity. For such scenarios SRTP (even DTLS-SRTP) serves almost no
purpose. If application is delivered over HTTP attacker can spoof the
entire web site. It is trivial if the attacker is on the communications
path. If attacker is seating in the airport using the same network, it can
put itself on the communications path using arp cache poisoning. Once the
web site is spoofed, any type of man in the middle attack can be
implemented. If DTLS-SRTP is used user can detect the attack by checking
the key signature, but in reality very few people will do this.

The main argument to require SRTP everywhere was that it does not break
anything. But neither would naming all the API methods in High Elfish.
Either requirement does not break things, but make working with WebRTC
harder then it should. At the same time both of those requirements are
completely unjustified.

Furthermore, assumption on this list that most of the WebRTC use would be
peer-to-peer communications between browsers with all the rest of the
communication modes, such as calling automated services or PSTN being
insignificant. I simply do not agree to this point of view. I expect that
communication with automated services, such as video greeting cards or
voice blogging, would be a significant portion of WebRTC user base. If such
automated service is deployed as a plain HTTP web site, it should be able
to communicate with web browsers using RTP. SRTP in such case would serve
no purpose.

Finally, requiring secure communications for everything is going against
the way most of the web works. Most of it is not secured and only requires
secure communications when secure (HTTPS) web site is accessed. I think it
should be the same for WebRTC, with DTLS-SRTP required when connected to
HTTPS web site and plain RTP allowed when connected to plan HTTP.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 May 2012 15:32:38 -0600

Roman, 

One comment on this - I think people understand there could be services with no security requirements that could run over RTP, and HTTP, with no identity. But we need to have a secure solution for some other services. The questions is once you have a secure solution, what is the incentive to also support an insecure solution - so far no one has come up with a super compelling story about dealing with the bid down and I suspect that lots of people did not view the overhead of running the secure version as all that high. I suspect that is part of why the decisions went the way it did - basically people agreed we needed a secure solution, and when they considered also having an insecure solution, they saw lots of complications of doing both and not much gain in the insecure solution over the secure solution. 

Cullen

On May 2, 2012, at 10:03 AM, Roman Shpount wrote:

> I know there was a consensus call on this list that SRTP shall be used for all the calls in WebRTC, but I still do not understand the justification for this requirement for WebRTC applications delivered over HTTP with no identity. For such scenarios SRTP (even DTLS-SRTP) serves almost no purpose. If application is delivered over HTTP attacker can spoof the entire web site. It is trivial if the attacker is on the communications path. If attacker is seating in the airport using the same network, it can put itself on the communications path using arp cache poisoning. Once the web site is spoofed, any type of man in the middle attack can be implemented. If DTLS-SRTP is used user can detect the attack by checking the key signature, but in reality very few people will do this.
> 
> The main argument to require SRTP everywhere was that it does not break anything. But neither would naming all the API methods in High Elfish. Either requirement does not break things, but make working with WebRTC harder then it should. At the same time both of those requirements are completely unjustified.
> 
> Furthermore, assumption on this list that most of the WebRTC use would be peer-to-peer communications between browsers with all the rest of the communication modes, such as calling automated services or PSTN being insignificant. I simply do not agree to this point of view. I expect that communication with automated services, such as video greeting cards or voice blogging, would be a significant portion of WebRTC user base. If such automated service is deployed as a plain HTTP web site, it should be able to communicate with web browsers using RTP. SRTP in such case would serve no purpose.
> 
> Finally, requiring secure communications for everything is going against the way most of the web works. Most of it is not secured and only requires secure communications when secure (HTTPS) web site is accessed. I think it should be the same for WebRTC, with DTLS-SRTP required when connected to HTTPS web site and plain RTP allowed when connected to plan HTTP.
> _____________
> Roman Shpount
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 May 2012 18:16:14 -0400

Cullen,

I do not think bid down is an issue. It should be clearly specified when
the peer connection is created that it is SRTP or RTP and never should one
become another. And if key exchange mechanism selection is not enforced, I
would consider bid down from DTLS to SDES SRTP just as much of an issue.

Numerous reasons for RTP support have been mentioned on this list (legacy
interop, easier to implement, easier to debug, quicker to setup, can be
used from a location from which encrypted communications are not allowed)
but as far as I know none of them have been considered compelling by the
people on this list. As everyone have mentioned before, requiring SRTP does
not really break anything, but, from my point of view, it just makes
implementation of some services more difficult for no apparent reason. I
simply see this as a general design flaw introduced based on FUD.
_____________
Roman Shpount

On Wed, May 2, 2012 at 5:32 PM, Cullen Jennings <[email-masked]> wrote:

>
> Roman,
>
> One comment on this - I think people understand there could be services
> with no security requirements that could run over RTP, and HTTP, with no
> identity. But we need to have a secure solution for some other services.
> The questions is once you have a secure solution, what is the incentive to
> also support an insecure solution - so far no one has come up with a super
> compelling story about dealing with the bid down and I suspect that lots of
> people did not view the overhead of running the secure version as all that
> high. I suspect that is part of why the decisions went the way it did -
> basically people agreed we needed a secure solution, and when they
> considered also having an insecure solution, they saw lots of complications
> of doing both and not much gain in the insecure solution over the secure
> solution.
>
> Cullen
>
>
>
> > I know there was a consensus call on this list that SRTP shall be used
> for all the calls in WebRTC, but I still do not understand the
> justification for this requirement for WebRTC applications delivered over
> HTTP with no identity. For such scenarios SRTP (even DTLS-SRTP) serves
> almost no purpose. If application is delivered over HTTP attacker can spoof
> the entire web site. It is trivial if the attacker is on the communications
> > Furthermore, assumption on this list that most of the WebRTC use would
> be peer-to-peer communications between browsers with all the rest of the

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 May 2012 17:41:36 -0700

At IETF 83,  Dan showed some slides relating to SRTP/RTP gateways that
seemed to cover the "extreme legacy" case quite well. 

In those slides, the "RTCWEB" components were still talking SRTP, so they
could be said to be compliant with a "mandatory to implement, mandatory to
use" posture.   Yet, the circa 2005 IP phone still got to receive and send
RTP.  

Since the "extreme legacy" cases are solvable via gateways, and the
performance impact and cost on virtually any new hardware (PC/tablet/mobile)
is minimal, it seems to me that making SRTP mandatory to implement and use
has little downside.

A few years ago, the thought of turning on SRTP by default was a bit scary
(mostly because of potential interop issues, not cost).  However, today
turning it on by default "just works" with minimal performance impact or
other hassles (other than occasional interop gremlins).  By the time RTCWEB
is widely deployed any argument against SRTP will probably be vestigial.

Given this, it seems to me that the "right thing" is for SRTP to be
mandatory to implement and use, especially if SDES is available, so the
likelihood of interoperability will be high.   

Roman,

One comment on this - I think people understand there could be services with
no security requirements that could run over RTP, and HTTP, with no
identity. But we need to have a secure solution for some other services. The
questions is once you have a secure solution, what is the incentive to also
support an insecure solution - so far no one has come up with a super
compelling story about dealing with the bid down and I suspect that lots of
people did not view the overhead of running the secure version as all that
high. I suspect that is part of why the decisions went the way it did -
basically people agreed we needed a secure solution, and when they
considered also having an insecure solution, they saw lots of complications
of doing both and not much gain in the insecure solution over the secure
solution.

Cullen

> I know there was a consensus call on this list that SRTP shall be used for
all the calls in WebRTC, but I still do not understand the justification for
this requirement for WebRTC applications delivered over HTTP with no
identity. For such scenarios SRTP (even DTLS-SRTP) serves almost no purpose.
If application is delivered over HTTP attacker can spoof the entire web
site. It is trivial if the attacker is on the communications path. If
attacker is seating in the airport using the same network, it can put itself
on the communications path using arp cache poisoning. Once the web site is
spoofed, any type of man in the middle attack can be implemented. If
DTLS-SRTP is used user can detect the attack by checking the key signature,
but in reality very few people will do this.
peer-to-peer communications between browsers with all the rest of the
communication modes, such as calling automated services or PSTN being
insignificant. I simply do not agree to this point of view. I expect that
communication with automated services, such as video greeting cards or voice
blogging, would be a significant portion of WebRTC user base. If such
automated service is deployed as a plain HTTP web site, it should be able to
communicate with web browsers using RTP. SRTP in such case would serve no
purpose.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 May 2012 11:48:33 -0400

On Wed, May 2, 2012 at 8:41 PM, Bernard Aboba <[email-masked]>wrote:

> *A few years ago, the thought of turning on SRTP by default was a bit
> scary (mostly because of potential interop issues, not cost).  However,
> today turning it on by default “just works” with minimal performance impact
> or other hassles (other than occasional interop gremlins).  By the time
> RTCWEB is widely deployed any argument against SRTP will probably be
> vestigial.*
>
> *Given this, it seems to me that the “right thing” is for SRTP to be
> likelihood of interoperability will be high.   *****
>
First of all, SDES-SRTP in combination with HTTP delivered application
provides no security at all. If you argue that you need SDES-SRTP for
interop, you might add support for RTP just as well.

Second, we just went through a couple of large scale SDES-SRTP deployments.
Virtually every device had some issues. Even though a lot of those issues
were not critical (like using RTP encryption routines to encrypt RTCP),
they were wide spread. What it indicates, is that even though SRTP is
widely implemented, it does not get nearly as much use as plain RTP. Even
though it is supported in the datasheet, it is often a datasheet support
only. Another indication of this is the state of libsrtp. It is widely used
to implement SRTP support in open source (and probably in quite a few
closed source) projects. At the same time it has issues that would had to
be addressed if it had any real life use. One examples is crashing on out
of order SRTCP packets which, even though addressed in libsrtp svn, is
present in release source code distribution that is commonly used. Another
example is random number generator that stops operating after a certain
number of calls which is not addressed anywhere. All of this can be
addressed given enough motivation, but this will take time.

Keep in mind, I am not saying that SRTP should not be a MUST implement
feature, and that plain RTP should be allowed from HTTPS sessions. What I
am saying that the value of SDES-SRTP for interop is questionable
(certainly less then value of plain RTP), and SRTP from HTTP session with
no identity provides no security, so it has little value.
_____________
Roman Shpount

---

From: jesse <[email-masked]>
Date: Thu, 3 May 2012 09:36:24 -0700

> At IETF 83,  Dan showed some slides relating to SRTP/RTP gateways that
seemed to cover the “extreme legacy” case quite well.
>
> In those slides, the “RTCWEB” components were still talking SRTP, so they
could be said to be compliant with a “mandatory to implement, mandatory to
use” posture.   Yet, the circa 2005 IP phone still got to receive and send
RTP.
>
> Since the “extreme legacy” cases are solvable via gateways,

First of all, solvable via gateway is a clumsy solution. For most small end
users, support and maintain gateway for srtp takes extra certain effort.
Very few VoIP systems make srtp default unless the whole system is provided
by big vendors.

Second, those are not extreme legacy. There are tons of traditional VoIP
systems there.

rtcweb is proposing a high standard, but "no legacy system should be left
behind" if the objective is to make rtcweb accessible everywhere and
everydevice.

> and the performance impact and cost on virtually any new hardware
(PC/tablet/mobile) is minimal, it seems to me that making SRTP mandatory to
implement and use has little downside.
>
> A few years ago, the thought of turning on SRTP by default was a bit
vestigial.
>
> Given this, it seems to me that the “right thing” is for SRTP to be
> >
> > Finally, requiring secure communications for everything is going
against the way most of the web works. Most of it is not secured and only
requires secure communications when secure (HTTPS) web site is accessed. I
think it should be the same for WebRTC, with DTLS-SRTP required when
connected to HTTPS web site and plain RTP allowed when connected to plan
HTTP.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 May 2012 08:21:01 +0200

Hi Roman,

In my role as a WG chair I have to say that the decision to make SRTP
mandatory to use for WebRTC had a very strong consensus behind it. Yes,
there are some few individuals like yourself that are on the rough side
of this decision.

My personal opinion is that the discussion so far in this thread has
raised most of the issues with supporting both. I think the bid-down
problem is one of the largest for most people. I also see a great
benefit with always using SRTP, in that we will get rid of RTP profile
negotiation. There will be no need to support any other RTP profile than
SAVPF.

Cheers

Magnus

On 2012-05-03 17:48, Roman Shpount wrote:
> 
> On Wed, May 2, 2012 at 8:41 PM, Bernard Aboba <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     *A few years ago, the thought of turning on SRTP by default was a
>     bit scary (mostly because of potential interop issues, not cost). 
>     However, today turning it on by default “just works” with minimal
>     performance impact or other hassles (other than occasional interop
>     gremlins).  By the time RTCWEB is widely deployed any argument
>     against SRTP will probably be vestigial.*
> 
>     mandatory to implement and use, especially if SDES is available, so
>     the likelihood of interoperability will be high.   *____
> 
> Second, we just went through a couple of large scale SDES-SRTP
> deployments. Virtually every device had some issues. Even though a lot
> of those issues were not critical (like using RTP encryption routines to
> encrypt RTCP), they were wide spread. What it indicates, is that even
> though SRTP is widely implemented, it does not get nearly as much use as
> plain RTP. Even though it is supported in the datasheet, it is often a
> datasheet support only. Another indication of this is the state of
> libsrtp. It is widely used to implement SRTP support in open source (and
> probably in quite a few closed source) projects. At the same time it has
> issues that would had to be addressed if it had any real life use. One
> examples is crashing on out of order SRTCP packets which, even though
> addressed in libsrtp svn, is present in release source code distribution
> that is commonly used. Another example is random number generator that
> stops operating after a certain number of calls which is not addressed
> anywhere. All of this can be addressed given enough motivation, but this
> will take time.
> 
> feature, and that plain RTP should be allowed from HTTPS sessions. What
> I am saying that the value of SDES-SRTP for interop is questionable
> (certainly less then value of plain RTP), and SRTP from HTTP session
> with no identity provides no security, so it has little value.
> _____________
> Roman Shpount
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Fri, 04 May 2012 08:30:04 +0200

> negotiation. There will be no need to support any other RTP profile than

So next main points to be defined, as far as i understand, is by
consensus working on key exchange methods that could be more or less:
- Use only DTLS-SRTP (as it is)
- Use only DTLS-SRTP-EKT
- Use DTLS-SRTP + SDES-SRTP

Other than this i would also suggest to suggest discussing about the
"Authentication" of the call, that currently with DTLS-SRTP can be:
- Based on idP (external identity provide)
- Unauthorized

I would also introduce the ability to verify the DTLS-SRTP call directly
and without intermediary (no trusted third party like idP), with methods
such as SAS.

That's the only way to achieve the "end-to-end security" property that
DTLS-SRTP would like to bring in WebRTC standard.

Otherwise DTLS-SRTP will provide "end-to-end encryption with end-to-site
security" but NO end-to-end security.

Fabio

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 May 2012 13:52:56 +0200

Fabio,

Yes the topics you raise are all suitable for continued discussion and
for future determination of what the consensus is on those.

Cheers

Magnus Westerlund
(As WG chair)

-- 

Magnus Westerlund

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 May 2012 12:41:10 -0400

> there are some few individuals like yourself that are on the rough side

Let's hope this will work in real life use cases. If it does not (which is
what I believe, but I can certainly be wrong), then RTP can be put back at
1.1 version of the standard.

 I think the bid-down problem is one of the largest for most people.

I do not think we need to support auto-negotiation of RTP vs SRTP. Also,
RTP should not be allowed from HTTPS sessions, so I do not think bid down
is a problem at all.

I also see a great benefit with always using SRTP, in that we will get rid
> of RTP profile

I do see a benefit of using one RTP profile only, but this will require
WebRTC to use yet another feature that had almost no real life use. This
will also ensure that RTCP will need to be re-encoded (as probably RTP)
when processing calls to anything outside of WebRTC world.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Fri, 04 May 2012 13:04:15 -0400

On 5/4/2012 12:41 PM, Roman Shpount wrote:
>
> On Fri, May 4, 2012 at 2:21 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:

> RTP should not be allowed from HTTPS sessions, so I do not think bid
> down is a problem at all.

You forget that bid-down includes bid-downs by the JS or server (which 
are not trusted in our model), not just by on-path attackers.

>     I also see a great benefit with always using SRTP, in that we will
>     get rid of RTP profile
>     negotiation. There will be no need to support any other RTP profile
>     than SAVPF.
>

I used to work on hardware endpoints that have been using SAVPF since 
2004, with hundreds of thousands of units in the field.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 May 2012 13:45:46 -0400

On Fri, May 4, 2012 at 1:04 PM, Randell Jesup <[email-masked]>wrote:

> You forget that bid-down includes bid-downs by the JS or server (which are
> not trusted in our model), not just by on-path attackers.
>

If your session is initiated by HTTPS, using RTP should not be an option
(the same way as using HTTP from HTTPS is not normally an option). If your
session is HTTP, whole application can be spoofed, so there is no security
to begin with.

I used to work on hardware endpoints that have been using SAVPF since 2004,
> with hundreds of thousands of units in the field.
>

I thought SAVPF was only standardized in 2008 and AVPF was standardized in
2006. AVPF was discussed for a while though, so I would assumed you worked
with something that implemented one of the drafts...
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 May 2012 09:57:42 +0200

On 05/04/2012 07:45 PM, Roman Shpount wrote:
>
> On Fri, May 4, 2012 at 1:04 PM, Randell Jesup <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     You forget that bid-down includes bid-downs by the JS or server
>     (which are not trusted in our model), not just by on-path attackers.
>
>
> If your session is initiated by HTTPS, using RTP should not be an 
> option (the same way as using HTTP from HTTPS is not normally an 
> option). If your session is HTTP, whole application can be spoofed, so 
> there is no security to begin with.
>
>     I used to work on hardware endpoints that have been using SAVPF
>     since 2004, with hundreds of thousands of units in the field.
>
>
> I thought SAVPF was only standardized in 2008 and AVPF was 
> standardized in 2006. AVPF was discussed for a while though, so I 
> would assumed you worked with something that implemented one of the 
> drafts...
The -00 version of the SAVPF draft is dated 19 October 2003.

According to 
https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/ 
publication was requested in February 2006, and it was approved by the 
IESG in November 2007. The publication delay was 3 months.

The technical changes that resulted from these 4 years of work can be 
seen here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt 
<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt>

                         Harald

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 May 2012 09:34:03 -0400

On Tue, May 8, 2012 at 3:57 AM, Harald Alvestrand <[email-masked]>wrote:

> **
> https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/publication was requested in February 2006, and it was approved by the IESG
> in November 2007. The publication delay was 3 months.
>
> The technical changes that resulted from these 4 years of work can be seen
> here:
>
>

I would say that something that changes to rfc4585 would be more relevant.
Regardless of the actual changes in the draft, my point is there are very
few actual SIP devices that implement SAVPF or AVPF. Specifying this as the
only profile supported by WebRTC will create yet another challenge to
legacy interop, since it will require not only processing of ICE messages,
and DTLS-SRTP re-encoding, but also RTCP re-generation.
_____________
Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 May 2012 15:49:30 +0200

On 2012-05-08 15:34, Roman Shpount wrote:

> I would say that something that changes to rfc4585 would be more
> relevant. Regardless of the actual changes in the draft, my point is
> there are very few actual SIP devices that implement SAVPF or AVPF.
> Specifying this as the only profile supported by WebRTC will create yet
> another challenge to legacy interop, since it will require not only
> processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP
> re-generation.

Hi,

Here I have to protest that it increases the barrier. First of all the S
in SAVPF is for using SRTP. That is already agreed on in this WG.
Secondly the F stands for the feedback part. That consists of two parts:

1) New Timer Rules

2) Feedback RTCP packets

The second is actually negotiated on a per individual feedback format
basis. So only the first is what really what would be mandated by a
WebRTC requirement of SAVPF. From my perspective to get the RTP/RTCP
functionalities needed to give a good user experience we really need the
timing rules. When it comes to legacy interop a signalling gateway can
actually produce a SAVPF configuration that is fully interopable with an
SAVP end-point.

The configuration required to make this interoperable are: use a=rtcp-fb
to sett trr-int to 3.5 to 4 seconds and ensure that the same or at least
sufficient RTCP bandwidth is configured and that no feedback format are
agreed on being used.

So please don't be afraid of SAVPF.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Tue, 08 May 2012 13:52:47 -0400

On 5/8/2012 9:34 AM, Roman Shpount wrote:
>
> On Tue, May 8, 2012 at 3:57 AM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     __
>>     would assumed you worked with something that implemented one of
>>     the drafts...
>     publication was requested in February 2006, and it was approved by
>     the IESG in November 2007. The publication delay was 3 months.
>
>     The technical changes that resulted from these 4 years of work can
>     be seen here:
>

Perhaps, though maybe it's more common in video (SIP INFO for IDR 
requests "sucks dead gerbils through garden hoses" - old Amiga slang 
phrase).

> processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP

AVPF has the advantage of being backward-compatible with AVP in almost 
all cases.  We used SAVPF internally, but typically hid that from the 
outside world by advertising AVP (this was long before SDP cap-neg was 
finalized).  (Has anyone truly implemented it?  In open source?)  IIRC 
this is even spoken to in the spec.  (We used AVP/AVPF instead of 
SAVP/SAVPF because we used the non-standardized "best effort encryption" 
draft I worked on with Hadriel, as an alternative/stopgap until cap-neg 
"worked".)

-- 
Randell Jesup
[email-masked]