Change:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos

Discussion:
the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. <del> Key or Key Length: 3 bits This field containts the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </del> <ins> Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </ins> If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes:

Adding a digital signature to each encrypted frame will be an overkill, instead we propose adding signature over multiple frames. <del> The signature is calculated by contatenating the authentication tags </del> <ins> The signature is calculated by concatenating the authentication tags </ins> of the frames that the sender wants to authenticate (in reverse sent order) and signing it with the signature key.  Signature keys are exchanged out of band along the secret keys.

The receiver has to keep track of all the frames received but yet not verified, by storing the authentication tags of each received frame. <del> When a signature is received, the reciever will verify it with the signature key associated to the key id of the frame the singature was sent in.  If the verification is sucessful, the received will mark </del> <ins> When a signature is received, the receiver will verify it with the signature key associated to the key id of the frame the signature was sent in.  If the verification is successful, the received will mark </ins> the frames as authenticated and remove them from the list of the not verified frames.  It is up to the application to decide what to do when signature verification fails.

graph and send multiple signatures in parallel (each for a branch of the dependency graph). <del> In case of simulcast or K-SVC, each spatial layer sould be </del> <ins> In case of simulcast or K-SVC, each spatial layer should be </ins> authenticated with different signatures to prevent the SFU to discard frames with the signature info.

following primitives: o A hash function This is used for the Key derivation and frame <del> hashes for signture.  We recommend using SHA256 hash function. </del> <ins> hashes for signature.  We recommend using SHA256 hash function. </ins> o An AEAD encryption algorithm [RFC5116] While any AEAD algorithm can be used to encrypt the frame, we recommend using algorithms with safe

4. SFrame must be integrated with an E2EE key management framework to <del> exchange and rotate the encryption keys such as MLSPROTO which scales to very large groups.  Call members will create a MLS group to exchange the encryption keys for all further calls for that group. When a client joins the call, they create a random key material and encrypt it to every other client on the call using their MLS application secret.  This key material is passed to SFrame to derive SFrame keys for that client.  When group membership changes, the active clients in the call must update their keys for "Forward Secrecy" and "Post Compromise Security".  Key ratcheting can be used when a new member joins the group but for member leave events, a fresh key material will be generated by each client endpoint in the call and encrypt it using their MLS application secret. If authentication is enabled, every client will also generate public- private key pair for signing and exchange the public part with the secret key material. </del> <ins> exchange and rotate the encryption keys.  This framework will maintain a group of participant endpoints who are in the call.  At call setup time, each endpoint will create a fresh key material and optionally signing key pair for that call and encrypt them to every other endpoints.  They encrypted keys are delivered by the messaging delivery server using a reliable channel. The key management framework will monitor the group changes, and exchange new keys when necessary.  It is up to the application to define this group, for example one application could have ephemeral group for every call and keep rotating key when end points joins or leave the call, while another app could have a persisted group that can be used for multiple calls and exchange keys with all group endpoints for every call. When a new key material is created during the call, we recommend not to start using it immediately in SFrame to give time for the new keys to be delivered.  If the application supports delivery receipts, it can be used to track if the key is delivered to all other endpoints on the call before using it. Keys must have a sequential id starting from 0 and incremented eery time a new key is generated for this endpoint.  The key id will be added in the SFrame header during encryption, so the recipient know which key to use for the decryption. 4.1. While any other E2EE key management framework can be used with SFrame, there is a big advantage if it is used with MLSARCH which supports group natively and can support very large groups an efficiently.  When MLSPROTO is used, the endpoints keys (AKA Application secret) can be used directly for SFrame without the need to exchange separate key material.  The application secret is rotated automatically by MLSPROTO when group membership changes. </ins> 5.

5.1.2. When using simulcast, the same input image will produce N different <del> encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter </del> <ins> encoded frames (one per simulcast layer) which would be processed independently by the frame encryptor and assigned an unique counter </ins> for each. 5.1.3.