Re: [rtcweb] No Interim on SDES at this juncture

Hadriel Kaplan <> Fri, 21 June 2013 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23D0521E80DC for <>; Thu, 20 Jun 2013 17:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSJj4KjELlaf for <>; Thu, 20 Jun 2013 17:33:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FE2B11E8133 for <>; Thu, 20 Jun 2013 17:33:21 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L0XJi0017967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 00:33:20 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L0XIML004129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 00:33:19 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L0XHco014384; Fri, 21 Jun 2013 00:33:18 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 17:33:17 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <>
In-Reply-To: <>
Date: Thu, 20 Jun 2013 20:33:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Roman Shpount <>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: []
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Fri, 21 Jun 2013 00:33:28 -0000

On Jun 20, 2013, at 4:58 PM, Roman Shpount <> wrote:

> Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicating with a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable from security point of view, then how is SRTP acceptable?

I'm operating under the assumption we would only allow the Browser to use SDES if and only if it is also using HTTPS to the web server.  And I'm operating under the assumption that all browsers still MUST offer DTLS-SRTP, and choose it instead SDES if they receive such an offer.  

In such a model, any two browsers do DTLS-SRTP to each other unless the web-server/JS is malicious.  Ergo, unless the web-server/JS is malicious, only calls to/from a gateway use an SDES key.  The SDES key isn't sniffable on the browser-server HTTPS portion.  Obviously it's sniffable beyond the web server, if it gets sent in the clear somewhere else.  But we know that will also happen even with DTLS-SRTP, because the gateway will terminate DTLS-SRTP and use SDES or plain RTP on the other side.  So we're not losing anything.

So... in theory the danger is relegated to the malicious web-server case.  But a malicious web server can get your media anyway, even with DTLS-SRTP, because it can simply direct you to its own "gateway" to terminate DTLS-SRTP and record the media.  There is no practical way to prevent a malicious web-server from getting your media, no matter what we do, for common every-day users.

Frankly with a malicious web server you're screwed in so many other ways anyway, that making it just slightly harder for it to get your media is like putting on a scuba drysuit when jumping into a pool of molten lava.  Yes, you'll live for some fraction of a millisecond longer.  And then what?