Draft: draft-omara-sframe

Commentary: Mostly cleanup and reordering to largely match the SRTP document 's structure .
This document describes a new end to end encryption and
authentication schema for WebRTC media frames in a multiparty
conference call where the central media server (SFU) will have access
to the needed metadata in order for it work without getting access
the encrypted media.  This proposal uses the entire media frame
instead of individual RTP packet as the encryptable unit to decrease
the encryption overhead.
This document describes the Secure Frame (SFrame) end-to-end
encryption and authentication mechanism for media frames in a
multiparty conference call, in which central media servers (SFUs) can
access the media metadata needed to make forwarding decisions without
having access to the actual media.  The proposed mechanism differs
from other approaches through its use of media frames as the
encryptable unit, instead of individual RTP packets, which makes it
more bandwidth efficient and also allows use with non-RTP transports.
Modern multi-party video call systems use Selective Forwarding Unit
(SFU) servers to efficiently route RTP streams to call endpoints
based on factors such as available bandwidth, desired video size,
codec support, and other factors.  In order for the SFU to work
properly though, it needs to be able to access RTP metadata and RTCP
feedback messages, which is not possible if all RTP/RTCP traffic is
end-to-end encrypted.
This document proposes a new end-to-end encryption mechanism known as
SFrame, specifically designed to work in group conference calls with
SFUs.
1- Provide an E2EE mechanism for video conference with low overhead.
2- Decouple the media encryption from the key management and allows
to be used with different KMS.
3- Easy to implement in the clients.
4- Minimize the changes needed in the SFU servers.
Modern multi-party video call systems use Selective Forwarding Unit
(SFU) servers to efficiently route RTP streams to call endpoints
based on factors such as available bandwidth, desired video size,
codec support, and other factors.  In order for the SFU to work
properly though, it needs to be able to access RTP data, which is not
possible if the entire RTP packets are end- to-end encrypted and
authenticated.
We propose a frame level encryption mechanism that provides effective
end-to-end encryption, is simple to implement, has no dependencies on
RTP, and minimizes encryption bandwidth overhead.  Because SFrame
encrypts the full frame, rather than packet basis, bandwidth overhead
is reduced by having a single IV and authentication tag for each
media frame.
Also, because media is encrypted prior to packetization, the
encrypted frame is packetized using a generic RTP packetizer instead
of codec-dependent packetization mechanisms.  With this move to a
generic packetizer, media metadata is moved from codec-specific
mechanisms to a generic frame RTP header extension which, while
visible to the SFU, is authenticated end-to- end.  This extension
includes necessary metadata such as resolution, frame beginning and
end markers, etc.
Provide an secure E2EE mechanism for audio and video in conference
calls that can be used with arbitrary SFU servers.
Decouple media encryption from key management to allow SFrame to
be used with an arbitrary KMS.
Minimize packet expansion to allow successful conferencing in as
many network conditions as possible.
Independence from the underlying transport, including use in non-
RTP transports, e.g., WebTransport.
When used with RTP and its associated error resilience mechanisms,
i.e., RTX and FEC, require no special handling for RTX and FEC
packets.
Minimize the changes needed in SFU servers.
Minimize the changes needed in endpoints.
Work with the most popular audio and video codecs used in
conferencing scenarios.
We propose a frame level encryption mechanism that provides effective
end-to-end encryption, is simple to implement, has no dependencies on
RTP, and minimizes encryption bandwidth overhead.  Because SFrame
encrypts the full frame, rather than individual packets, bandwidth
overhead is reduced by having a single IV and authentication tag for
each media frame.
Also, because media is encrypted prior to packetization, the
encrypted frame is packetized using a generic RTP packetizer instead
of codec-dependent packetization mechanisms.  With this move to a
generic packetizer, media metadata is moved from codec-specific
mechanisms to a generic frame RTP header extension which, while
visible to the SFU, is authenticated end-to-end.  This extension
includes metadata needed for SFU routing such as resolution, frame
beginning and end markers, etc.
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.
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 monotonically
increasing to avoid IV reuse.
Signature flag (S): 1 bit This field indicates the payload contains a
signature if set.  Counter Length (LEN): 3 bits This field indicates
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.
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.
Signature flag (S): 1 bit This field indicates the payload contains a
signature if set.  Counter Length (LEN): 3 bits This field indicates
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.
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.