Change:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM

Discussion:
Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing <del> the packet.  The length of this field is 16 bits. </del> <ins> the packet, within a given conference.  The length of this field is 16 bits, representing a two-byte integer in network byte order.  The parameters identified by this field are: 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. 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. </ins> EKTMsgLength: All EKT messages types other than the ShortEKTField have a length as second from the last element.  This is the length in

steps.  The creation of the EKTField MUST precede the normal SRTP packet processing. <del> The computed value of the FullEKTField is appended to the SRTP packet. </del> <ins> The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload. </ins> When a packet is sent with the ShortEKTField, the ShortEKFField is simply appended to the packet. Outbound packets SHOULD continue to use the old SRTP Master Key for <del> 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. </del> <ins> 250 ms after sending any new key in a FullEKTField value.  This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key.  (The specific value of 250ms is chosen to represent a reasonable upper bound on the amount of latency and jitter that is tolerable in a real-time context.) </ins> 4.3.2.

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 <del> interface MAY be used. </del> <ins> 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. </ins> An EKTCipher consists of an encryption function and a decryption function.  The encryption function E(K, P) takes the following

along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. <ins> 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. </ins> 5.1. DTLS-SRTP RFC5764 uses an extended DTLS exchange between two peers to

of I-D.ietf-tls-dtls13.  The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of RFC6347. <del> Note: To be clear, EKT can be used with versions of DTLS prior to 1.3.  The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. </del> <ins> 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. </ins> If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert.

The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another <del> SRTP stream. 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. </del> <ins> 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. </ins> An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system

position to mount these attacks, however, could achieve the same effects more easily without attacking EKT. <ins> 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. </ins> Each EKT cipher specifies a value T that is the maximum number of times a given key can be used.  An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey.  In

this specification. New entries to this table can be added via "Specification Required" <del> 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 </del> <ins> as defined in RFC8126.  IANA SHOULD prefer allocation of even values over odd ones until the even code points are consumed to avoid </ins> conflicts with pre standard versions of EKT that have been deployed. <ins> Allocated values MUST be in the range of 0 to 254. </ins> All new EKT messages MUST be defined to have a length as second from <del> the last element. </del> <ins> the last element, as specified. </ins> 7.2.

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. <del> Allocated values MUST be in the range of 1 to 254. </del> <ins> Allocated values MUST be in the range of 0 to 254. </ins> 7.3. IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer <del> Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. </del> <ins> Security (TLS) Extensions" registry: </ins> [[ Note to RFC Editor: TBD will be allocated by IANA. ]]

IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) <del> 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. </del> <ins> Parameters" registry: </ins> [[ Note to RFC Editor: TBD will be allocated by IANA. ]]