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

Harald Alvestrand <> Thu, 13 June 2013 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0009421F9385 for <>; Thu, 13 Jun 2013 05:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S4v+3htn6bmT for <>; Thu, 13 Jun 2013 05:59:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 03F8421F940D for <>; Thu, 13 Jun 2013 05:59:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE4E039E172 for <>; Thu, 13 Jun 2013 14:59:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eWq8xihu-P0j for <>; Thu, 13 Jun 2013 14:59:49 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPSA id E472E39E058 for <>; Thu, 13 Jun 2013 14:59:48 +0200 (CEST)
Message-ID: <>
Date: Thu, 13 Jun 2013 14:59:48 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Thu, 13 Jun 2013 12:59:58 -0000

On 06/13/2013 01:07 PM, Tim Panton wrote:
> I fear it just _looks_like_ the primary interop issue.
> As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without
> the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)
> Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES.
> The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay.
> I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway.
> Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.

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

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.

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".

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