Re: [AVT] Media over DTLS

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

> 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