Re: [AVT] Media over DTLS

Eric,

On Mar 18, 2006, at 8:27 AM, Eric Rescorla wrote:

> Lakshminath,
>
> Thanks for your careful review. Sorry it took me so long to get
> back to you. Here's a response to both your messages.
>
>> First, as Mark points out, there has been a bundle of work trying to
>> solve the early media and forking issues.
>
> Right.
>
> It seems to me that early media/forking don't work reliably in 3830 or
> SDESCRIPTIONS as in the RFC-Ed queue, which is why you're seeing work
> aimed fixing those problems.

It's good that you're raising this issue.  If we're to begin some  
focused work on this topic in the RAI, then we need to get some  
agreement on what the problems are.  So this is a start.

I don't see reliability as being the issue at all if we couple SDP  
security descriptions (sdesc) with SDP security preconditions  
(sprecon).  I personally think that sprecon is a very good solution  
for sdesc early media.  Why do you say otherwise?  I know some  
reasonable people who disagree, but it's not related to any  
reliability concern to my knowledge.

> So, I certainly agree that there's been
> work on that problem, but I'm not convinced that it's satisfactorily
> solved.
>
>
>> Second, it is not clear how DTLS or DTLS-SHORT addresses those  
>> issues.
>> Could you please elaborate?  (I have read the motivation section of
>> sipping-media-dtls, but that's not convincing).
>
> So, the basic problem with early media and forking is that there's a
> race condition (in the broad sense) between the completion of SIP
> offer/answer and the start of the media. In DTLS/RTP the key
> establishment happens in the media channel so there's no need to worry
> about round-trips in the signalling channel.

If the race is between a response message sent through the signaling
channel versus an RTP packet through the media channel, then the
outcome is pretty much certain.  Hence all the interest in multiplexing
the media and the signaling.

I see the problem as one of initiating the key establishment from the
caller rather than the callee.  To me, the basic problem is that the
callee can't tell when the caller has received its keying materials
and thus can't send any media until it receives some ack from the
initiator.  Early media can't be supported when that acknowledgment
comes in the form of the caller's RTP packets.

In the forking case, the caller initiates a call with one entity and
ends up with N.  Thus, whatever authenticator the caller has chosen to
use for the callee no longer holds. Callee-initiated key exchange
informs the caller that it is establishing a multi-unicast session
rather than a unicast one and allows each callee to provide its
credentials to the caller.  sdesc+sprecon also solves this problem.
But there's disagreement among some SIP developers about the
complexity of sprecon.  What this debate is missing IMO is running code.

Mark
>
>
>> Next, you note that you are reusing DTLS, yet I find DTLS-SHORT to be
>> a quite complex variation of DTLS, and I for one would like to see a
>> security analysis of all the extensions and modifications to DTLS
>> before we conclude that DTLS-SHORT is equivalent to DTLS.  It may be
>> clear to the authors, but it is not clear from the text in the I-Ds.
>
> I agree that we don't make this argument that clearly in the
> drafts. The basic intuition to have is that all the transformations
> specified in DTLS-SHORT can be done without having access to the
> keying material. This means that the adversary could have made
> those transformations himself, which severely limits the security
> impact of the transformations. The major exception, which both
> David and you raise, is that trying multiple values for the
> packet sequence/epoch combination somewhat reduces the strength
> of the MAC. However, an 80-bit MAC leaves plenty of room for
> this kind of reduction, so I'm not overly worried about that.
>
> Note that the partial encryption mode (not part of DTLS short)
> isn't a non-cryptographic transformation, but we already have
> partial coverage (we don't encrypt the header) and a NULL
> cipher version of TLS so I don't think this is going to require
> an enormous amount of non-obvious analysis, at least with a
> fixed boundary.
>
>
>> DTLS or DTLS-SHORT do not have the same on-the-wire packet format as
>> SRTP, unless you make liberal assumptions about optional fields.
>
> I assume you're referring to extensions here? I don't have a good
> intuition for how much variability there is with extensions in a given
> connection. I'd note that our major design requirement here was to
> enable header compression and debug tools, so if those work mostly OK,
> then I'm not sure it's a catastrophe if the extensions are
> encrypted. I'd definitely love to get input from AVT types on this
> point.
>
>
>> SRTP also has certain capabilities that DTLS does not have.  Of
>> course, as with DTLS-SHORT, you can continue to tweak DTLS to look  
>> and
>> behave like SRTP.  But, it is not clear what DTLS offers that
>> MIKEY+SRTP for instance don't, and why we need this elaborate  
>> exercise
>> of tweaking DTLS to behave like SRTP, instead of just using the  
>> latter
>> (it has been around for a long while now and a lot of other SDOs use
>> it quite satisfactorily).  Please elaborate!
>
> Right. The problem here isn't SRTP proper but rather key management
> for SRTP, which is turning out to be rather problematic (which,
> again, is why you're seeing so many attempts to rework it at this
> IETF mtg). DTLS's key management is clear and well understood,
> but happens to be bound to a transport security protocol that's not
> as highly tuned as SRTP. DTLS-SHORT is an attempt to capture the
> benefits of DTLS/TLS key management while getting acceptable
> transport--though admittedly not quite as good--transport
> performance.
>
> Re: your review of draft-tschofenig-avt-rtp-dtls
>
>> 1. Needs a motivation section.  I realize there is one in
>> sipping-media-dtls, but I would like to see one here as well
>> explaining why RTP over DTLS is needed or makes sense.
>
> No argument here.
>
>
>> 3.  On the text in the last paragraph of Section 4:
>>
>> "With these extensions negotiated, RTP over DTLS packets look
>>     identical to SRTP records with a 10-byte MAC value.  In fact,  
>> they
>>     cannot be distinguished without access to the DTLS or SRTP keying
>>     material.  In addition, since the RTP header is in the clear,  
>> header
>>     compression and debugging both work.  Note that DTLS running  
>> in SRTP
>>     compatibility mode has the same security properties as  
>> ordinary DTLS
>>     (with the truncated MAC); there is a reduction between the two
>>     protocols."
>>
>> a) I am curious about how DTLS or SRTP packets are distinguished in
>> the first place.  In case of SRTP, the destination, port ID and SSRC
>> identifies the crypto context.  Why not talk about things in those
>> terms and make it more concrete.
>
> I'm not sure I understand this question. Can you elaborate?
>
>
>> Why the need to be identical to SRTP packets?
>
> It's not an absolute need, but David McGrew and others have argued
> eloquently for why it's desirable for secured RTP to look as much
> as RTP as possible and we've taken that to heart.
>
>
>> b) There is no concept of SRTP records!
>
> Bad writing on my part. I meant packets.
>
>
>> c) Is there a paper on the reduction between DTLS and DTLS-short?  Is
>> DTLS-short an independent protocol or DTLS in SRTP compatibility  
>> mode?
>
> DTLS-short is a draft that specifies a set of low bandwidth extensions
> to DTLS. "SRTP compatibility mode" is a profile of various DTLS
> extensions that makes RTP over DTLS look as much like SRTP as we could
> <figure out how to make it. Re: a reduction, I think it's pretty clear
> that at least as far as passive attacks go, breaking these extensions
> would imply a serious problem with TLS, so the only issue I know about
> is the one David raised about MAC strength reduction and that's
> clearly bounded by the number of times you retry.
>
>
>> 4. Would like to see more on the subject of Section 5.  Can I  
>> conclude
>> that there will be (2 * number of sources) DTLS sessions?  How many
>> DTLS handshakes would that be? (Or is there a possibility of
>> optimization?)
>
> So, remember that DTLS has the concept of "session" (a master key,
> basically) and "connection" (inherited from TLS) which is an
> association with a given set of keying material. You can resume
> a session established in one connection when initiating another
> connection (i.e., skipping the public key ops). There is a
> bit of a race condition here if you try to establish them
> together, so naively you would get two sessions. However, you
> could probably get some resumption hence some optimization.
> I agree that a little more explanation is needed here, but
> session resumption is a pretty clearly understood feature of
> TLS/DTLS.
>
>
>> 5. Section 6 has some fundamental errors regarding RFC 3711.  The
>> statement that "SRTP uses a 4 byte MAC" is incorrect!  That entire
>> section goes on to make comparisons based on that assertion, and that
>> should be corrected.
>
> Agreed. The point we were trying to make was about packet size,
> and so we chose the MAC size that was favorable to SRTP on
> that score. But I agree we should use a 10-byte MAC.
>
>
>> "
>> In order to use DTLS/RTP in SRTP compatibility mode, implementations
>>     SHOULD negotiate:
>>     o  The TLS partial encryption extension with an InitialPlaintext
>>        value equal to the length of the RTP header.
>>     o  The DTLS implicit application data header.
>>     o  The TLS MAC truncation extension.
>>
>>
>> Shouldn't counter mode part of the list?
>
> Yes. My bad.
>
> Thanks,
> -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