Original text:
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

Reviewer comments:
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.

Revised text:
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