Change:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits

Discussion:
security.  The Media Distributor MAY change some of the RTP header information that would impact the end-to-end integrity.  In that case, the original value of any RTP header field that is changed is <del> included in a new RTP header extension called the Original Header Block.  The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </del> <ins> included in an "Original Header Block" that is added to the packet. The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </ins> One can think of the double as a normal SRTP transform for encrypting the RTP in a way where things that only know half of the key, can

Here <del> represents the AES_CM PRF KDF RFC3711 for </del> <ins> represents the AES_CM PRF KDF (see Section 4.3.3 of RFC3711) for </ins> DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF KDF RFC6188 for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.

The Original Header Block (OHB) contains the original values of any modified RTP header fields.  In the encryption process, the OHB is <del> appended to the RTP payload.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. </del> <ins> included in an SRTP packet as described in rtp-operations.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. </ins> The OHB can reflect modifications to the following fields in an RTP header: the payload type, the sequence number, and the marker bit.

transmitting. In order to avoid nonce reuse, the cryptographic contexts used in <del> step 1 and step 5 MUST use different, independent master keys and master salts. </del> <ins> step 1 and step 5 MUST use different, independent master keys.  Note that this means that the key used for decryption by the MD MUST be different from the key used for re-encryption to the end recipient. </ins> Note that if multiple MDs modify the same packet, then the first MD to alter a given header field is the one that adds it to the OHB.  If

no update to the OHB is required. A Media Distributor that decrypts, modifies, and re-encrypts packets <del> in this way MUST use an independent key for each recipient, SHOULD use an independent salt for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES- GCM. </del> <ins> in this way MUST use an independent key for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES-GCM. </ins> 5.3.

7. <del> Media distributors sometimes interact with RTP media packets sent by </del> <ins> Media Distributors sometimes interact with RTP media packets sent by </ins> endpoints, e.g., to provide recovery or receive commands via DTMF. When media packets are encrypted end-to-end, these procedures require <del> modification. </del> <ins> modification.  (End-to-end interactions, including end-to-end recovery, are not affected by end-to-end encryption.) </ins> Repair mechanisms, in general, will need to perform recovery on <del> encrypted packets (double-encrypted when using this transform).  When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key.  This allows a media distributor to generate recovery packets without </del> <ins> encrypted packets (double-encrypted when using this transform), since the Media Distributor does not have access to the plaintext of the packet, only an intermediate, E2E-encrypted form. When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key. This allows a media distributor to generate recovery packets without </ins> having access to the inner, end-to-end keys.  However, it also results in recovery packets being triple-encrypted, twice for the base transform, and once for the recovery protection.

be encrypted the packet in repair mode (i.e., with only the hop-by- hop key). <ins> If the Media Distributor were to cache the inner, E2E-encrypted payload and retransmit that with an RTX OSN field prepended, then the modifications to the payload would cause the inner integrity check to fail at the receiver. </ins> A typical RTX receiver would decrypt the packet, undo the RTX transformation, then process the resulting packet normally by using the steps in decrypt. 7.2. <del> When using RED RFC2198 with double, the primary encoding MAY contain RTP header extensions and CSRC identifiers but non primary encodings cannot. The sender takes encrypted payload from the cached packets to form the RED payload.  Any header extensions from the primary encoding are copied to the RTP packet that will carry the RED payload and the other RTP header information (SSRC, SEQ, CSRC, etc.) are set to the same as the primary payload.  The RED RTP packet is then encrypted in repair mode and sent. The receiver decrypts the payload to find the encrypted RED payload. Note a media relay can do this decryption as the packet was sent in repair mode that only needs the hop-by-hop key.  The RTP headers and header extensions along with the primary payload and PT from inside the RED payload (for the primary encoding) are used to form the encrypted primary RTP packet which can then be decrypted with double. The RTP headers (but not header extensions or CSRC) along with PT from inside the RED payload corresponding to the redundant encoding are used to from the non-primary payloads.  The time offset and packet rate information in the RED data MUST be used to adjust the sequence number in the RTP header.  At this point the non primary packets can be decrypted with double. Note that Flex FEC I-D.ietf-payload-flexible-fec-scheme is a superset of the capabilities of RED.  For most applications, FlexFEC is a better choice than RED. </del> <ins> When using RED RFC2198 with double, the processing at the sender and receiver is the same as when using RED with any other SRTP transform. The main difference between double and any other transform is that in an intermediated environment, usage of RED must be end-to-end.  A Media Distributor cannot synthesize RED packets, because it lacks access to the plaintext media payloads that are combined to form a RED payload. Note that FlexFEC may often provide similar or better repair capabilities compared to RED.  For most applications, FlexFEC is a better choice than RED; in particular, FlexFEC has modes in which the Media Distributor can synthesize recovery packets. </ins> 7.3.

The AES-GCM cryptographic algorithm introduces an additional 16 octets to the length of the packet.  When using AES-GCM for both the inner and outer cryptographic algorithms, the total additional length <del> is 32 octets.  If no other header extensions are present in the packet and the OHB is introduced, that will consume an additional 8 octets.  If other extensions are already present, the OHB will consume up to 4 additional octets.  Packets in repair mode will carry additional repair data, further increasing their size. </del> <ins> is 32 octets.  The OHB will consume an additional 1-4 octets. Packets in repair mode will carry additional repair data, further increasing their size. </ins> 9.

and outer keys. The protections with regard to the network are the same as with the <del> normal SRTP AES-GCM transforms. </del> <ins> normal SRTP AES-GCM transforms.  The major difference is that the double transforms are designed to work better in a group context.  In such contexts, it is important to note that because these transforms are symmetric, they do not protect against attacks within the group. Any member of the group can generate valid SRTP packets for any SSRC in use by the group. </ins> With regard to a malicious MD, the recipient can verify the integrity of the base header fields and confidentiality and integrity of the

transforms is that it allows a partly-trusted MD to decrypt, modify, and re-encrypt a packet.  When this is done, the cryptographic contexts used for decryption and re-encryption MUST use different, <del> independent master keys and master salts.  If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM. </del> <ins> independent master keys.  If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM. </ins> In other words, from the perspective of the MD, re-encrypting packets using this protocol will involve the same cryptographic operations as