Draft: draft-ietf-perc-double

Commentary: This PR responds to IESG review comments from Magnus Westerlund , except for his comments on RED , which I have n't quite figured out how to address yet . 
 LGTM with nits
Paragraph (version A):
This specification defines a transform for the Secure Real Time
Protocol (SRTP) that uses the AES-GCM algorithm RFC7714 to provide
encryption and integrity for an RTP packet for the end-to-end
cryptographic key as well as a hop-by-hop cryptographic encryption
and integrity between the endpoint and the Media Distributor.  The
Media Distributor decrypts and checks integrity of the hop-by-hop
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
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.
Paragraph (version B):
This specification defines a transform for the Secure Real Time
Protocol (SRTP) that uses the AES-GCM algorithm RFC7714 to provide
encryption and integrity for an RTP packet for the end-to-end
cryptographic key as well as a hop-by-hop cryptographic encryption
and integrity between the endpoint and the Media Distributor.  The
Media Distributor decrypts and checks integrity of the hop-by-hop
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
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.
Paragraph (version A):
represents the AES_CM PRF KDF RFC3711 for
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.
Paragraph (version B):
represents the AES_CM PRF KDF (see Section 4.3.3 of RFC3711) for
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.
Paragraph (version A):
The Original Header Block (OHB) contains the original values of any
modified RTP header fields.  In the encryption process, the OHB is
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.
Paragraph (version B):
The Original Header Block (OHB) contains the original values of any
modified RTP header fields.  In the encryption process, the OHB is
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.
Paragraph (version A):
In order to avoid nonce reuse, the cryptographic contexts used in
step 1 and step 5 MUST use different, independent master keys and
master salts.
Paragraph (version B):
In order to avoid nonce reuse, the cryptographic contexts used in
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.
Paragraph (version A):
A Media Distributor that decrypts, modifies, and re-encrypts packets
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.
Paragraph (version B):
A Media Distributor that decrypts, modifies, and re-encrypts packets
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.
Paragraph (version A):
Media distributors sometimes interact with RTP media packets sent by
endpoints, e.g., to provide recovery or receive commands via DTMF.
When media packets are encrypted end-to-end, these procedures require
modification.
Paragraph (version A):
Repair mechanisms, in general, will need to perform recovery on
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
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.
Paragraph (version B):
Repair mechanisms, in general, will need to perform recovery on
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.
Paragraph (version B):
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
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.
Paragraph (version A):
When using RED RFC2198 with double, the primary encoding MAY contain
RTP header extensions and CSRC identifiers but non primary encodings
cannot.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version A):
The protections with regard to the network are the same as with the
normal SRTP AES-GCM transforms.
Paragraph (version B):
The protections with regard to the network are the same as with the
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.
Paragraph (version A):
The main innovation of this transform relative to other SRTP
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,
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.
Paragraph (version B):
The main innovation of this transform relative to other SRTP
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,
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.