Re: [rtcweb] Let's define the purpose of WebRTC

Iñaki Baz Castillo <> Wed, 09 November 2011 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5525121F8B64 for <>; Wed, 9 Nov 2011 07:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HJhDD5iKR0ZJ for <>; Wed, 9 Nov 2011 07:05:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A6C5C21F8B63 for <>; Wed, 9 Nov 2011 07:05:33 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so1675274vcb.31 for <>; Wed, 09 Nov 2011 07:05:33 -0800 (PST)
Received: by with SMTP id fq4mr5235239vdc.32.1320851133157; Wed, 09 Nov 2011 07:05:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 9 Nov 2011 07:05:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Wed, 9 Nov 2011 16:05:12 +0100
Message-ID: <>
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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, 09 Nov 2011 15:05:34 -0000

2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <>om>:
> |And what is the advantage? you still say exactly the
> |same: a WebRTC client "MUST" allow plain RTP if the
> |peer is not a WebRTC client. Why is that an argument
> |in favour of non mandating SRTP?
> We seem to have a group of people concerned about the cost associated with having to upgrade/replace/supplement their non-SRTP capable gears such as PSTN gateways, and I was sympathetic towards them -:)

That's *your* problem. But you want to translate *your* problem into
WebRTC users by making their communications non secure.

Implementing SRTP is really easier and cheap. There is no reason at
all not to mandate it in a new specification, even less when it's
designed to work in the open (and untrusted) Internet.

So bad luck. You, telcos, have the specs and the tools to upgrade your
non-secure SIP devices. Do it.

> |If I'm in a shared WiFi network and receive a call from
> |a non-WebRTC client not supporting SRTP, my neighbors can
> |intercept it.
> If the shared WiFi network hasn't employed WiFi encryption, then you would probably be more concerned with your neighbors intercepting all of your traffic than just RTP -:)

It was just an example. Think about so many open WiFi networks in
airports (captive portals with no encryption).

> |What does such "STUN extension" provides here?
> It would tell the browser that the peer (browser) claims WebRTC compliance and so shouldn't allow insecure calling (the STUN extension is added by the browser and the applications has no control over it).

I insist: that provides nothing. It just means that me, a WebRTC user,
could have a non-secure media session in case the remote peer is not a
WebRTC peer (or a peer implementing SRTP). It solves nothing. It makes
my communication unsafe regardless I'm a WebRTC client implementing
SRTP. *My* security should NOT depend on the security implemented in
the peer (since I cannot trust the peer, never).

Iñaki Baz Castillo