Secure Media Frames (sframe) Proposed WG
|WG||Name||Secure Media Frames|
|Area||Applications and Real-Time Area (art)|
|Charter||charter-ietf-sframe-00-00 Start Chartering/Rechartering (Internal Steering Group/IAB Review)|
|Dependencies||Document dependency graph (SVG)|
|Jabber chat||Room address||xmpp:email@example.com?join|
Charter for proposed Working Group
Real-time conferencing sessions increasingly require end-to-end protections that prevent intermediary servers from decrypting real-time media. The PERC WG developed a “double encryption” scheme for end-to-end encryption that was deeply tied to SRTP as its underlying transport. This entanglement has prevented widespread deployment.
This working group will define the SFrame secure encapsulation for real-time media content that is independent of the underlying transport. The encapsulation will provide:
* Selection among multiple encryption keys in use during a real-time session
* Information to form a unique nonce within the scope of the key
* Authenticated encryption using the selected key and nonce
The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models.
The transport-independence of this encapsulation means that it can be applied at a higher level than individual RTP payloads. For example, it may be desirable to encrypt whole frames that span multiple packets in order to amortize the overhead from framing and authentication tags. It may also be desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable. The working group will choose what levels of granularity are available and to what degree this can be configured.
This working group will not specify the signaling required to configure SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. This working group will, however, define how SFrame interacts with RTP (e.g., with regard to packetization, depacketization, and recovery algorithms) to ensure that it can be used in environments such as WebRTC.
It is anticipated that several use cases of SFrame will involve its use with keys derived from the MLS group key exchange protocol. The working group will define a mechanism for doing SFrame encryption using keys from MLS, including, for example, the derivation of SFrame keys per MLS epoch and per sender.
Submit SFrame specification to IESG (Standards Track)