Re: [rtcweb] Final plea about SRTP

Roman Shpount <> Wed, 02 May 2012 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4A6E11E80B1 for <>; Wed, 2 May 2012 15:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.130, 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 MhrZdVrgKnWM for <>; Wed, 2 May 2012 15:16:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 81FBA11E809B for <>; Wed, 2 May 2012 15:16:18 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so779853wgb.13 for <>; Wed, 02 May 2012 15:16:17 -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=yZQIO+2/9oX4mMlGjNxQHhTbe89rrDdg9b3Bep51vjM=; b=ShND/FcFkAWRdOw2Oeq9WlWkw3qQ4sxbjvO+fMsK3X6+gW4O7Asw86LQyd+p6JHWqw l1r2/cn0Kb5tYPZ/LIAkucPWDNMuY1CtkXx3xLS7QURsRBN3R8vYGPoYDuobsYGsuzhQ PUw39MWmIEmf+GnDl6vYxD7619esRVdX/hODraCzdBdVcwG1o/qJT7ZrAmIzF2WwBDZy VkSZtkzlR7rvTH+m6vaepaERuVOWRSx7cwu1qyZAlpI7K/Iz1WYHml/IbJxHLbbrwp0E 1hKIHNqbSSd7QA+C82XjzLbK2CN9x5OCU8ypiwEhUWZ7vDAiYOAaLtbMaHHGVWxXKta0 9/sQ==
Received: by with SMTP id f6mr18246984wiz.5.1335996977713; Wed, 02 May 2012 15:16:17 -0700 (PDT)
Received: from ( []) by with ESMTPS id l5sm47175170wia.11.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 15:16:16 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1041522bkt.31 for <>; Wed, 02 May 2012 15:16:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id f6mr4017078bkw.7.1335996974665; Wed, 02 May 2012 15:16:14 -0700 (PDT)
Received: by with HTTP; Wed, 2 May 2012 15:16:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 02 May 2012 18:16:14 -0400
Message-ID: <>
From: Roman Shpount <>
To: Cullen Jennings <>
Content-Type: multipart/alternative; boundary="001517592bfc1890f704bf1509ac"
X-Gm-Message-State: ALoCoQmM7omG/d1rE0ovZohrEYzIuvdikkBXiK8YDrU3GzbsfaS8A3vZQKlWLUr6OJkL+W/87Wy+
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: Wed, 02 May 2012 22:16:20 -0000


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 <> 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
> 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
> >
> >