Draft: draft-omara-sframe

Commentary: Change frame counter to be a global counter Add section to Key management and reference MLS clarify the SFrame keys are per sender
We propose a frame level encryption schema for the E2EE layer to
decrease the overhead by having a single IV and authentication tag
per the media frame and not per RTP packet, and the encrypted frame
will be packetized using a generic RTP packetized and not codec
dependent packetized anymore.  In order for SFU to work, media
metadata will be moved to a generic frame RTP header extension which
will be authenticated end to end.  This extensions will include
metadata such as resolution, frame rate, frame begin and end marks,
etc.
We propose to add second layer of encryption using keys only known to
the client endpoints and negotiated through an E2EE channel.  Each
client endpoint uses a different symmetric key to encrypt their
outgoing traffic.  The new encryption is done at the frame level
instead of packet level to decrease the overhead by having a single
IV and authentication tag per the media frame and not per RTP packet,
and the encrypted frame will be packetized using a generic RTP
packetized and not codec dependent packetized anymore.  In order for
SFU to work, media metadata will be moved to a generic frame RTP
header extension which will be authenticated end to end.  This
extensions will include metadata such as resolution, frame rate,
frame begin and end marks, etc.
Since each endpoint can send multiple media layers, each stream will
have a unique frame counter that will be used to derive the
encryption IV.  To guarantee uniqueness across all streams and avoid
IV reuse, the frame counter will have be prefixed by a stream id
which will be 0 to N where N is the total number of outgoing streams.
The expected number of outgoing streams will be between 4 and 9
streams, using 4 bits for stream id will support up to 16 streams.
S 1 bit Signature flag, indicates the payload contains a signature of
set.
LEN (3 bits) The CTR length fields in bytes.
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
increasing to avoid IV reuse.
The first byte in the header is fixed and contains the header
metadata S 1 bit Signature flag, indicates the payload contains a
signature of set.
LEN (3 bits) The length of the CTR fields in bytes.
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
keeps track of all received frame ids for each incoming stream and
returns and error when it detects a duplicate frame.
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
use the last received frame counter to protect against this.  It
allows only older frame pithing a short interval to support out of
order delivery.
SFrame must be integrated with an E2EE key management framework to
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.
PERC <https://datatracker.ietf.org/doc/rfc8723/> has significant
overhead over SFrame because the overhead is per packet, not per
frame, and OHB which duplicates any RTP header/extension field
modified by the SFU.  PERC-Lite 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 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.
PERC has significant overhead over SFrame because the overhead is per
packet, not per frame, and OHB which duplicates any RTP header/
extension field modified by the SFU.  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 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.