Draft: draft-omara-sframe

Commentary: 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
"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).
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.
After encoding the frame and before packetizing it, the necessary
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
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.
The encrypted payload is then passed to a generic RTP packetized to
construct the RTP packets and encrypts it using SRTP keys for the HBH
encryption to the media server.
After encoding the frame and before packetizing it, the necessary
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
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.
The encrypted payload is then passed to a generic RTP packetized to
construct the RTP packets and encrypt it using SRTP keys for the HBH
encryption to the media server.
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
it to Frame for decryption.  SFrame maintains multiple decryptor
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
passes the authentication verification and use it to decrypt the
frame.  If the client has the mapping ready, it can push it down to
SFrame later.
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
it to SFrame for decryption.  SFrame maintains multiple decryptor
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
passes the authentication verification and use it to decrypt the
frame.  If the client has the mapping ready, it can push it down to
SFrame later.
o A hash function This is used for the Key derivation and frame
hashes for signature.  We recommend using SHA256 hash function.
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.
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.
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.
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.
While any other E2EE KMS can be used with SFrame, there is a big
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.
While any other E2EE KMS can be used with SFrame, there is a big
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.
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/
SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't
use the OHB anymore, however it still does per packet encryption
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.
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/
SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't
use the OHB anymore, however it still does per packet encryption
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.