Change:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on

Discussion:
end-to-end encrypted. As such, two layers of encryptions and authentication are required: <del> 1- Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU 2- End-to-end (E2E) encryption of media between the endpoints </del> <ins> Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU End-to-end (E2E) encryption of media between the endpoints </ins> While DTLS-SRTP can be used as an efficient HBH mechanism, it is inherently point-to-point and therefore not suitable for a SFU

4.3. <ins> SFrame encryption uses an AEAD encryption algorithm and hash function defined by the ciphersuite in use (see ciphersuites).  We will refer to the following aspects of the AEAD algorithm below: "AEAD.Encrypt" and "AEAD.Decrypt" - The encryption and decryption functions for the AEAD.  We follow the convention of RFC 5116 RFC5116 and consider the authentication tag part of the ciphertext produced by "AEAD.Encrypt" (as opposed to a separate field as in SRTP RFC3711). "AEAD.Nk" - The size of a key for the encryption algorithm, in bytes "AEAD.Nn" - The size of a nonce for the encryption algorithm, in bytes </ins> 4.3.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: </del> <ins> Each client creates a secret key "base_key" and shares it with the other participants via an E2E secure channel.  From "base_key", we derive the following values using HKDF RFC5869: </ins> <del> 1- Salt key used to calculate the IV </del> <ins> A Salt key used to calculate the IV </ins> <del> 2- Encryption key to encrypt the media frame </del> <ins> An encryption key to encrypt the media frame </ins> <del> 3- Authentication key to authenticate the encrypted frame and the media metadata </del> <ins> An authentication key to authenticate the encrypted frame and the media metadata </ins> <del> The IV is 128 bits long and calculated from the CTR field of the Frame header.  First the var int CTR is decoded into 16 bytes long field, where CTR fills the the 8 most significant bytes and low 8 bytes are always filled with zeros: </del> <ins> Each SFrame KID value identifies a "base_key", and thus both the "sframe_secret" and "sframe_salt" values to be used for encryption and decryption. </ins> 4.3.2.

media metadata will be moved out of the encoded frame buffer, to be used later in the RTP generic frame header extension.  The encoded frame, the metadata buffer and the frame counter are passed to SFrame <del> encryptor.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame, the media metadata and the header are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> encryptor. SFrame encryption uses the AEAD encryption algorithm for the ciphersuite in use.  The key for the encryption is the "sframe_key" and the nonce is formed by XORing the "sframe_salt" with the current counter, encoded as a big-endian integer of length "AEAD.Nn". The encryptor forms an SFrame header using the S, CTR, and KID values provided.  The encoded header is provided as AAD to the AEAD encryption operation, with any frame metadata appended. </ins> The encrypted payload is then passed to a generic RTP packetized to <del> construct the RTP packets and encrypts it using SRTP keys for the HBH </del> <ins> construct the RTP packets and encrypt it using SRTP keys for the HBH </ins> encryption to the media server. 4.3.3.

The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP frame header extension, and once all packets are available, it passes <del> it to Frame for decryption.  SFrame maintains multiple decryptor </del> <ins> it to SFrame for decryption.  SFrame maintains multiple decryptor </ins> objects, one for each client in the call.  Initially the client might not have the mapping between the incoming streams the user's keys, in this case SFrame tries all unmapped keys until it finds one that

4.5. <del> 4.5.1. </del> Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function This is used for the Key derivation and frame hashes for signature.  We recommend using SHA256 hash function. </del> <ins> o A hash function used for key derivation and hashing signature inputs o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </ins> <del> 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: </del> <ins> o [Optional] A signature algorithm </ins> <del> 1- AES_CM_128_HMAC_SHA256_80 </del> <ins> This document defines the following ciphersuites: </ins> <del> 2- AES_CM_128_HMAC_SHA256_32 </del> <ins> In the "AES_CM" suites, the length of the authentication tag is indicated by the last value: "_8" indicates an eight-byte tag and "_4" indicates a four-byte tag. In a session that uses multiple media streams, different ciphersuites might be configured for different media streams.  For example, in order to conserve bandwidth, a session might use a ciphersuite with 80-bit tags for video frames and another ciphersuite with 32-bit tags for audio frames. 4.5.1. </ins> <del> o [Optional] A signature algorithm If signature is supported, we recommend using ed25519 </del> <ins> In order to allow very short tag sizes, we define a synthetic AEAD function using the authenticated counter mode of AES together with HMAC for authentication.  We use an encrypt-then-MAC approach as in SRTP RFC3711. </ins> <del> 4.5.2. </del> <ins> Before encryption or decryption, encryption and authentication subkeys are derived from the single AEAD key using HKDF.  The subkeys are derived as follows, where "Nk" represents the key size for the AES block cipher in use and "Nh" represents the output size of the hash function: </ins> <del> SRTP is used as an HBH 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. </del> <ins> The AEAD encryption and decryption functions are then composed of individual calls to the CM encrypt function and HMAC.  The resulting MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite. </ins> 5.

5.1. While any other E2EE KMS can be used with SFrame, there is a big <del> advantage if it is used with MLSARCH which natively supports very large groups 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. </del> <ins> advantage if it is used with I-D.ietf-mls-architecture which natively supports very large groups efficiently.  When I-D.ietf-mls-protocol 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 I- D.ietf-mls-protocol when group membership changes. </ins> 6.

7.3. <del> PERC has significant overhead over SFrame because the overhead is per packet, not per frame, and OHB (Original Header Block) which duplicates any RTP header/extension field modified by the SFU. PERCLITE <https://mailarchive.ietf.org/arch/msg/perc/ </del> <ins> RFC8723 has significant overhead over SFrame because the overhead is per packet, not per frame, and OHB (Original Header Block) which duplicates any RTP header/extension field modified by the SFU.  I- D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/ </ins> SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't use the OHB anymore, however it still does per packet encryption <del> using SRTP.  Below the the overheard in PERCLITE implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition to the extra MAC tag per packet. </del> <ins> using SRTP.  Below the the overheard in I-D.murillo-perc-lite implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition to the extra MAC tag per packet. </ins> OverheadPerPacket = 11 + MAC length Overhead bps = PacketPerSecond * OverHeadPerPacket * 8 Similar to SFrame, we will assume the HBH authentication tag length will always be 4 bytes for audio and video even though it is not the <del> case in this PERCLITE implementation </del> <ins> case in this I-D.murillo-perc-lite implementation </ins> 7.3.1.