Re: [rtcweb] Final plea about SRTP

Magnus Westerlund <> Fri, 04 May 2012 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1491021F85DF for <>; Thu, 3 May 2012 23:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.141
X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zp4pOjEW1-Bo for <>; Thu, 3 May 2012 23:21:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6126821F85DD for <>; Thu, 3 May 2012 23:21:09 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-37-4fa37553752d
Authentication-Results: x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA)
Received: from (Unknown_Domain []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by (Symantec Mail Security) with SMTP id 97.9B.25560.35573AF4; Fri, 4 May 2012 08:21:07 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 4 May 2012 08:21:07 +0200
Message-ID: <>
Date: Fri, 04 May 2012 08:21:01 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Roman Shpount <>
References: <> <> <> <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] Final plea about SRTP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 May 2012 06:21:11 -0000

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



On 2012-05-03 17:48, Roman Shpount wrote:
> On Wed, May 2, 2012 at 8:41 PM, Bernard Aboba <
> <>> 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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: