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

domenico.colella@ctiplanet.it Mon, 23 July 2012 07:15 UTC

Return-Path: <domenico.colella@ctiplanet.it>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8844311E8080 for <rtcweb@ietfa.amsl.com>; Mon, 23 Jul 2012 00:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.418
X-Spam-Level:
X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_72=0.6, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy2wItTRnv3D for <rtcweb@ietfa.amsl.com>; Mon, 23 Jul 2012 00:15:48 -0700 (PDT)
Received: from hostingsmtp.register.it (hostingsmtp04.register.it [81.88.50.245]) by ietfa.amsl.com (Postfix) with ESMTP id D8C3A21F8532 for <rtcweb@ietf.org>; Mon, 23 Jul 2012 00:15:46 -0700 (PDT)
Received: (qmail 3574 invoked from network); 23 Jul 2012 07:15:44 -0000
Received: from unknown (HELO localhost) by hostingsmtp.register.it with ESMTP; 23 Jul 2012 07:15:44 -0000
MIME-Version: 1.0
X-Mailer: AtMail PHP 5.1
Message-ID: <1278.1343027744@ctiplanet.it>
X-RID: dDsndCNuJSjsO3RjQCUoKCMoK2MnK2M7biNtK2Q=|dDsndCNuJSjsO3Rj|+eBeJ+Bd4CcsXeAnPT3g|T1JQTElBTUJFVw==
To: <rtcweb@ietf.org>
Content-Type: text/plain; charset="utf-8"
X-Origin: 188.135.131.216
Date: Mon, 23 Jul 2012 09:15:44 +0200
From: domenico.colella@ctiplanet.it
Content-Transfer-Encoding: quoted-printable
Cc: daniele.filippi@ctiplanet.it
Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: domenico.colella@ctiplanet.it
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 07:15:49 -0000

Help! I'm getting confused: last JSEP draft (http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-01#section-5.2) states a list of SDP 
parameter that can be controlled by "signaling" application. Among the others, the following attribute dealing with security are 
present:
- remove or reorder SRTP crypto-suites (a=crypto)
- change SRTP parameters or keys (a=crypto)

What does it mean ?
SDES MUST be supported if the "signaling" application deals with it and through JSEP API sets appropriate keys ? 
SDES MAY be supported as an "out of the box" security feature (i.e. "signaling" application does not care about RTP security and just 
proxies SDP)?
Thanks,
Domenico

On Fri 20/07/12 00:20 , 'Dan Wing'  sent:
> > -----Original Message-----
> > From: Roman Shpount [roman@telur
> ix.com]> Sent: Thursday, July 19, 2012 1:19 PM
> > To: Dan Wing
> > Cc: Domenico Colella; rtcweb@ietf.o
> rg; 
> daniele.filippi@ctiplanet.it> Subject: Re: [rtcweb] Security Architecture: SDES
> support is a MUST> 
> > 
> > On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing dwing@cisco.c
> om> 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
> > 	http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pd
> f> 	http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt> 
> > 
> > 
> > 
> > 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),
> thoseSRTP packets would need to be rekeyed.  This is depicted in slide
> 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pd
> fwhere 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
> above.
> 
> 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,
> 
> https://www.sipit.net/SIPit29_summary, and 80%
> that had SRTP supportused 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.
> 
> -d
> 
> 
> 
> 
>