Original text:
Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function used for key derivation and hashing signature inputs </del>  o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag <del> o [Optional] A signature algorithm </del> This document defines the following ciphersuites: In the "AES" suites, the length of the authentication tag is 5. SFrame must be integrated with an E2E key management framework to <del> exchange and rotate the keys used for SFrame encryption and/or signing.  The key management framework provides the following functions: </del>  Provisioning KID/"base_key" mappings to participating clients <del> (optional) Provisioning clients with a list of trusted signing keys </del> Updating the above data as clients join or leave It is up to the application to define a rotation schedule for keys. If the participants in a call have a pre-existing E2E-secure channel, they can use it to distribute SFrame keys.  Each client participating <del> in a call generates a fresh encryption key and optionally a signing key pair.  The client then uses the E2E-secure channel to send their encryption key and signing public key to the other participants. </del>  In this scheme, it is assumed that receivers have a signal outside of SFrame for which client has sent a given frame, for example the RTP out-of-order delivery, but should be deleted promptly. If a new participant joins mid-call, they will need to receive from <del> each sender (a) the current sender key for that sender, (b) the signing key for the sender, if used, and (c) the current KID value for the sender.  Evicting a participant requires each sender to send a fresh sender key to all receivers. </del>  5.2. and "sender_base_key" values on demand, as it needs to encrypt/ decrypt for a given member. <del> MLS also provides an authenticated signing key pair for each participant.  When SFrame uses signatures, these are the keys used to generate SFrame signatures. </del> 6. 6.1. receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another <del> participant's media.  Note that in order to prevent impersonation by a malicious participant (not the SFU) usage of the signature is required.  In case of video, the a new signature should be started each time a key frame is sent to allow the receiver to identify the source faster after a switch. </del>  6.1.2.

Reviewer comments:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?

Revised text:
Each SFrame session uses a single ciphersuite that specifies the following primitives:  <ins> o A hash function used for key derivation </ins> o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag  This document defines the following ciphersuites: In the "AES" suites, the length of the authentication tag is 5. SFrame must be integrated with an E2E key management framework to  <ins> exchange and rotate the keys used for SFrame encryption.  The key management framework provides the following functions: </ins> Provisioning KID/"base_key" mappings to participating clients  Updating the above data as clients join or leave It is up to the application to define a rotation schedule for keys. If the participants in a call have a pre-existing E2E-secure channel, they can use it to distribute SFrame keys.  Each client participating  <ins> in a call generates a fresh encryption key.  The client then uses the E2E-secure channel to send their encryption key to the other participants. </ins> In this scheme, it is assumed that receivers have a signal outside of SFrame for which client has sent a given frame, for example the RTP out-of-order delivery, but should be deleted promptly. If a new participant joins mid-call, they will need to receive from  <ins> each sender (a) the current sender key for that sender and (b) the current KID value for the sender.  Evicting a participant requires each sender to send a fresh sender key to all receivers. </ins> 5.2. and "sender_base_key" values on demand, as it needs to encrypt/ decrypt for a given member.  6. 6.1. receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another  <ins> participant's media. Note that in order to prevent impersonation by a malicious participant (not the SFU), a mechanism based on digital signature would be required.  SFrame does not protect against such attacks. </ins> 6.1.2.