Re: [rtcweb] Consensus call regarding media security

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC30921E8204 for <>; Thu, 29 Mar 2012 08:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.623
X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, 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 dB2PSjwH31Ln for <>; Thu, 29 Mar 2012 08:21:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DD80C21E8202 for <>; Thu, 29 Mar 2012 08:21:24 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1796171vbb.31 for <>; Thu, 29 Mar 2012 08:21:24 -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=zHalwkO9kXfw4XG85Zw/BtreUgvhhKF+bFkaegIJ5FI=; b=hqMIeV4/iHIzqbMJ/dyMlcOMpfjSYERetawsdOq6RQbEUQgM4iErBUpak1AIb3ujeF yflVEpwq0g6R1t4795Uqq3qNCs4lciIobLE3eYBuvBoLNsN9x+xywty8SBkEhMa+SVv0 uLrM/1e7HGIlzdY/q/RIMepooM37NMY4CssuM2dXu2wGlzwSWe3CltciMPA70RxmjEfV PWyc7cufWEhwyNrAZcIQij5WNRVA60h10Rjxu7eFJikzdOmRasGUsjG3WwjR4SvqfHsi PJ2/L2c/73ryU4JJaKBrPuwUnhuDQcwusyoRN+Mqgrh8wwMlQEWAZ8C5G5DMxEjMzk4J GELg==
Received: by with SMTP id a9mr2817157vdd.34.1333034484415; Thu, 29 Mar 2012 08:21:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 29 Mar 2012 08:21:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Thu, 29 Mar 2012 17:21:04 +0200
Message-ID: <>
To: Roman Shpount <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlNv7JO0z4CnYouxMg4uNETIvDuMvMRmFHEyHqqudB//hp2DccanNyI/jgC6ZLRKo3FUCyn
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:21:25 -0000

2012/3/29 Roman Shpount <>:
> 1. SRTP-DTLS is required to be supported and is offered by default with no
> option to bid down to anything else.
> 2. From HTTPS session SDES SRTP can be enabled via an API method
> 3. From HTTP session RTP can be enabled via an API method
> I only want to allow RTP from HTTP initiated session, since I see no benefit
> of supporting SDES SRTP there. I only want to allow SDES SRTP from HTTPS
> initiated sessions, since SDES SRTP provides no security benefits when
> session description is transmitted over clear channel.
> With my proposal, if an application provider does not care about security,
> they will use HTTP/RTP. If they care about security, they will use
> HTTPS/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so.
> Also, this way we do not provide false sense of security if someone decides
> to start SDES-SRTP session from HTTP.
> Is someone can explain to me how this is less secure, even in the airport
> wifi comparing to SDES-RTP from HTTP session, please do so.

You miss something:

1) I access some web using HTTPS with a valid certificate and so.

2) Some HTML and JavaScript is got.

3) The JS code opens a *non* secure WebSocket connection to some other
server (same domain or not, it does not matter here).

4) WebRTC signaling goes through the WebSocket connection (so forget
the initial HTTPS hyper-secure-and-verified connection).

5) SDES-SRTP is negotiated and accepted by both peers.

6) So signaling can be intercepted (unsecure WebSocket connection),
and therefore also the SDES keys. Interception possible regardless the
initial communication was HTTPS.

7) FAIL.

Iñaki Baz Castillo