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 at ietf.org
https://www1.ietf.org/mailman/listinfo/avt