Re: [rtcweb] Final plea about SRTP

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> 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
>     mandatory to implement and use, especially if SDES is available, so
>     the 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
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------