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

Commentary: This PR addresses IESG review comments from   ,   , and   ( while he was still SEC AD ) . 
 LGTM
Paragraph (version A):
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):
Epoch: This field indicates how many SRTP keys have been sent for
this SSRC under the current EKTKey, prior to the current key, as a
two-byte integer in network byte order.  It starts at zero at the
beginning of a session and resets to zero whenever the EKTKey is
changed (i.e., when a new SPI appears).  The epoch for an SSRC
increments by one every time the sender transmits a new key.  The
recipient of a FullEKTField MUST reject any future FullEKTField for
this SPI and SSRC that has an equal or lower epoch value to an epoch
already seen.
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.
Paragraph (version A):
The computed value of the FullEKTField is appended to the SRTP
packet.
Paragraph (version A):
Outbound packets SHOULD continue to use the old SRTP Master Key for
250 ms after sending any new key.  This gives all the receivers in
the system time to get the new key before they start receiving media
encrypted with the new key.
Paragraph (version B):
The computed value of the FullEKTField is appended to the end of the
SRTP packet, after the encrypted payload.
Paragraph (version A):
EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext.  This specification defines the interface to the
cipher, in order to abstract the interface away from the details of
that function.  This specification also defines the default cipher
that is used in EKT.  The default cipher described in DefaultCipher
MUST be implemented, but another cipher that conforms to this
interface MAY be used.
Paragraph (version B):
EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext.  This specification defines the interface to the
cipher, in order to abstract the interface away from the details of
that function.  This specification also defines the default cipher
that is used in EKT.  The default cipher described in DefaultCipher
MUST be implemented, but another cipher that conforms to this
interface MAY be used.  The cipher used for a given EKTCiphertext
value is negotiated using the supported_ekt_ciphers and indicated
with the SPI value in the FullEKTField.
Paragraph (version B):
In cases where the DTLS termination point is more trusted than the
media relay, the protection that DTLS affords to EKT key material can
allow EKT keys to be tunneled through an untrusted relay such as a
centralized conference bridge.  For more details, see I-D.ietf-perc-
private-media-framework.
Paragraph (version A):
Note: To be clear, EKT can be used with versions of DTLS prior to
have built-in support for generating and processing Ack messages.
Paragraph (version B):
EKT MAY be used with versions of DTLS prior to 1.3.  In such cases,
the Ack message is still used to provide reliability.  Thus, DTLS
implementations supporting EKT with DTLS pre-1.3 will need to have
explicit affordances for sending the Ack message in response to an
EKTKey message, and for verifying that an Ack message was received.
The retransmission rules for both sides are the same as in DTLS 1.3.
Paragraph (version A):
The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream.
Paragraph (version A):
An attacker who tampers with the bits in FullEKTField can prevent the
intended receiver of that packet from being able to decrypt it.  This
is a minor denial of service vulnerability.  Similarly the attacker
could take an old FullEKTField from the same session and attach it to
the packet.  The FullEKTField would correctly decode and pass
integrity checks.  However, the key extracted from the FullEKTField ,
when used to decrypt the SRTP payload, would be wrong and the SRTP
integrity check would fail.  Note that the FullEKTField only changes
the decryption key and does not change the encryption key.  None of
these are considered significant attacks as any attacker that can
modify the packets in transit can cause the integrity check to fail.
Paragraph (version B):
The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream.  This mitigates the impact of the cut-and-paste attacks
that arise due to the lack of a cryptographic binding between the EKT
tag and the rest of the SRTP packet.  SRTP tags can only be cut-and-
pasted within the stream of packets sent by a given RTP endpoint; an
attacker cannot "cross the streams" and use an EKT tag from one SSRC
to reset the key for another SSRC.  The epoch field in the
FullEKTField also prevents an attacker from rolling back to a
previous key.
Paragraph (version B):
The key encryption keys distributed with EKTKey messages are group
shared symmetric keys, which means they do not provide protection
within the group.  Group members can impersonate each other; for
example, any group member can generate an EKT tag for any SSRC.  The
entity that distributes EKTKeys can decrypt any keys distributed
using EKT, and thus any media protected with those keys.
Paragraph (version A):
New entries to this table can be added via "Specification Required"
as defined in RFC8126.  When requesting a new value, the requestor
needs to indicate if it is mandatory to understand or not.  If it is
mandatory to understand, IANA needs to allocate a value less than 64,
if it is not mandatory to understand, a value greater than or equal
to 64 needs to be allocated.  IANA SHOULD prefer allocation of even
values over odd ones until the even code points are consumed to avoid
conflicts with pre standard versions of EKT that have been deployed.
Paragraph (version A):
All new EKT messages MUST be defined to have a length as second from
the last element.
Paragraph (version B):
New entries to this table can be added via "Specification Required"
as defined in RFC8126.  IANA SHOULD prefer allocation of even values
over odd ones until the even code points are consumed to avoid
conflicts with pre standard versions of EKT that have been deployed.
Allocated values MUST be in the range of 0 to 254.
Paragraph (version B):
All new EKT messages MUST be defined to have a length as second from
the last element, as specified.
Paragraph (version A):
New entries to this table can be added via "Specification Required"
as defined in RFC8126.  The expert SHOULD ensure the specification
defines the values for L and T as required in cipher of RFCAAAA.
Allocated values MUST be in the range of 1 to 254.
Paragraph (version A):
IANA is requested to add supported_ekt_ciphers as a new extension
name to the "TLS ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this.
Paragraph (version B):
New entries to this table can be added via "Specification Required"
as defined in RFC8126.  The expert SHOULD ensure the specification
defines the values for L and T as required in cipher of RFCAAAA.
Allocated values MUST be in the range of 0 to 254.
Paragraph (version A):
IANA is requested to add ekt_key as a new entry in the "TLS
HandshakeType Registry" table of the "Transport Layer Security (TLS)
Parameters" registry with a reference to this specification, a DTLS-
OK value of "Y", and allocate a value of TBD to for this content
type.