of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the <del> Partial IV (Sequence Number) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </del>  Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV) <del> with the Sender Sequence Number (partial IV). </del>  If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)

This should fix issue
As per Christian Amsüss' message from 2017-01-04 we should clarify how we expect implementers to map sequence numbers to partial IV's. I think that network-byte order is a good way.

of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the  <ins> Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </ins> Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV)  <ins> with the Sender Sequence Number in network byte order (partial IV). </ins> If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)


length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. <del> If the OHB is one octet in length, it contains both the original X bit and PT field value.  In this case, the OHB has this form: </del>  If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: <del> If the OHB is three octets in length, it contains the original X bit, PT field value, and RTP packet sequence number.  In this case, the OHB has this form: </del>  If an MDD modifies an original RTP header value, the MDD MUST include <del> the OHB extension to reflect the changed value.  If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </del>  5.

2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.

length, or three octets in length.  The length of the OHB indicates what data is contained in the extension.  <ins> If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt. </ins> If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form:  <ins> If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: </ins> If an MDD modifies an original RTP header value, the MDD MUST include  <ins> the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present. If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB. To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </ins> 5.


typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra <del> envelope information.  This, along with the OBH, is used to construct </del>  a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.

Make sure double can work with future FEC schemes that do HBH repair and have state that could be corrupted by non authenticated packets
resolved in latest draft

typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra  <ins> envelope information.  This, along with the OHB, is used to construct </ins> a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.


The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension.  5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at

EKT draft should make a clear naming difference between the message form TLS server / client and the the thing that goes at end of RTP packet Also clear up figure 5. First packets go to KD, last several packets go elsewhere
The PR fixes the figure. I looked at the naming and I don't think there is anything to be done to make it clearer.

The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. <ins> Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the oter packets will be relayed by the Media Distributor to the Key Distributor. </ins> 5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at


Media Distributor or an endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two <del> security contexts and two associated encryption keys; an "inner" key (E2E Key(i); i={a given endpoint}) for authenticated encryption of RTP media between endpoints and an "outer" key (HBH Key(j); j={a given hop}) for the hop between an endpoint and a Media Distributor or between Media Distributor.  Reference the following figure. The PERC Double draft specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to-end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop-by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation. </del>  RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated To ensure the confidentiality of E2E keys shared between endpoints, endpoints will make use of a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference.  That KEK, <del> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKTKey, will be used to subsequently encrypt SRTP master keys used for E2E authenticated encryption (E2E Key(i); i={a given endpoint}) of media sent by a given endpoint. </del>  4.3. transmitted during the life of a conference. Thus, endpoints MUST maintain a list of SSRCs from received RTP flows <del> and each SSRC's associated E2E Key(i) information.  Following a change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD be retained for a period long enough to ensure that late-arriving or out-of-order packets from other endpoints can be successfully decrypted.  The endpoint MUST discard the E2E Key(i) and KEK information no later than when it leaves the conference. </del>  If there is a need to encrypt one or more RTP header extensions end- to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys. </del>  4.4. an endpoint and a Media Distributor, as well between Media Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the <del> respective hop (HBH Key(j); j={a given hop}).  Each HBH Key(j) is distinct per hop and no two hops ever intentionally use the same SRTP master key. </del>  Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media <del> Distributor to establish HBH keys for transmitting RTP and RTCP </del>  packets to that peer Media Distributor.  The Key Distributor does not <del> facilitate establishing HBH keys for use between Media Distributors. </del>  4.5.1. association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to receive E2E key <del> information, Key Encryption Key (KEK) information (i.e., EKTKey), and HBH key information.  At the same time, the Key Distributor can </del>  securely provide the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. 4.5.2. Following the initial key information exchange with the Key <del> Distributor, endpoints will be able to encrypt media end-to-end with their E2E Key(i), sending that E2E Key(i) to other endpoints encrypted with KEK, and will be able to encrypt and authenticate RTP packets using local HBH Key(j).  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKTKey) may need to change from time-to-time during </del>  the life of a conference, such as when a new participant joins or leaves a conference.  Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference. <del> When a Key Distributor decides to rekey a conference, it transmits a </del>  specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.  The endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information <del> from a new inbound EKTKey immediately.  See Section 2.2.2 of I- </del>  D.ietf-perc-srtp-ekt-diet. 5.

This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM

Media Distributor or an endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two  <ins> security contexts and two associated encryption keys: an "inner" key (an E2E key distinct for each transmitted media flow) for authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media Distributor or between Media Distributor.  Reference the following figure. The PERC Double specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to- end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop- by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation.  (See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire.) </ins> RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated To ensure the confidentiality of E2E keys shared between endpoints, endpoints will make use of a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference.  That KEK,  <ins> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKT Key, will be used to subsequently encrypt the SRTP master key used for E2E authenticated encryption of media sent by a given endpoint.  Each endpoint in the conference will create a random SRTP master key for E2E authenticated encryption, thus participants in the conference MUST keep track of the E2E keys received via the Full EKT Field for each distinct SSRC in the conference so that it can properly decrypt received media.  Note, too, that an endpoint may change its E2E key at any time and advertise that new key to the conference as specified in I-D.ietf-perc-srtp-ekt-diet. </ins> 4.3. transmitted during the life of a conference. Thus, endpoints MUST maintain a list of SSRCs from received RTP flows  <ins> and each SSRC's associated E2E key information.  Following a change in an E2E key, prior E2E keys SHOULD be retained by receivers for a period long enough to ensure that late-arriving or out-of-order packets from the endpoint can be successfully decrypted.  Receiving endpoints MUST discard old E2E keys no later than when it leaves the conference. </ins> If there is a need to encrypt one or more RTP header extensions end- to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those  <ins> header extensions encrypted with an E2E key. </ins> 4.4. an endpoint and a Media Distributor, as well between Media Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the  <ins> respective hop.  Each HBH key is distinct per hop and no two hops ever intentionally use the same SRTP master key. </ins> Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media  <ins> Distributor to establish the HBH key for transmitting RTP and RTCP </ins> packets to that peer Media Distributor.  The Key Distributor does not  <ins> facilitate establishing a HBH key for use between Media Distributors. </ins> 4.5.1. association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to receive E2E key  <ins> information, Key Encryption Key (KEK) information (i.e., EKT Key), and HBH key information.  At the same time, the Key Distributor can </ins> securely provide the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. 4.5.2. Following the initial key information exchange with the Key  <ins> Distributor, an endpoints will be able to encrypt media end-to-end with an E2E key, sending that E2E key to other endpoints encrypted with the KEK, and will be able to encrypt and authenticate RTP packets using a HBH key.  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKT Key) may need to change from time-to-time during </ins> the life of a conference, such as when a new participant joins or leaves a conference.  Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference.  <ins> When a Key Distributor decides to re-key a conference, it transmits a </ins> specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.  The endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information  <ins> from a new inbound EKT Key immediately.  See Section 2.2.2 of I- </ins> D.ietf-perc-srtp-ekt-diet. 5.


7.1. <del> TODO - Add text to explain how to use RTX as described in Option A of slides presented at IETF 99. </del>  7.2.

This is not ready to merge yet but can be used to start discussion on RTX text
Higher level question .. Should it help having a generic repair processing section that identifies the sender and receiver behavior. It could be informative and can reflect the pictures from the presentation. Thoughts ?
I think as confusing as the whole topic is/was to us experts I think we should have a paragraph explaining that any of the repairs are effectively a triple encryption.
looks good

7.1.  <ins> When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be encrypted using a crypto context with a null E2E key. </ins> 7.2.


4. <del> Any SRTP packet processed following these procedures MAY contain an Original Header Block (OHB) RTP header extension. The OHB contains the original values of any modified header fields and MUST be placed after any already-existing RTP header extensions. Placement of the OHB after any original header extensions is important so that the receiving endpoint can properly authenticate the original packet and any originally included RTP header extensions.  The receiving endpoint will authenticate the original packet by restoring the modified RTP header field values and header extensions.  It does this by copying the original values from the OHB and then removing the OHB extension and any other RTP header extensions that appear after the OHB extension. The Media Distributor is only permitted to modify the extension (X) bit, payload type (PT) field, and the RTP sequence number field. The OHB extension is either one octet in length, two octets in length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt.  ID is the RTP Header Extension identifier negotiated in the SDP. If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: If a Media Distributor modifies an original RTP header value, the Media Distributor MUST include the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present.  If another Media Distributor along the media path makes additional changes to the RTP header and any original value is already present in the OHB, the Media Distributor must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, a Media Distributor MUST NOT change a value already present in the OHB extension. </del>  5.

This PR refactors the packet format in -double to be friendlier to implementations using double-unaware base transforms. Move the OHB to the payload of the packet Arrange the inner tag, OHB, and outer tag so that appending / truncation are the only transormations needed in the encryption / decryption process Remove support for E2E-protected header extensions, so that implementations don't need header-processing logic

4.  <ins> The Original Header Block (OHB) contains the original values of any modified 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. The OHB can reflect modifications to the following fields in an RTP header: the payload type, the sequence number, and the marker bit. All other fields in the RTP header MUST remain unmodified; since the OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet. The OHB has the following syntax (in ABNF): If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively.  The final "config" octet of the OHB specifies whether these fields are present, and the original value of the marker bit (if necessary): In particular, an all-zero OHB config octet (0x00) indicates that there have been no modifications from the original header. </ins> 5.


provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel.  4. The Original Header Block (OHB) contains the original values of any

Right now, the SRTP KDF destroys the separation between the inner and outer halves of the master key, which means that EKT can't set the E2E key without also resetting the HBH key. This PR moves from the default SRTP KDF to use a "split PRF" that preserves the separation between the E2E and HBH halves of the key.
LGTM

provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel. <ins> 3.1. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following PRF, which preserves the separation between the two halves of the key: Here represents the default SRTP PRF RFC3711, represents the first half of the key, and represents the second half of the key. </ins> 4. The Original Header Block (OHB) contains the original values of any


Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized.  Trusted endpoint authorization is described in I- D.roach-perc-webrtc. </del>  A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects 3.2.2. <del> The Key Distributor, which may be collocated with an endpoint or exist standalone, is responsible for providing key information to endpoints for both end-to-end and hop-by-hop security and for providing key information to Media Distributors for the hop-by-hop security. </del>  Interaction between the Key Distributor and the call processing function is necessary to for proper conference-to-endpoint mappings. authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media <del> Distributor or between Media Distributor.  Reference the following figure. The PERC Double specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to- end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop- by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation.  (See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire.) </del>  RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the respective hop.  Each HBH key is distinct per hop and no two hops <del> ever intentionally use the same SRTP master key. </del>  Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media 4.5.  4.5.1. <del> The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls- tunnel establish one or more TLS tunnels between the Media Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS </del>  association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to generate E2E and HBH additional protocol or interface is required. In establishing the DTLS association between endpoints and the Key <del> Distributor, the endpoint acts as the DTLS client and the Key Distributor acts as the DTLS server.  The Key Encryption Key (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT I-D.ietf- perc-srtp-ekt-diet via the EKTKey message. </del>  Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double cipher, the endpoint will generate both E2E and HBH encryption keys and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key <del> or MAY generate different E2E keys.  In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Distributor via the EKTKey message.  That is because every endpoint in the conference uses the same SRTP master salt.  The endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other endpoints in RTP/RTCP packets per I- D.ietf-perc-srtp-ekt-diet. </del>  Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish the HBH key for transmitting RTP and RTCP 5. It is important to this solution framework that the entities can <del> trust and validate the authenticity of other entities, especially the Key Distributor and endpoints.  The details of this are outside the scope of specification but a few possibilities are discussed in the </del>  following sections.  The key requirements is that endpoints can verify they are connected to the correct Key Distributor for the conference and the Key Distributor can verify the endpoints are the

This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.

Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is  <ins> authorized.  Instead, the Key Distributor is responsible for authenticating endpoints (e.g., using WebRTC Identity I-D.ietf- rtcweb-security-arch) and determining their authorization to receive E2E media encryption keys. </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects 3.2.2.  <ins> The Key Distributor, which may be colocated with an endpoint or exist standalone, is responsible for providing key information to endpoints for both end-to-end and hop-by-hop security and for providing key information to Media Distributors for the hop-by-hop security. </ins> Interaction between the Key Distributor and the call processing function is necessary to for proper conference-to-endpoint mappings. authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media  <ins> Distributor or between Media Distributor. The PERC Double transform I-D.ietf-perc-double enables endpoints to perform encryption using both the E2E and HBH contexts while still preserving the same overall interface as other SRTP transforms.  The Media Distributor simply uses the corresponding normal (single) AES- GCM transform, keyed with the appropriate HBH keys.  See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire. </ins> RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the respective hop.  Each HBH key is distinct per hop and no two hops  <ins> ever use the same SRTP master key. </ins> Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media 4.5. <ins> In brief, the keys used by any given endpoints are determined in the following way: </ins> 4.5.1.  <ins> The Media Distributor maintains a tunnel with the Key Distrubutor (e.g., using I-D.ietf-perc-dtls-tunnel), making it possible for the Media Distributor to facilitate the establishment of a secure DTLS </ins> association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to generate E2E and HBH additional protocol or interface is required. In establishing the DTLS association between endpoints and the Key  <ins> Distributor, the endpoint MUST act as the DTLS client and the Key Distributor MUST act as the DTLS server.  The Key Encryption Key (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT I- D.ietf-perc-srtp-ekt-diet via the EKTKey message. </ins> Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double cipher, the endpoint will generate both E2E and HBH encryption keys and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key  <ins> for transmission or MAY generate a fresh E2E key.  In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Distributor via the EKTKey message.  That is because every endpoint in the conference uses the same SRTP master salt.  The endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other endpoints in RTP/ RTCP packets per I-D.ietf-perc-srtp-ekt-diet. </ins> Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish the HBH key for transmitting RTP and RTCP 5. It is important to this solution framework that the entities can  <ins> validate the authenticity of other entities, especially the Key Distributor and endpoints.  The details of this are outside the scope of specification but a few possibilities are discussed in the </ins> following sections.  The key requirements is that endpoints can verify they are connected to the correct Key Distributor for the conference and the Key Distributor can verify the endpoints are 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- <del> to-end integrity.  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. </del>  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 <del> decrypt and modify part of the RTP packet but not other parts of if </del>  including the media payload. 2. 3. <del> This specification uses a cryptographic context with two parts: an inner (end-to-end) part that is used by endpoints that originate and consume media to ensure the integrity of media end-to-end, and an outer (hop-by-hop) part that is used between endpoints and Media Distributors to ensure the integrity of media over a single hop and to enable a Media Distributor to modify certain RTP header fields. RTCP is also handled using the hop-by-hop cryptographic part.  The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is </del>  AES-GCM.  Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry. 4. The Original Header Block (OHB) contains the original values of any <del> modified 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. OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet. <del> The OHB has the following syntax (in ABNF): </del>  If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively.  The final 5.2. The Media Distributor has the part of the key for the outer (hop-by- <del> hop), but it does not have the part of the key for the (end-to-end) cryptographic algorithm.  The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key. </del>  In order to modify a packet, the Media Distributor decrypts the <del> packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the cryptographic using the outer (hop-by-hop) key. </del>  5.3. 6. Unlike RTP, which is encrypted both hop-by-hop and end-to-end using <del> two separate cryptographic key, RTCP is encrypted using only the </del>  outer (hop-by-hop) cryptographic key.  The procedures for RTCP encryption are specified in RFC3711 and this document introduces no additional steps. There are some RTP related extensions that need special consideration to be used by a relay when using the double transform due to the end- to-end protection of the RTP.  The repair mechanism, when used with <del> double, typically operate on the double encrypted data then take the results of theses operations and encrypted them using only the HBH key.  This results in three cryptography operation happening to the repair data sent over the wire. </del>  7.1. When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be <del> encrypted in packet repair mode. </del>  A typical RTX receiver would decrypt the packet, undo the RTX <del> transformation, then process the resulting packet using the normally by using the steps in decrypt. </del>  7.2. When using RED RFC2198 with double, the primary encoding MAY contain RTP header extensions and CSRC identifiers but non primary encodings <del> can not. </del>  <del> The sender takes encrypted payloads from the cached packets to form </del>  the RED payload.  Any header extensions from the primary encoding are <del> copied to the RTP packet that will cary the RED payload and the other RTP header information such as 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 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 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 are used for from the non primary payloads.  The time offset information in the RED data MUST be used to adjust the sequence number in the RTP header by using the timestamp offset and packet rate to find a sequence number offset to adjust by.  At this point the non primary </del>  packets can be decrypted with double. Note that Flex FEC I-D.ietf-payload-flexible-fec-scheme is a superset 7.4. When DTMF is sent with RFC4733, it is end-to-end encrypted and the <del> relay can not read it so it can not be used to control the relay. </del>  Other out of band methods to control the relay need to be used instead. While this document only defines a profile based on AES-GCM, it is possible for future documents to define further profiles with <del> different inner and outer crypto in this same framework.  For </del>  example, if a new SRTP transform was defined that encrypts some or all of the RTP header, it would be reasonable for systems to have the option of using that for the outer algorithm.  Similarly, if a new To summarize what is encrypted and authenticated, we will refer to all the RTP fields except headers created by the sender and before <del> the pay load as the initial envelope and the RTP payload information </del>  with the media as the payload.  Any additional headers added by the sender or Media Distributor are referred to as the extra envelope. <del> The sender uses the end-to-end key to encrypts the payload and authenticate the payload + initial envelope which using an AEAD </del>  cipher results in a slight longer new payload.  Then the sender uses the hop-by-hop key to encrypt the new payload and authenticate the <del> initial envelope extra envelope and the new payload. </del>  The Media Distributor has the hop-by-hop key so it can check the authentication of the received packet across the initial envelope, extra envelope and payload data but it can't decrypt the payload as it does not have the end-to-end key.  It can add or change extra envelope information.  It then authenticates the initial plus extra <del> envelope information plus payload with a hop-by-hop key.  This hop- by-hop for the outgoing packet is typically different than the hop- </del>  by-hop key for the incoming packet. The receiver can check the authentication of the initial and extra envelope information from the Media Distributor.  This, along with <del> the OHB, is used to construct a synthetic packet that is should be identical initial envelope plus payload to one the sender created and the receiver can check that it is identical and then decrypt the original payload. </del>  The end result is that if the authentications succeed, the receiver <del> knows exactly what the payload and initial envelope the sender sent, as well as exactly which modifications were made by the Media Distributor and what extra envelope the Media Distributor send.  The </del>  receive does not know exactly what extra envelope the sender sent. <del> It is obviously critical that the intermediary has only the outer (hop-by-hop) algorithm key and not the half of the key for the the inner (end-to-end) algorithm.  We rely on an external key management protocol to assure this property. </del>  Modifications by the intermediary result in the recipient getting two values for changed parameters (original and modified).  The recipient

NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF

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-  <ins> 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. </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  <ins> decrypt and modify part of the RTP packet but not other parts, </ins> including the media payload. 2. 3.  <ins> This specification uses a cryptographic context with two parts: The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is </ins> AES-GCM.  Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry. 4. The Original Header Block (OHB) contains the original values of any  <ins> modified RTP header fields.  In the encryption process, the OHB is </ins> 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. OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet.  <ins> The OHB has the following syntax (in ABNF RFC5234): </ins> If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively.  The final 5.2. The Media Distributor has the part of the key for the outer (hop-by-  <ins> hop) cryptographic algorithm, but it does not have the part of the key for the (end-to-end) cryptographic algorithm.  The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key. </ins> In order to modify a packet, the Media Distributor decrypts the  <ins> received packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the the outer (hop-by-hop) cryptographic key before transmitting. </ins> 5.3. 6. Unlike RTP, which is encrypted both hop-by-hop and end-to-end using  <ins> two separate cryptographic keys, RTCP is encrypted using only the </ins> outer (hop-by-hop) cryptographic key.  The procedures for RTCP encryption are specified in RFC3711 and this document introduces no additional steps. There are some RTP related extensions that need special consideration to be used by a relay when using the double transform due to the end- to-end protection of the RTP.  The repair mechanism, when used with  <ins> double, typically operates on the double encrypted data and encrypts them using only the HBH key.  This results in three cryptography operation happening to the repair data sent over the wire. </ins> 7.1. When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be  <ins> encrypted the packet in repair mode. </ins> A typical RTX receiver would decrypt the packet, undo the RTX  <ins> transformation, then process the resulting packet normally by using the steps in decrypt. </ins> 7.2. When using RED RFC2198 with double, the primary encoding MAY contain RTP header extensions and CSRC identifiers but non primary encodings  <ins> cannot. </ins>  <ins> The sender takes encrypted payload from the cached packets to form </ins> the RED payload.  Any header extensions from the primary encoding are  <ins> copied to the RTP packet that will carry the RED payload and the other RTP header information such as 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 </ins> packets can be decrypted with double. Note that Flex FEC I-D.ietf-payload-flexible-fec-scheme is a superset 7.4. When DTMF is sent with RFC4733, it is end-to-end encrypted and the  <ins> relay can not read it so it cannot be used to control the relay. </ins> Other out of band methods to control the relay need to be used instead. While this document only defines a profile based on AES-GCM, it is possible for future documents to define further profiles with  <ins> different inner and outer algorithms in this same framework.  For </ins> example, if a new SRTP transform was defined that encrypts some or all of the RTP header, it would be reasonable for systems to have the option of using that for the outer algorithm.  Similarly, if a new To summarize what is encrypted and authenticated, we will refer to all the RTP fields except headers created by the sender and before  <ins> the payload as the initial envelope and the RTP payload information </ins> with the media as the payload.  Any additional headers added by the sender or Media Distributor are referred to as the extra envelope.  <ins> The sender uses the end-to-end key to encrypt the payload and authenticate the payload + initial envelope, which using an AEAD </ins> cipher results in a slight longer new payload.  Then the sender uses the hop-by-hop key to encrypt the new payload and authenticate the  <ins> initial envelope, extra envelope and the new payload. </ins> The Media Distributor has the hop-by-hop key so it can check the authentication of the received packet across the initial envelope, extra envelope and payload data but it can't decrypt the payload as it does not have the end-to-end key.  It can add or change extra envelope information.  It then authenticates the initial plus extra  <ins> envelope information plus payload with a hop-by-hop key.  The hop-by- hop key for the outgoing packet is typically different than the hop- </ins> by-hop key for the incoming packet. The receiver can check the authentication of the initial and extra envelope information from the Media Distributor.  This, along with  <ins> the OHB, is used to construct a synthetic packet which should be identical to the initial envelope plus payload to one the sender created and the receiver can check that it is identical and then decrypt the original payload. </ins> The end result is that if the authentications succeed, the receiver  <ins> knows exactly the payload and initial envelope the sender sent, as well as exactly which modifications were made by the Media Distributor and what extra envelope the Media Distributor sent.  The </ins> receive does not know exactly what extra envelope the sender sent.  <ins> It is obviously critical that the intermediary has access to just the outer (hop-by-hop) algorithm key and not the half of the key for the the inner (end-to-end) algorithm.  We rely on an external key management protocol to ensure this property. </ins> Modifications by the intermediary result in the recipient getting two values for changed parameters (original and modified).  The recipient


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>  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>  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>  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>  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.  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>  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>  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.  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>  conflicts with pre standard versions of EKT that have been deployed.  All new EKT messages MUST be defined to have a length as second from <del> the last element. </del>  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>  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>  [[ 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>  [[ Note to RFC Editor: TBD will be allocated by IANA. ]]

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

Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing  <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.  <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  <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  <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.  <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  <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"  <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  <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.  <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  <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)  <ins> Parameters" registry: </ins> [[ Note to RFC Editor: TBD will be allocated by IANA. ]]


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>  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>  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>  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>  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>  5.3. 7. <del> Media distributors sometimes interact with RTP media packets sent by </del>  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>  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>  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).  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>  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>  9. and outer keys. The protections with regard to the network are the same as with the <del> normal SRTP AES-GCM transforms. </del>  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>  In other words, from the perspective of the MD, re-encrypting packets using this protocol will involve the same cryptographic operations as

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

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  <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  <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  <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  <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  <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.  <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  <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  <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.  <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  <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  <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,  <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


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 <del> SRTP/SRTCP receiver context. </del>  EKT can be used in conferences where the central media distributor or conference bridge cannot decrypt the media, such as the type defined 4.1. The EKTField uses the format defined in tag-format-base for the <del> FullEKTField and ShortEKTField. </del>  The following shows the syntax of the EKTField expressed in ABNF <del> RFC5234.  The EKTField is added to the end of an SRTP or SRTCP packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </del>  These fields and data elements are defined as follows: tag is appended. Rollover Counter (ROC): On the sender side, this is set to the <del> current value of the SRTP rollover counter in the SRTP/SRTCP context associated with the SSRC in the SRTP or SRTCP packet.  The length of this field is 32 bits. </del>  Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing 4.3. <del> At any given time, each SRTP/SRTCP source has associated with it a single EKT parameter set.  This parameter set is used to process all </del>  outbound packets, and is called the outbound parameter set for that SSRC.  There may be other EKT parameter sets that are used by other <del> SRTP/SRTCP sources in the same session, including other SRTP/SRTCP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set).  All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP 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. </del>  Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets.  The decision on which to send when is specified When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created as follows, or uses an equivalent set of <del> steps.  The creation of the EKTField MUST precede the normal SRTP packet processing. </del>  The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload. If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a <del> new FullEKTField.  This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. </del>  4.6. The three cases are:  5. This document defines an extension to DTLS-SRTP called SRTP EKTKey Transport which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client.  This allows <del> those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </del>  In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can

From URL Already fixed on master. I think the idea here is to forbid the use of 0x01, treating it as a reserved value (due to legacy, pre-standard implementations). I think you're looking in the wrong place, actually. There are two levels of constraint here: len(EKTCiphertext) < 256 - len(Epoch) - len(SPI) len(SRTPMasterKey) < len(EKTCiphertext) - len(SSRC) - len(ROC) - len(SRTPMasterKeyLength) - Cipher.Overhead So we can make the following bounds... EKTCiphertext = 1251BYTE ; 255 - 2 - 2 SRTPMasterKey = 1242BYTE ; 251 - 1 - 4 - 4 - Overhead=0 ... but the maximum SRTPMasterKey will never be maximized in practice because the crypto overhead will be non-zero. And we can't really nail it down here in the ABNF because different ciphers will have different overhead. In any case, I have added the above constraints. I agree. In fact, the natural order of operations is to form the SRTP packet, then compute and append the EKT tag. I have made this change. Already fixed on master. I don't think this is unclear, but I have adapted the text to say that the implementation MAY continue normal SRTP/SRTCP processing. I have added a definition in {{EKT}}. Already fixed on master. The word "immediately" appears nowhere here. The sequencing seems clear: Receipt of a new EKTKey should trigger an update to the SRTP Master Key, but you don't start using that for 250ms. I have edited to clarify. I have removed the remaining mentions of SRTCP. Edited to: "it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets" This is covered by the "new receiver" and "rekey" cases. I have left this as-is. As noted above, the statement in §4.5 is not inconsistent. And your notion of "fate sharing" is pretty strict here. The intent is that the keying packets are following the same general path (in terms of media servers, etc.) as the media. It's not a perfect match. I have left this as-is. I don't know the answer on the merits, but it's an application decision anyway. I have added a note that applications will need to decide what latency/bandwidth tradeoff they want to make. On master, this table has been shifted down by one, so this change is no longer needed. Re-sending my initial comments, as only one of the 17 were addressed in subsequent revisions. While no single comment rises to the level of a DISCUSS-worthy issue, several of these are moderately severe. I would appreciate either a response to each comment, or a corresponding change in the document. Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments that I would like to see considered prior to publication of the document. Nit: "...participant to securely..." Shouldn't this be "%x01 / %x03-ff" ? I think this either needs to be "1*255BYTE", or we need text that explicitly indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably the former. I think this is even further constrained by the fact that EKTCiphertext is limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is more appropriate? Why? This seems unnecessary and unnecessarily complicated. If the order of operations has an impact on the bits on the wire (I don't see how it does?), then please include some explanatory text here that clarifies the reason for this constraint. Nit: s/ShortEKFField/ShortEKTField/ I can see implementors easily interpreting this as requiring them to discard the RTP payload as well. If that's not the intention (I don't think it is), consider adding text like "The FullEKTField is removed from the packet then normal SRTP or SRTCP processing occurs." This is the first appearance of the phrase "EKT tag," which never seems to be properly defined. I presume this is meant to be the combination of the EKT Ciphertext and the SPI? In any case, please clearly define this term somewhere, preferably before using it the first time. The parenthetical phrase appears to be missing something here. Nit: "...either... is exceeded..." Nit: "...implementations need..." I suppose it's not terribly important for interop, but the implication that this change takes place immediately seems to contradict the 250 ms period specified in §4.2.1. Perhaps a few words here about how these two normative statements are intended to interact would save implementors a bit of grief. After reading this far, I was quite surprised to find this qualification. If this is the intention for this document, please adjust the rest of the text to match. Some examples follow. Nit: "...containing..." (alternately, remove "be transmitted" -- both make a grammatically correct sentance) More substantially -- under "New sender:", I'm a little surprised that there isn't any mention of other senders re-keying in response to a new sender joining. In the vast majority of conferences, when a sender joins, that same entity generally will also be a receiver. It seems this should trigger other senders to include the key in their next packet. Is this actually true? Going back to the 250 ms period specified in §4.2.1, it seems that the master key is sent out in packets pretty far removed from those it actually protects. Between this and the inconsistency I mention in §4.5 above, this increasingly feels like maybe there were two different ways of reasoning about the timing of sending a master key versus the timing of actually using it. Does the text in §4.2.1 perhaps represent an outdated notion of how this is intended to work? Is this "100ms" correct?  Assuming, say, the use of Opus at voice quality with 20 ms packets, this is taking packets on the order of 40 bytes in length and tacking on something like 20 to 30 bytes to every fifth packet. That's an increase in overall stream size on the order of roughly 15% to 20%. At the same time, when using real-time video, intra frames are going to happen roughly every 500 ms to 1500 ms. If a cadence on that order is okay for audiovisual streams, I have to imagine it's okay for audio streams. So, to clarify: is this "100ms" a typo for "1000 ms"? Section 5.2.1 reserves "0" as well. I suspect we want to replicate that reservation in this table.

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  <ins> SRTP receiver context. </ins> EKT can be used in conferences where the central media distributor or conference bridge cannot decrypt the media, such as the type defined 4.1. The EKTField uses the format defined in tag-format-base for the  <ins> FullEKTField and ShortEKTField.  The EKTField appended to an SRTP packet can be referred to as an "EKT tag". </ins> The following shows the syntax of the EKTField expressed in ABNF  <ins> RFC5234.  The EKTField is added to the end of an SRTP packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </ins> These fields and data elements are defined as follows: tag is appended. Rollover Counter (ROC): On the sender side, this is set to the  <ins> current value of the SRTP rollover counter in the SRTP context associated with the SSRC in the SRTP packet.  The length of this field is 32 bits. </ins> Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing 4.3.  <ins> At any given time, each SRTP source has associated with it a single EKT parameter set.  This parameter set is used to process all </ins> outbound packets, and is called the outbound parameter set for that SSRC.  There may be other EKT parameter sets that are used by other  <ins> SRTP sources in the same session, including other SRTP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set).  All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP 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. </ins> Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets.  The decision on which to send when is specified When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created as follows, or uses an equivalent set of  <ins> steps. </ins> The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload. If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a  <ins> new FullEKTField and eventually begin encrypting with it, as defined in outbound-processing.  This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. </ins> 4.6. The three cases are: <ins> In general, sending EKT tags less frequently will consume less bandwidth, but increase the time it takes for a join or rekey to take effect.  Applications should schedule the sending of EKT tags in a way that makes sense for their bandwidth and latency requirements. </ins> 5. This document defines an extension to DTLS-SRTP called SRTP EKTKey Transport which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client.  This allows  <ins> those peers to process EKT keying material in SRTP and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, 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


DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange <del> draft-ietf-perc-dtls-tunnel-06 </del>  Abstract 1. <del> An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure that endpoints in a multimedia conference have access to the end-to- end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) RFC3550 packets, while the Media Distributor has access only to the hop-by-hop (HBH) keying material for encryption and authentication. </del>  This specification defines a tunneling protocol that enables the media distributor to tunnel DTLS RFC6347 messages between an endpoint aware of the fact that DTLS messages it transmits toward the media distributor are being tunneled to the key distributor. <del> The endpoint MUST include the </del>  <del> DTLS extension I-D.thomson-mmusic-sdp-uks in the </del>  <del> message when establishing a DTLS association.  Likewise, the </del>  <del> SDP RFC4566 attribute MUST be included in SDP sent by the endpoint in both the offer and answer RFC3264 messages as per I-D.ietf-mmusic- dtls-sdp. </del>  When receiving a When sending the <del> message, the key distributor MUST insert its own value in the </del>  extension.  This value MUST also be conveyed back to the client via SDP as a messages for the given endpoint. The key distributor uses the certificate fingerprint of the endpoint <del> along with the value received in the </del>  extension to determine which conference a given DTLS association is associated. message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and <del> DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double. RFC Editor Note: Please replace the values 0009 and 000A in the following two examples with whatever code points IANA assigned for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. </del>  Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:

Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM

DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange  <ins> draft-ietf-perc-dtls-tunnel-07 </ins> Abstract 1.  <ins> An objective of Privacy-Enhanced RTP Conferencing (PERC) RFC8871 is to ensure that endpoints in a multimedia conference have access to the end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) RFC3550 packets, while the Media Distributor has access only to the hop-by- hop (HBH) keying material for encryption and authentication. </ins> This specification defines a tunneling protocol that enables the media distributor to tunnel DTLS RFC6347 messages between an endpoint aware of the fact that DTLS messages it transmits toward the media distributor are being tunneled to the key distributor.  <ins> The endpoint MUST include a unique identifier in the </ins>  <ins> SDP RFC4566 attribute sent by the endpoint in both offer and answer RFC3264 messages as per I-D.ietf-mmusic-dtls-sdp.  Further, the endpoint MUST include this same unique identifier in the </ins>  <ins> DTLS extension I-D.ietf-mmusic-sdp-uks in the </ins>  <ins> message when establishing a DTLS association. </ins> When receiving a When sending the  <ins> message, the key distributor MUST insert its own unique identifier in the </ins> extension.  This value MUST also be conveyed back to the client via SDP as a messages for the given endpoint. The key distributor uses the certificate fingerprint of the endpoint  <ins> along with the unique identifier received in the </ins> extension to determine which conference a given DTLS association is associated. message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and  <ins> DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM RFC8723. </ins> Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:


6.  TODO IANA registry for Message Type  TODO IANA registry EKT ciphers. <del> 6.1. </del>  IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". <del> 6.2. </del>  IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer

Should be in EKTkey not where it is. Should have text that when grt new KEK, need to wait X then start using new SRTP master key

6. <ins> 6.1. </ins> TODO IANA registry for Message Type <ins> 6.2. </ins> TODO IANA registry EKT ciphers.  <ins> 6.3. </ins> IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus".  <ins> 6.4. </ins> IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer


security. Interaction between the Key Distributor and the call processing <del> function may be necessary to for proper conference-to-endpoint mappings, which may or may not be satisfied by getting information directly from the endpoints or via some other means.  See dolist for a related item in the To Do list. </del>  The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys.  See dolist for a related item in the To Do list. </del>  4.4. 5.1. <del> WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </del>  Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor. can be conveyed to endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference.  6. This framework, and the individual protocols defined to support it, 7. <del> 8. </del> There are no IANA considerations for this document. <del> 9. [TBD] 10. </del>  The authors would like to thank Mo Zanaty and Christian Oien for invaluable input on this document.  Also, we would like to

This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG

security. Interaction between the Key Distributor and the call processing  <ins> function is necessary to for proper conference-to-endpoint mappings. This is described in identity. </ins> The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those  <ins> header extensions encrypted with E2E keys. </ins> 4.4. 5.1.  <ins> WebRTC Identity assertion I-D.ietf-rtcweb-security-arch can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </ins> Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor. can be conveyed to endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference. <ins> 5.3. The Key Distributor is responsible for knowing what users are allowed in a given conferences.  When the call setup signalling indicates a session from a particular endpoint and user wishes to join a conferences, the Key Distributor will tell the Media Distributor which conference to place that session in using a globally unique identifier for the conference that is sent, along with the relevant keying information, from the Key Distributor to the Media Distributor. </ins> 6. This framework, and the individual protocols defined to support it, 7.  There are no IANA considerations for this document.  <ins> 8. </ins> The authors would like to thank Mo Zanaty and Christian Oien for invaluable input on this document.  Also, we would like to