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

From: [email-masked]
Date: Mon, 23 Jul 2012 09:15:44 +0200

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; [email-masked]
> rg; 
> [email-masked]> Subject: Re: [rtcweb] Security Architecture: SDES
> support is a MUST> 
> > 
> > On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing [email-masked]
> 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
> 
> 
> 
> 
>