[AVT] Comments on draft-wing-avt-dtls-srtp-key-transport-01

[Eric Rescorla <ekr at networkresonance.com>]

$Id: draft-wing-avt-dtls-key-transport-01-rev.txt,v 1.1 2008/03/11 13:57:27 ekr Exp $

GENERAL COMMENTS
DTLS-SRTP was explicitly designed for point-to-point sessions in which
there were two communication parties. This implies that a number of
RTP settings (e.g., conference bridges/mixers), need to be implemented
as a number of pairwise DTLS-SRTP connections. Thus, for instance,
when a single caller on a conference bridge speaks, the bridge needs
to reencrypt the data for all recipients separately. There has been
debate about how serious this performance issue is, but people
certainly have been concerned about it.

This draft describes a mechanism which allows one side of a DTLS-SRTP
association to impose a key of its choice on the other side. Thus, for
instance, the mixer/bridge could give each caller the same receiving
key (the one that the bridge uses to send/encrypt). Thus, the bridge
can only perform one encryption instead of one for each recipient.
This doesn't seem like a crazy idea.

That said, I have two major concerns about the particular mechanism
described in this document:

- It's specified at the DTLS layer but it's only useful for DTLS-SRTP,
  and doesn't really affect the DTLS part at all. I would prefer to
  see this either specified as a TLS extension that applies to TLS in
  all contexts, or to be specified purely as a feature of SRTP
  (a la EKT, though I'm not claiming it's adequate as-is).
- The mechanism described here seems a lot more complicated 
  (the ability to request keys, convey SSRCs, etc.) than required
  by the requirements I'm aware of.


DETAILED COMMENTS
S 4.1.
   After successful negotiation of the key_transport extension, the DTLS
   client and server MAY exchange SRTP packets, encrypted using the KDF
   described in [I-D.ietf-avt-dtls-srtp].  This is normal and expected,

I wouldn't write this as "encrypted using the KDF". The keys are generated
with a KDF, but the packets aren't.


S 4.2.
What's the need to request a new key.

I don't understand why the SSRC needs to be communicated, given that
DTLS-SRTP already describes mechanisms for SSRC->Key Material mapping.
Also, this breaks the general RTP model that implies that new SSRCs
can be introduced at any time, which (though I'm no RTP expert)
seems like it's going to be a lot worse in mutiparty cases. 

I don't understand wy keys need to be deleted.

Under what circumstances would these messages be large enough to
exceed 512 bytes and thus potentially need fragmentation?

-Ekr
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt