Secure Media Frames
charter-ietf-sframe-01

[[ comments/questions ]]

* Agree with "Information to form a unique nonce within the scope of the key"
  seeming a bit underdefined at the moment.

* If conferencing migrates to carriage over QUIC, would that have any
  impact on/overlap with this work?

** I share Éric Vyncke concerns with the bulleted list of what SFRAME encapsulation will provide.  My recommendation would be to reframe this text around what security properties/assurances/services this encapsulation will provide (rather than a functional list).

** If configuring the security services is out of scope, where is it anticipated that this signalling protocol work would occur?

Still not too happy with some previous DISCUSS points of mine, notably:
- 'This working group will not specify the signaling required to configure SFrame encryption", it is unclear to me whether the WG will specify a control channel to negotiate keys and crypto algorithms as the current sentence appears more generic configuration (e.g., supported crypto algorithms)

I support Magnus's and Érics' Blocks.

Some additional comments:

    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.

I thought we were going to tweak this text (noting that RFC RFC 8723 is only a
handful of months old).

It might also be worth a note about the general expected shape of the key
hierarchy (e.g., one key per sender vs. full mesh).

    * 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

I assume that this means "assembling preexisting crypto building blocks", not
"define new crypto".

    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.

(Available as input to the WG of available from its output?)

    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.

Will other sources of key material be considered?

Thanks, this update address my significant issues with the charter. 

I think the charter might be giving a slightly skewed image of the granularity question. To my understanding the application data units (ADU) combined with SFRAMEs properties and the underlying transport will in combination define what granularity that are practical to accomplish. As an example an RTP payload format for SFRAMEs that would support multiple SFRAME objects for a set of ADUs belonging to the same video frame would provide great flexibility in how many SFRAMEs the ADUs are protected in. If each ADU is split into multiple SFRAMES that could be supported but maybe unnecessary as the codec likely are unable to process sub-ADUs, at the same time putting multiple ADUs into one SFRAME requires a seperation to exist above SFRAMEs. This type of questions will be application specific and dependent on underlying layers where to support which functionality. I have the impression that the proponents for SFRAME have a desire to have minimal support for this in SFRAME and rather rely on how the application and the transport is capable of applying SFRAMEs to achieve its confidentiality goals.

This may come up in the context of the document reviews, but given the recent discussions on terminology we may want to proactively avoid use of the term 'nonce' in the WG charter.