Original text:
3.1.  Since each endpoint can send multiple media layers, each frame will have a unique frame counter that will be used to derive the encryption IV.  The frame counter must be unique and monodically (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. <del> 3.2. </del>  <del> 3.2.1. </del>  Each client creates a 32 bytes secret key K and share it with with other participants via an E2EE channel.  From K, we derive 3 secrets: The IV is 128 bits long and calculated from the CTR field of the Frame header: <del> 3.2.2. 3.2.2.1. SFrame supports two ciphers, the only difference is the length of the authentication tag, where 10 bytes is used for video and 4 bytes for audio 1- AES_CM_128_HMAC_SHA256_80 2- AES_CM_128_HMAC_SHA256_32 It uses AES counter mode for encryption with 128 bit key, SHA256 hash for the HKDF key derivation. 3.2.2.2. SRTP is used as an outer encryption, since the media payload is already encrypted, and SRTP only protects the RTP headers, one implementation could use 4 bytes outer auth tag to decrease the overhead, however it is up to the application to use other ciphers like AES-128-GCM with full authentication tag. It is possible that future versions of this draft will define other ciphers. 3.2.3. </del>  After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be construct the RTP packets and encrypts it using SRTP keys for the outer encryption to the media server. <del> 3.2.4. </del>  The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP the client has the mapping ready, it can push it down to SFrame later.  For frames that are failed to decrypt because there is not key available yet, SFrame will buffer them and retries to decrypt them once a key is received. <del> 3.2.5. </del>  Unlike messaging application, in video calls, receiving a duplicate frame doesn't necessary mean the client is under a replay attack, there are other reasons that might cause this, for example the sender might just be sending them in case of packet loss.  SFrame decryptors <del> use the last received frame counter to protect against this.  It </del>  allows only older frame pithing a short interval to support out of order delivery. <del> 3.2.6. </del>  Because the E2EE keys could be rotated during the call when people join and leave, these new keys are exchanged using the same E2EE hash ratcheting for the join case, so no need to send a new key to the clients who are already on the call.  SFrame supports both modes <del> 3.2.6.1. </del>  When SFrame decryptor fails to decrypt one of the frames, it automatically ratchets the key forward and retries again until one If a new ratchet passed the decryption, all previous ratchets are deleted. <del> 3.2.6.2. </del>  Frame will set the key immediately on the decrypts when it is received and destroys the old key material, so if the key manager decryption failure.  It is up to the application and the key manager to define how long this period is. <del> 3.3. </del>  Every client in the call knows the secret key for all other clients so it can decrypt their traffic, it means a malicious client can The signature keys are exchanged out of band along the secret keys.  4. SFrame must be integrated with an E2EE key management framework to

Reviewer comments:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section

Revised text:
3.1. <ins> 3.2. </ins> Since each endpoint can send multiple media layers, each frame will have a unique frame counter that will be used to derive the encryption IV.  The frame counter must be unique and monodically (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long.  <ins> 3.3. </ins>  <ins> 3.3.1. </ins> Each client creates a 32 bytes secret key K and share it with with other participants via an E2EE channel.  From K, we derive 3 secrets: The IV is 128 bits long and calculated from the CTR field of the Frame header:  <ins> 3.3.2. </ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be construct the RTP packets and encrypts it using SRTP keys for the outer encryption to the media server.  <ins> 3.3.3. </ins> The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP the client has the mapping ready, it can push it down to SFrame later. <ins> The KeyId field in the SFrame header is used to find the right key for that user, which is incremented by the sender when they change to a new key. </ins> For frames that are failed to decrypt because there is not key available yet, SFrame will buffer them and retries to decrypt them once a key is received.  <ins> 3.3.4. </ins> Unlike messaging application, in video calls, receiving a duplicate frame doesn't necessary mean the client is under a replay attack, there are other reasons that might cause this, for example the sender might just be sending them in case of packet loss.  SFrame decryptors  <ins> use the highest received frame counter to protect against this.  It </ins> allows only older frame pithing a short interval to support out of order delivery.  <ins> 3.3.5. </ins> Because the E2EE keys could be rotated during the call when people join and leave, these new keys are exchanged using the same E2EE hash ratcheting for the join case, so no need to send a new key to the clients who are already on the call.  SFrame supports both modes  <ins> 3.3.5.1. </ins> When SFrame decryptor fails to decrypt one of the frames, it automatically ratchets the key forward and retries again until one If a new ratchet passed the decryption, all previous ratchets are deleted.  <ins> 3.3.5.2. </ins> Frame will set the key immediately on the decrypts when it is received and destroys the old key material, so if the key manager decryption failure.  It is up to the application and the key manager to define how long this period is.  <ins> 3.4. </ins> Every client in the call knows the secret key for all other clients so it can decrypt their traffic, it means a malicious client can The signature keys are exchanged out of band along the secret keys. <ins> 3.5. 3.5.1. Each SFrame session uses a single ciphersuite that specifies the following primitives: o A hash function This is used for the Key derivation and frame hashes for signture.  We recommend using SHA256 hash function. o An AEAD encryption algorithm [RFC5116] While any AEAD algorithm can be used to encrypt the frame, we recommend using algorithms with safe MAC truncation like AES-CTR and HMAC to reduce the per-frame overhead.  In this case we can use 80 bits MAC for video frames and 32 bits for audio frames similar to DTLS-SRTP cipher suites: 1- AES_CM_128_HMAC_SHA256_80 2- AES_CM_128_HMAC_SHA256_32 o [Optional] A signature algorithm If signature is supported, we recommend using ed25519 3.5.2. SRTP is used as an outer encryption, since the media payload is already encrypted, and SRTP only protects the RTP headers, one implementation could use 4 bytes outer auth tag to decrease the overhead, however it is up to the application to use other ciphers like AES-128-GCM with full authentication tag. It is possible that future versions of this draft will define other ciphers. </ins> 4. SFrame must be integrated with an E2EE key management framework to