Re: [rtcweb] Final plea about SRTP

jesse <> Thu, 03 May 2012 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FB6921F8532 for <>; Thu, 3 May 2012 09:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.423
X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XjK9k60uKrXB for <>; Thu, 3 May 2012 09:36:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB38821F84C3 for <>; Thu, 3 May 2012 09:36:24 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so1550256qcs.31 for <>; Thu, 03 May 2012 09:36:24 -0700 (PDT)
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; bh=/SUOVV/WIEGUJxk8ABEo2vWheUMU4wUojfs8vo5NJyU=; b=X7TaqVEAfYHMn0i5tK7mo8Amks3qYNJkzjVreFWMVYImr+rKjmXGrSMI2pdHS9O1HI U9NVBvm6JhruXujV0M88DFCSpe5ZhjmwT4zCB+f4h5n1k+t1qsWinA4AShX5vGVlqMNO cXEv3EXIHvYmDld7VntbHIckb1p/SuO9ZKlUFogAIBoKX5BcKv2SV/Ewz0hyRNP6gX9c nkjvIKqgnwpaqsTt1ZyKpT6qbLIaT8Db6b3wE2UWdmQEzCy21F3OJUkheS9Ypaownr3y Rsl4/tlpSqMJA+amZry5RHdMeAy0pI+KJHr24PcTwbWKNZy1X/qb11harlPiMxyjg9au 3q0Q==
MIME-Version: 1.0
Received: by with SMTP id a7mr3758980oeh.24.1336062984208; Thu, 03 May 2012 09:36:24 -0700 (PDT)
Received: by with HTTP; Thu, 3 May 2012 09:36:24 -0700 (PDT)
Received: by with HTTP; Thu, 3 May 2012 09:36:24 -0700 (PDT)
In-Reply-To: <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl>
References: <> <> <> <BLU169-DS251D322307BC173FD221AE932F0@phx.gbl>
Date: Thu, 03 May 2012 09:36:24 -0700
Message-ID: <>
From: jesse <>
To: Bernard Aboba <>
Content-Type: multipart/alternative; boundary="e89a8ff1cafa92412404bf2467d5"
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 16:36:26 -0000

On May 2, 2012 5:41 PM, "Bernard Aboba" <> wrote:
> 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
> 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

> 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
> 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.
> On Wed, May 2, 2012 at 5:32 PM, Cullen Jennings <> 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
> 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
> > _____________
> > Roman Shpount
> > _______________________________________________
> > rtcweb mailing list
> >
> >
> _______________________________________________
> rtcweb mailing list