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

Hi Lakshminath,

thanks for your comments, more inline:

On Apr 4, 2006, at 12:20 AM, Lakshminath Dondeti wrote:

> 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

Right, but the limitation applies to all of the point-to-point keying  
methods, including MIKEY-DH, SDP-DH, and ZRTP.  The point-to-point  
case is probably important enough that it deserves to be addressed by  
a mechanism that targets its particular needs.  This consideration is  
underscored by the number of proposed methods that address this case.

> (SRTP-EKT might be used to compensate this problem, but again more  
> on that in a different discussion).

This is an interesting idea, and it certainly deserves some more  
consideration.  It could handle the SIP parallel forking case very  
cleanly, and it would probably work well for small groups of  
participants.  Of course, it would be important to make sure that we  
don't add too much complexity by adding a tie-in to EKT, but I think  
it would be manageable since EKT has a fairly simple interface.   
Let's look into this some more.

> 2. Multiple media sessions each require a DTLS-SRTP session:

Right; this property is fundamental to in-band keying.

> there is an optimization where multiple sessions might run in  
> sequence and take advantage of TLS/DTLS session re-start,

Right, this optimization makes the true critical path for the  
establishment of all of the sessions equal to the critical path for  
establishing a single session plus a single round trip (since the  
data can be sent immediately following the client's "Finished"  
message in TLS session resumption).  But it doesn't decrease the  
number of messages on the wire.

One nice property of the optimization is that it doesn't require any  
change to DTLS at all; it essentially consists of causing one session  
establishment to wait until another is done.

> but I consider this a serious limitation.

Yeah, the chattiness is probably the least desirable aspect of DTLS- 
SRTP.

> DTLS would have more latency in establishing keys for a single  
> session, compared to say, SDES and MIKEY

Right, DTLS would take two round trips instead of one.  But one of  
the motivations for in-band keying is the fact that a round trip in  
the media plane has considerably lower latency than a round trip in  
the signaling plane, because signaling messages are forwarded at the  
application layer and may be processed at several points during their  
trip.  I cannot cite any data to back this up, but informally I've  
been told that in several cases a full two-round trip TLS handshake  
can take place before a single offer/answer exchange can complete.   
(This difference in RTT is behind the idea of using media-plane  
keying whenever the media might arrive before the the answer in the O/ 
A exchange - otherwise, it would be pointless :-)

> and the multiple sessions case makes the problem worse.  It doesn't  
> look like there's a way to get around this problem.

Well, there are some ways that the extra round trips could be  
avoided.  One method would be to use one message exchange to  
establish an EKT key, then use EKT to convey the SRTP master key for  
all of the other media sessions.  This would require that we  
introduce a way in SDP to say that one media line should get its EKT  
KEK from the handshake done in another media line, but this is  
probably as simple as adding something like "I'm keyed by stream  
#NNN".  This method works because it's perfectly legal to use a  
single EKT KEK across multiple SRTP sessions.

Yet another approach would be to introduce a way to derive SRTP  
master keys for one session from the key material derived by another  
session.  This method would reduce the cumulative latency and would  
reduce the number of messages on the wire, but it might be less  
robust.  I'd prefer using EKT if it were available.

> 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.

This is a good point.  Skipping the SRTP KDF has a bigger impact on  
SRTP implementations than I'd originally thought, and it might make  
implementation re-use more difficult.  Ideally, DTLS-SRTP should be  
able to work with any RFC3711 conformant implementation.

> 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?

I don't see any issues, and if there are any, they should be easy to  
fix.  As with all cases in which key material is handled, it is  
important that we make sure that there is never re-use or ambiguity  
about the intended use of the keys.  But the DTLS-SRTP method is  
using the TLS KDF in a manner consistent with its intended use.  (It  
just takes some additional output from a PRF, and treats it as though  
it were random.)

> 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.

We should rewrite whatever part is not clear.  I'd prefer to keep the  
client/server terms in the DTLS context, because they are clear and  
precise, but then include definitions of which RTP participant is the  
server and which is the client, and a couple of sentences mapping the  
terms appropriately.  Do you think that would clear things up?

> 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.

RTP implementations will need to demultiplex ICE packets from RTP  
packets, so architecturally speaking, the requirement to demux DTLS  
packets just introduces a new packet type, not a new process.

>
> 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.

For inband keying, DTLS-keyed-SRTP has the advantage that it can re- 
use large parts of the TLS implementation, which is in many cases  
used to protect the telephony signaling.  I expect that this fact  
will appeal to many implementers of SRTP because of the resource- 
constrained environments that they work in.

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

Sure, I'll write up some comments.  We talked with Flemming in Dallas  
and I guess it slipped my mind to send a response to the list.

David

>
> 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
>> avt@ietf.org
>> https://www1.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt