Re: [rtcweb] Consensus call regarding media security

Iñaki Baz Castillo <> Thu, 29 March 2012 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B9C921F882E for <>; Thu, 29 Mar 2012 08:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, 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 gITk5r9xr0-p for <>; Thu, 29 Mar 2012 08:43:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5BBC921F875C for <>; Thu, 29 Mar 2012 08:43:11 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1853591vcb.31 for <>; Thu, 29 Mar 2012 08:43:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=UTUNl2UMTpjlJOuxf4wPZJs6+ebtWt4Mhg0yXRly9iI=; b=fgpWtlar3O71aMfHVCyF+qa7UPTsu0VYyZiHbdQO87heHMJfTOHcM5m0HxDFyeUtvk MkEwJ64te///a9+CesPA785ZbuP+kPaIM5NU9VdYRJKgJ6zTazAd4Yl3eakfcCQ1ZpSi hVPXCSzY4PDUOfJFjQLAczeT75Zxh65GnY+nuaqseqIZlDd50ZfxM/kdINKGXH/F8cCR UPpRpjtI142i26ghfOw2ALMYBZ++gFsnZj3Hg1tKdXbzQ4hahwP10nxlBRVE78I4U3d4 b+Nrb4QUvQjRbckvGUNQ/aGS3Dy1hbWSVISGHAcX0Enusz/v1XND99v196vZdBozoJXN HvHg==
Received: by with SMTP id z7mr6018606vcw.2.1333035790724; Thu, 29 Mar 2012 08:43:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 29 Mar 2012 08:42:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Thu, 29 Mar 2012 17:42:49 +0200
Message-ID: <>
To: Roman Shpount <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkEBk6Wc2vre1X1XcI9bGBtiAMHXDiCmentveWz+ouNQx0SJJv02E6yM0Jnm/o4XjOui5Bt
Cc: "" <>
Subject: Re: [rtcweb] Consensus call regarding media security
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, 29 Mar 2012 15:43:28 -0000

2012/3/29 Roman Shpount <>:
> First of  all, HTTP WebSocket connection are normally not allowed from HTTPS
> initiated sessions (or generate a warning).

Ok, I didn't check that.

> Second, my point was that SDES-SRTP is no more secure then plain RTP when
> signaling is transmitted over clear channel. You are saying the same thing.


> If SDES-SRTP is allowed, there is no harm in allowing plain RTP from HTTP,
> since, as far as security is concerned, there is no difference.

The only I meant is that the signaling must be secured. Otherwise,
using SDES-SRTP adds no security at all. But the signaling could be a
different connection (i.e. WebSocket) different from the HTTP(s)
connection used to retrieve the web.

Let's assume this example:

- The browser access the web via plain HTTP.

- The JS opens two websocket connections:
  1) First one for the WebRTC signaling, a secure WS connection.
  2) Second one for other realtime stuff, a NON secure WS connection.

If the SDES key is carried over the first WS connection (wss) then
it's ok, it provides confidenciality. But if the SDES key is carried
over the second WS connection (ws, so unsecure) then it's
interceptable and therefore also the SRTP.

Question: can the WebRTC stack figure which WS connection is being
used for WebRTC signaling?
Autoanswer: NO, since the signaling protocol is up to the app developer.

So Houston we have a problem if we try to make requirements in which
SDES-SRTP can be used. I'm in favour of mandating SDES-SRTP in WebRTC,
but we need to solve this issue, and it is not easy (AFAIK).


Iñaki Baz Castillo