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

Hadriel Kaplan <> Fri, 14 June 2013 03:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C930521F8F6E for <>; Thu, 13 Jun 2013 20:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.567
X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ll9y6Me35Yb for <>; Thu, 13 Jun 2013 20:39:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 439ED21F9133 for <>; Thu, 13 Jun 2013 20:39:47 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5E3dgrc006626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jun 2013 03:39:42 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5E3de3Q014805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 03:39:41 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5E3deJ5024952; Fri, 14 Jun 2013 03:39:40 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Jun 2013 20:39:40 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <>
In-Reply-To: <>
Date: Thu, 13 Jun 2013 23:39:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: []
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, 14 Jun 2013 03:39:53 -0000

On Jun 13, 2013, at 8:59 AM, Harald Alvestrand <> wrote:

> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.

My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig".  In fact if I recall correctly it was you who said something along those lines in Paris. :)

> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.


> My impression from the performance numbers people have quoted is that the CPU cost of decrypt/encrypt doesn't cost enough to be the deal-breaker between "viable solution" and "not viable solution"; other things weigh far more on capex/opex.

Yes, I also think that's true, that the cost/complexity overhead of decrypt/encrypt wouldn't break the viability.  It does cost more to do it, though, so if we can get away without having to do it (without truly sacrificing security) then it would be a good thing.  Things add up after all, both in processing cost and time.

But yes clearly it isn't as big a deal as having to transcode video, for example, which would not be viable.

> The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits".

I hadn't heard that one.  I'm not really sure how one could prove that anyway though, since SDES would certainly give the gateway the *ability* to look at the bits.  You would have to either check the code or believe the logs, and if you're willing to believe them then you might as well believe the code/logs that the gateway isn't storing/sampling the bits when it decrypts/encrypts.

> Agree with Tim about the relative difficulty of adding the needed features.

Afaict, adding SDES is trivial if you went to the trouble of doing DTLS-SRTP already.  The converse isn't true.