Secure Media Frames (sframe) Proposed WG

WG Name Secure Media Frames
Acronym sframe
Area Applications and Real-Time Area (art)
State Proposed
Charter charter-ietf-sframe-00-00 Start Chartering/Rechartering (Internal Steering Group/IAB Review)
Dependencies Document dependency graph (SVG)
Personnel Area Director Murray Kucherawy 
Mailing list Address sframe@ietf.org
To subscribe
Archive
Jabber chat Room address xmpp:sframe@jabber.ietf.org?join
Logs https://jabber.ietf.org/logs/sframe/

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.

Proposed milestones

Date Milestone
1 Jun 2021 Submit SFrame specification to IESG (Standards Track)
draft-omara-sframe