Re: [rtcweb] Security Architecture: SDES support is a MUST

"Dan Wing" <> Thu, 19 July 2012 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0F5921F86C6 for <>; Thu, 19 Jul 2012 15:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.494
X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T2c7m+9GDEtj for <>; Thu, 19 Jul 2012 15:19:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6EF8A21F86BA for <>; Thu, 19 Jul 2012 15:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3367; q=dns/txt; s=iport; t=1342736453; x=1343946053; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Q47Br357Gs+yPx+eOy7JjatAlURoTZNVs1pTOevaGdw=; b=HJGzawC+J0WAUCAZFAYPqzunKcARCsCux9hE9v+rWPWfAadtVr2vlyew kXacbFX1GELKK0GzHnahU7CmJXxeaQKEBzJCQQOkzkBtpWB/zJ1LbpM+t 7zEM2CgkdjDSTXg8NeGPends10ytNHxVThWOdqSJIBZYjXxo1nGI5j0Dx k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.77,617,1336348800"; d="scan'208";a="49335821"
Received: from ([]) by with ESMTP; 19 Jul 2012 22:20:53 +0000
Received: from dwingWS ( []) by (8.14.5/8.14.5) with ESMTP id q6JMKqFH010045; Thu, 19 Jul 2012 22:20:53 GMT
From: "Dan Wing" <>
To: "'Roman Shpount'" <>
References: <> <075201cd65d8$db37a210$91a6e630$@com> <>
In-Reply-To: <>
Date: Thu, 19 Jul 2012 15:20:52 -0700
Message-ID: <081e01cd65fc$c29e2340$47da69c0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1l65OAzIr202rMRWa25tknkIfWxgABzJ4A
Content-Language: en-us
Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST
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, 19 Jul 2012 22:20:01 -0000

> -----Original Message-----
> From: Roman Shpount []
> Sent: Thursday, July 19, 2012 1:19 PM
> To: Dan Wing
> Cc: Domenico Colella;;
> Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST
> On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing <> wrote:
> 	As I explained at IETF83 in Paris at the RTCWEB, interworking
> 	between DTLS-SRTP keying and SDESC keying can be done without
> 	expensive CPU operations.  Reference
> Even though I understand how you can bridge DTLS-SRTP with SRTP-EKV
> without re-encryption, I do not think it is possible to bridge SDES-
> SRTP with DTLS-SRTP the same way.

Short answer:  you are right, the WEBRTC network needs DTLS-SRTP 
and EKT.

Without EKT, it is possible to interwork in one direction without re-keying 
each SRTP packet, specifically the packets going from the DTLS-SRTP
network to the SDESC network can be forwarded without re-keying.  However,
in the the other direction (from SDESC network to DTLS-SRTP network), those
SRTP packets would need to be rekeyed.  This is depicted in slide
28 of
where the media gateway is on fire (it is doing lots of CPU processing
to rekey those SRTP packets in the 'red' direction).

To avoid that rekeying in that direction, we add EKT on the DTLS-SRTP
network.  With EKT, there is no longer a need to rekey SRTP in either
direction.  This is depicted in slide 33 of the same presentation as

EKT has other advantages for group video conferencing, which allow
video switching devices to avoid re-keying -- which reduces costs
(and saves energy, everybody is about saving energy!).  It was those
advantages which led to the design of EKT in 2006 as 
draft-mcgrew-srtp-ekt-00, and the implementation in Cisco's 
telepresence systems.

> Bridging DTLS-SRTP with SRTP-EKV is
> completely useless for legacy interop since old equipment is more
> likely to support DTLS-SRTP then EKV, which is not even standardized
> yet.

The majority of legacy systems seem to use SDESC keying, not 
DTLS-SRTP keying.  And we don't need to change those legacy systems 
for this interworking.

There were no DTLS-SRTP implementations brought to SIPit 29,, and 80% that had SRTP support
used SDESC keying.  Assuming that SIPit is a more-or-less accurate 
representation of the market, the 'legacy' market uses SDESC keying
if it supports SRTP at all.

Of course, there is also a lot of 'legacy' equipment only supports
RTP.  That is yet another reason for an interworking gateway in 
front of that RTP-only equipment.

> This being said, I am strongly against supporting SDES-SRTP. Re-
> encoding is cheap and you can do nearly 10GB/s of AES encoding on a
> fairly modest modern server. Having more protocols to test and support
> is a much higher cost.

Some objected to that cost, and after Magnus and Jonathan Lennox
suggested EKT be changed slightly to allow each packet to be self-
describing, we now have a very efficient way to interwork the
SRTP packets.