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

Bernard Aboba <> Thu, 13 June 2013 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AE5321F9AD3 for <>; Thu, 13 Jun 2013 12:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ogCKL8IUreSZ for <>; Thu, 13 Jun 2013 12:47:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DEA1D21F9ACB for <>; Thu, 13 Jun 2013 12:47:43 -0700 (PDT)
Received: from BLU169-W85 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jun 2013 12:47:43 -0700
X-TMN: [u3YstHEvH1U7PYwx00rLBPoohP2E1BE4]
X-Originating-Email: []
Message-ID: <BLU169-W85165ED7250E6035128B0693870@phx.gbl>
Content-Type: multipart/alternative; boundary="_084b0e56-8720-4161-9d87-7ab282dd5e53_"
From: Bernard Aboba <>
To: Harald Alvestrand <>, "" <>
Date: Thu, 13 Jun 2013 12:47:42 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>, <>, <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Jun 2013 19:47:43.0576 (UTC) FILETIME=[DEE7FD80:01CE686E]
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 19:47:49 -0000

Harald said: 

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

[BA] There are only a limited number of situations where it is possible to "disclaim the ability to look at the bits".  For example, a PSTN gateway, PBX connecting to a SIP trunk, a video compositor or an audio mixer need to access decrypted RTP packets in order to do their job.  What non-P2P scenarios are you imagining where that would be possible? 
> 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.
[BA] I believe it is correct to say that the CPU cost of SRTP encrypt/decrypt  is not the bottleneck in large membership conferences (a good MCU implementation running on a high-end multicore server is likely to saturate a 1 Gbps NIC before CPU utilization becomes a factor).  Given that, I don't see that EKT will actually have that much impact, compared with other decisions about the key exchange -  whether PFS is required, key establishment algorithms and key sizes, etc.  For example, see: