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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 16:31:01 -0700

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?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 Sep 2020 09:56:42 -0400

Hi Ben,

See inline.

> I thought we were going to tweak this text (noting that RFC RFC 8723 is

Given the speed of the RFC process vs. the speed of deployment these days,
successful things succeed before RFC.

> hierarchy (e.g., one key per sender vs. full mesh).

I don't think we have an expected shape.  In practice, it will always be
per-sender keys.  But that's not an assumption we should bake in.

If you want an IETF precedent, the right analogy would be something like
CMS AuthEnvelopedData [https://tools.ietf.org/html/rfc5083].  Except that
SFrame (a) wouldn't do the asymmetric-encrypt-the-key part, and (b) would
optimize down the encoding to be suitable for real-time.

> I assume that this means "assembling preexisting crypto building blocks",

Correct.  It means "send the ciphertext".  I think we can probably delete
this bullet.

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

Available in the output of the WG.  That is, there's a granularity
configuration parameter that we might want in the protocol, and it's up to
the WG to decide whether the parameter exists, and if so, what settings it
has.

    It is anticipated that several use cases of SFrame will involve its use
> with

Absolutely!  The default case is manual / unspecified keying (again, just
like with the CMS case above).  This paragraph just says that *in addition
to that*, the WG will specify how it works with MLS.

--Richard

>
>
>
> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>