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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Roman Shpount [mailto:[e-mail]]
> Sent: Thursday, July 19, 2012 1:19 PM
> To: Dan Wing
> Cc: Domenico Colella; [e-mail]; [e-mail]
> Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST
> 
> 
> On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing <[e-mail]> 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.pdf
> 	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), those
SRTP packets would need to be rekeyed.  This is depicted in slide
28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
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
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 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.

-d