Re: [rtcweb] Final plea about SRTP

Roman Shpount <> Thu, 03 May 2012 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C8B921F85D2 for <>; Thu, 3 May 2012 08:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.855
X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2MCaFf4Av3Is for <>; Thu, 3 May 2012 08:48:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E91821F84D6 for <>; Thu, 3 May 2012 08:48:36 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2707458pbc.31 for <>; Thu, 03 May 2012 08:48:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=famJemptVuv6NjxawevOHK+impGUHMaVpwgPuz1nAuA=; b=UCaNiGBjkAehYaYPUeHMNGXy5zUgZwEORIQI0+VnuOZoD/+JhyM/U9vWjLHF8qFRUI RYE8makYvO+/sAlxRvFBUL3VD35m0qedtb4psroDE2LmrgOuQu1zP5cxRJCj2t/fov5R Z5b77V7ORWrJM8HnEvWId5YK5b7ge0R2rZstcU4FpMisiXvc9TsUnDQCfzY4Noeb4taR boL2L8Xln7jLZum97JNhauX3X7OU7qm4swowZZtzylULSWw/o8M9EkdgrcAC0/E6zLL4 THyqQUgRITvT1AVesrQpF1XiqfkKoggdISvKt5ncxeU/P5yIIbo83+gqbvu9OFlsS9Fw dHHQ==
Received: by with SMTP id hz3mr9281372pbc.23.1336060116182; Thu, 03 May 2012 08:48:36 -0700 (PDT)
Received: from ( []) by with ESMTPS id g4sm5639738pbt.58.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 08:48:34 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2707406pbc.31 for <>; Thu, 03 May 2012 08:48:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id qz4mr661197pbc.69.1336060114015; Thu, 03 May 2012 08:48:34 -0700 (PDT)
Received: by with HTTP; Thu, 3 May 2012 08:48:33 -0700 (PDT)
In-Reply-To: <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl>
References: <> <> <> <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl>
Date: Thu, 03 May 2012 11:48:33 -0400
Message-ID: <>
From: Roman Shpount <>
To: Bernard Aboba <>
Content-Type: multipart/alternative; boundary="047d7b1605c97e96fb04bf23bcf9"
X-Gm-Message-State: ALoCoQnl87/RI2QcdrhDvfTvgaEdp8zYQXTEiBODSYHq4DS4zWYL5WFGQN/31Ym8NLXiDmBrgk50
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: Thu, 03 May 2012 15:48:37 -0000

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