Re: [Sframe] MLS Integration Question

[Richard Barnes <[e-mail]>]

Hi Joël,

(Accidentally sent this unicast, retransmitting to the list)

Glad this is looking useful to you, and thanks for the nudge to make some
updates to the document.

1. The problem you describe is definitely real.  In addition to A/V, there
are things like endpoints with multiple cameras that don't share state.  I
wrote up the solution that we're using in Webex, which is basically what
you suggest -- stealing a few more bits of KID to indicate the context
within the sender.  Unfortunately, I apparently forgot that we had moved
the MLS keying into the main spec, so I only wrote up the solution in the
separate predecessor document:

https://github.com/bifurcation/sframe-mls/blob/main/draft-barnes-sframe-mls.md#multiple-sender-contexts

If that looks good to you, let's work on getting it ported over to
draft-ietf-sframe-enc.

2. This situation seems a little different from the MLS reuse_guard
situation, since it depends on whether MLS group memberships persist across
restarts.  In a system where MLS joins/leaves correspond to meeting
joins/leaves, this is not an issue, because if the client crashes, then it
will rejoin the group, and thus have a different base key.  So your issue
would only come up in a case where MLS state was preserved across restarts,
but the CTR state was lost/corrupted.  (Right?)  In any case, it seems this
is something an implementation could do using the context value discussed
above -- generate a different context / set of contexts every time you
restart.  Maybe we could add a recommendation, but it seems like the
application-defined context ID gives the application the tools it needs.

3. The main reason for the current design is API cleanliness -- you just
export an SFrame key once when the epoch changes and generate the remaining
keys internal to the SFrame library, instead of having interaction between
the SFrame and MLS layers each time SFrame needs a new key.

Hope that helps,
--Richard

On Thu, Jan 19, 2023 at 11:25 AM Alwen, Joel <alwenjo=
[e-mail]> wrote:

>  _Hey everyone,
>
>
> As Marta Mularczyk and I have been looking at using MLS to key SFrame
> we came across the following two questions/suggestions for the SFrame
> mailinglist.
>
>
> 1) Section 5.2 recommends how KIDs can be defined when using MLS as the
> key source. It domain separates between (epoch, leaf) pairs which is good.
> But by "only" domain separating on this it seems to imply that when
> encrypting frames from different streams (e.g. audio & video) from the same
> sender implementations need to coordinate the counter values in the SFrame
> header (lest the same IV is used more than once by the sender).  So, to
> make implementation easier / more flexible, we were thinking KID
> should also domain separate streams. E.g. the KID has an extra byte
> indicating the stream. That way encrypting different streams can be done
> independently and concurrently. Does that sound like a good idea to
> everyone? If so maybe we should update the SFrame MLS
> integration recommendation accordingly.
>
> 2) Another question about how KIDs are derived in section 5.2: to avoid
> reuse of the same key/nonce pairs in encryption due to "failure\crash ->
> resumption"  type scenarios maybe it would be a good idea to add a bit of
> entropy (say a byte) into KID that then goes in to the base_key generation.
> Basically, the suggestion is to have a similar mechanism to the nonce reuse
> guard in MLS (only this time its a key reuse guard).
>
>
> 3) Why recommend first generating sframe_epoch_secret as an Exporter and
> then doing HKDF-Expand again to generate individual base_keys? Is there an
> issue with just generating the base_keys directly as Exporter keys?
>
>
> - Joël
>
>
>
>
> Amazon Development Center Austria GmbH
> Brueckenkopfgasse 1
> 8020 Graz
> Oesterreich
> Sitz in Graz
> Firmenbuchnummer: FN 439453 f
> Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz
>
>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>