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

Discussion:
DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange <del> draft-ietf-perc-dtls-tunnel-06 </del> <ins> draft-ietf-perc-dtls-tunnel-07 </ins> 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> <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. <del> The endpoint MUST include the </del> <ins> The endpoint MUST include a unique identifier in the </ins> <del> DTLS extension I-D.thomson-mmusic-sdp-uks in the </del> <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> <del> message when establishing a DTLS association.  Likewise, the </del> <ins> DTLS extension I-D.ietf-mmusic-sdp-uks in the </ins> <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> <ins> message when establishing a DTLS association. </ins> When receiving a

When sending the <del> message, the key distributor MUST insert its own value in the </del> <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 <del> along with the value received in the </del> <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 <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> <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: