Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: LGTM 
 One concern inline but rest looks good
Paragraph (version A):
The inability of SRTP to work in the absence of central control was
well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth
conservation.  Additionally, in many situations SRTP is used in
conjunction with a signaling system that can provide the central
control needed by SRTP.  However, there are several cases in which
conventional signaling systems cannot easily provide all of the
coordination required.  It is also desirable to eliminate the layer
violations that occur when signaling systems coordinate certain SRTP
parameters, such as SSRC values and ROCs.
Paragraph (version B):
The inability of SRTP to work in the absence of central control was
well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth
conservation.  Additionally, in many situations SRTP is used in
conjunction with a signaling system that can provide the central
control needed by SRTP.  However, there are several cases in which
conventional signaling systems cannot easily provide all of the
coordination required.
Paragraph (version A):
EKT provides a way for an SRTP session participant, to securely
transport its SRTP master key and current SRTP rollover counter to
the other participants in the session.  This data furnishes the
information needed by the receiver to instantiate an SRTP/SRTCP
receiver context.
Paragraph (version B):
EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP
rollover counter to the other participants in the session.  This data
furnishes the information needed by the receiver to instantiate an
SRTP/SRTCP receiver context.
Paragraph (version A):
EKT does not control the manner in which the SSRC is generated; it is
only concerned with their secure transport.
Paragraph (version A):
EKT is not intended to replace external key establishment mechanisms.
Instead, it is used in conjunction with those methods, and it
relieves those methods of the burden to deliver the context for each
SRTP source to every SRTP participant.
Paragraph (version B):
EKT does not control the manner in which the SSRC is generated.  It
is only concerned with distributing the security parameters that an
endpoint needs to associate with a given SSRC in order to decrypt
SRTP packets from that sender.
Paragraph (version B):
EKT is not intended to replace external key establishment mechanisms.
Instead, it is used in conjunction with those methods, and it
relieves those methods of the burden to deliver the context for each
SRTP source to every SRTP participant.  This document defines how EKT
works with the DTLS-SRTP approach to key establishment, by using keys
derived from the DTLS-SRTP handshake to encipher the EKTKey in
addition to the SRTP media.
Paragraph (version A):
SSRC: On the sender side, this is the SSRC for this SRTP source.  The
length of this field is 32 bits.
Paragraph (version B):
SSRC: On the sender side, this is the SSRC for this SRTP source.  The
length of this field is 32 bits.  The SSRC value in the EKT tag MUST
be the same as the one in the header of the SRTP packet to which the
tag is appended.
Paragraph (version A):
Together, these data elements are called an EKT parameter set.  Each
distinct EKT parameter set that is used MUST be associated with a
distinct SPI value to avoid ambiguity.
Paragraph (version B):
Security Parameter Index (SPI): This field indicates the appropriate
EKTKey and other parameters for the receiver to use when processing
the packet.  The length of this field is 16 bits.
Paragraph (version B):
Together, these data elements are called an "EKT parameter set".
Each distinct EKT parameter set that is used MUST be associated with
a distinct SPI value to avoid ambiguity.  The association of a given
parameter set with a given SPI value is configured by some other
protocol, e.g., the DTLS-SRTP extension defined in dtls-srtp-kt.
Paragraph (version A):
and SRTCP traffic.
Paragraph (version B):
and SRTCP traffic.  If a participant deletes an EKT parameter set
(e.g., because of space limitations, then it will be unable to
process Full EKT Tags containing updated media keys, and thus unable
to receive media from a particpant that has changed its media key.
Paragraph (version A):
An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-impl-notes
helps mitigate this issue.
Paragraph (version B):
An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-processing
helps mitigate this issue.