Re: [AVT] draft-mcgrew-dtls-srtp-00

[Lakshminath Dondeti <[e-mail]>]

I have been meaning to review this draft for a while now and finally 
completed reading it just a little while ago.  I must also preface 
the review to say that this is more on the opinionated end of the 
spectrum; this area has attracted a wide range of ideas for key 
management, some I like and some I don't care for all that much!

Review of draft-mcgrew-tls-srtp-00
Datagram Transport Layer Security (DTLS) Extension to Establish Keys 
for Secure Real-time Transport Protocol

My understanding of the evolution of this work is that the number of 
changes one needs to make to DTLS for SRTP equivalency on the wire is 
unattractive, and of course the changes themselves are not really 
elegant (that's a separate discussion, however).  One way to fix that 
might be (again looking from the world view of TLS/DTLS) to reuse 
SRTP and use the tried and tested TLS(DTLS) protocol for key 
management.  That sounds nice, but there are any number of problems with that.

1. DTLS-SRTP supports point-to-point media sessions, with exactly two 
participants: This is in itself is not the end of the world, but it's 
a limitation nonetheless (SRTP-EKT might be used to compensate this 
problem, but again more on that in a different discussion).
2. Multiple media sessions each require a DTLS-SRTP session: there is 
an optimization where multiple sessions might run in sequence and 
take advantage of TLS/DTLS session re-start, but I consider this a 
serious limitation.  DTLS would have more latency in establishing 
keys for a single session, compared to say, SDES and MIKEY and the 
multiple sessions case makes the problem worse.  It doesn't look like 
there's a way to get around this problem.
3. Minor changes required to introduce an extension to DTLS for SRTP: 
not a problem.
4. TLS KDF instead of SRTP master key derivation is used: I don't 
like it.  I'd have liked to reuse all of SRTP as much as possible, 
especially if SRTP is implemented for other purposes in 
hardware/firmware/toolkit.  The keys also come from the end of the 
DTLS key block.  I need to think more about that some time.  Any 
opinions of whether that's an issue?
5. Client-server terminology: I am not thrilled to see the client 
server terminology for point-to-point media sessions, but that's 
baggage from the DTLS world.
6. Transmission and reception: The DTLS handshake is used for keying 
SRTP as well as the record layer, so there are demultiplexing 
semantics.  As explained they seem ok and might work without a hitch, 
but again I must conclude that this has a retrofitting feel to it.

Conclusion: If the "final" consensus were to use in-band (or bearer 
path) keying for SRTP, in my view, DTLS-SRTP is not the way forward.

I am still open minded about all this, but it would take a lot to 
convince me to change that personal opinion.

regards,
Lakshminath

PS:  I'd also like to see the response to Fleming's questions in his 
review. Thanks.

At 10:36 AM 3/21/2006, Eric Rescorla wrote:
>Folks,
>
>Here's a pointer to the draft by David McGrew and myself that Jason
>Fischl mentioned in today's AVT meeting. It uses DTLS for key
>establishment and algorithm/parameter negotiation and SRTP for carrying
>the media.
>
>http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.html
>http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.txt
>
>-Ekr
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt