Secure Media Frames
charter-ietf-sframe-00-00

Document Proposed charter Secure Media Frames WG (sframe)
Title Secure Media Frames
Last updated 2020-08-29
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Initial chartering
WG State Proposed
IESG Responsible AD Murray Kucherawy
Charter Edit AD Murray Kucherawy
Telechat date (None)
Has 2 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
Send notices to dispatch@ietf.org

Charter
charter-ietf-sframe-00-00

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

Proposed milestones

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