[Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-00: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
charter-ietf-sframe-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-sframe/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?