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

["Alwen, Joel" <[e-mail]>]

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]<mailto:[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]<mailto:[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