[Perc] Diet review of draft-ietf-perc-srtp-ekt-diet-03

[Martin Thomson <[e-mail]>]

If this is the diet version of the protocol, the full-blown version
must have been mammoth, because this has lots of moving parts.  Not
that it can be trimmed much (see below), it's just an observation.

This document really needs an overview of how the pieces fit together.
It defines two separate mechanisms and the relationship between those
is not very well articulated.  A reader shouldn't have to read as much
as I did to understand that you have:

1. a DTLS connection established between peers
2. that connection used to exchange an EKT key (or keys) indexed by SPI
3. each endpoint that sends SRTP occasionally sends the keys it is
using to all recipients, encrypted under one of the EKT keys it knows

In the Security Considerations:

   EKT inherits the security properties of the DTLS-SRTP (or other)
   keying it uses.

This is untrue in a very important way.  DTLS explicitly provides
protection against key synchronization (certain attacks
notwithstanding).  The entire purpose of EKT is to enable key
synchronization.  This is introduction-worthy material in my opinion.

Finally, a design complaint: this document adds a new message to TLS
(one of the two key exchange methods).  That message has an inner type
that is extensible.  I would prefer if this were to define multiple
message types.  In particular, DTLS 1.3 is adding acknowledgments at
the DTLS layer, which will produce redundant mechanisms.