Re: [Sframe] [UNVERIFIED SENDER] Re: MLS Integration Question

[Richard Barnes <[e-mail]>]

Hi Joël,

I posted an alternative approach in this PR, to include the KID in both the
key *and* nonce:

https://github.com/sframe-wg/sframe/pull/92

`sframe_secret = HKDF-Extract(base_key, 'SFrame 1.0 ' + KID)`

Wrt (1) - I like this better than your proposal because it segregates both
the key and the nonce, rather than only the nonce space, and it doesn't
require a new identifier (SSRC).  Is there some reason you want to be able
to have multiple non-overlapping nonce streams with the same key, or would
it be tolerable to have different keys?

Wrt (3) - The above proposal seems like a compromise between the two
ideas.  On the one hand, there's still only one export from MLS (of a
base_secret).  On the other hand, even though there's still some HKDF
inside the SFrame box, it's HKDF'ing that is standard across SFrame uses,
not specific to keying with MLS.

How does that strike you?

--Richard

On Tue, Jan 31, 2023 at 9:13 AM Alwen, Joel <[e-mail]> wrote:

> Hey Richard,
>
> 1. Re: domain (key, nonce) domain separation for sources from same user.
>
> > If that looks good to you, let's work on getting it ported over to
> draft-ietf-sframe-enc.
>
> While it looks like it works we have another suggestion. In section 4.3.2
> replace salt derivation with:
>
> sframe_salt = HKDF-Expand(sframe_secret, 'salt'+SSRC, AEAD.Nn)
>
> where + denotes string concatenation and SSRC = synchronization source.
> i.e. a unique ID for the stream (received from the encoder).
>
> This has 2 advantages over the KID construction in your draft doc.
> - It solves the problem once-and-for-all regardless of how keying is done
> rather than just solving it when integrating MLS with SFrame.
> - It leaves more room in the KID for other uses. (E.g. the random
> challenge we proposed in 2.)
>
>
> 2. Re: Crash/resumption leading to (key, nonce) reuse.
>
> Fair enough.
>
>
> 3. Re: calling MLS.export for each sender separately
>
> Both solutions have advantages. An advantage of using MLS.export for each
> sender is that this way one can build an application using black-box an
> SFrame library and a MLS library without needing an HKDF.Expand dependency
> (MLS & SFrame do all HKDFing for them).
>
>
> - Joël & Marta
>
>
>
> ------------------------------
> *From:* Sframe <[e-mail]> on behalf of Richard Barnes <
> [e-mail]>
> *Sent:* Friday, January 27, 2023 9:43 PM
> *To:* Alwen, Joel
> *Cc:* [e-mail]
> *Subject:* [EXTERNAL] [UNVERIFIED SENDER] Re: [Sframe] MLS Integration
> Question
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> 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
>>
>
>
>
> Amazon Development Center Austria GmbH
> Brueckenkopfgasse 1
> 8020 Graz
> Oesterreich
> Sitz in Graz
> Firmenbuchnummer: FN 439453 f
> Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz
>
>
>