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

[Richard Barnes <[e-mail]>]

Hi Ben,

See inline.

On Wed, Sep 9, 2020 at 7:31 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

>     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).
>

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


> 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).
>

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.



>     * 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".
>

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



>     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?)
>

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
>     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?
>

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>