Re: [MLS] Subgroups

[Brendan McMillion <[e-mail]>]

Hi Konrad

I was able to publish the draft properly here:
https://datatracker.ietf.org/doc/draft-mcmillion-mls-subgroups/

This includes some updates from your feedback, also detailed below

On Tue, Mar 12, 2024 at 6:23 AM Konrad Kohbrok <[e-mail]>
wrote:

> Hi Brendan,
>
> Thanks for writing this up! Some comments:
>
> # 1 Introduction and 2 Conventions and Definitions
>
> - The language in the document is very specific to the use-case of a
> single user with multiple devices. As there are a few other use-cases for
> such a virtual clients protocol, it might be better to keep the terminology
> a bit more general.
>

Yes, that's intentional. Almost all the content of the draft is about how
to hide which device sent a message or generated a key. That design
constraint seems unique to the multi-device use case and wouldn't apply to
say, subgroups representing an organization, etc.


> # 3.2 Private Keys
>
> - There is a third instance where emulator clients will have to share
> randomness and that is to compute `path_secret[0]` as described in 7.5 of
> the MLS spec. It shouldn’t be a problem to include just add an extra
> deterministic key derivation step, though.
>

Ah yes, I was misled by Fig 14 of RFC 9420 into thinking that
path_secret[0] is already derived from leaf_secret.


> - I always thought that we’d have to rely on commits to coordinate the
> actions of emulator clients, but the including the encrypted PrivateKeyInfo
> is a neat way of doing so indirectly. At least for KeyPackage uploads.
> - If an emulator client uploads KeyPackages, it should probably also
> inform other emulator clients of the KeyPackage’s hash s.t. when they
> receive a Welcome (on behalf of the virtual client) they know which key to
> use for decryption. The other emulator clients can’t learn that hash from
> the Subgroup Extension, because they might not have access to the group’s
> tree if the group relies on RatchetTreeExtensions to transmit the ratchet
> tree. I don’t think that’s covered yet.
>

I'm not sure we need to specify a protocol mechanism for this, as it is not
security-sensitive and there are a lot of valid ways for the DS to handle
it. The device can use an endpoint that allows fetching KPs by reference,
the DS can send the relevant KP along with the Welcome, or KPs can be
synchronized in the background.


> # 4 Application Messages
>
> - As I’ve already mentioned in my other mail, I’m not sure relying on
> DS-client coordination to prevent key reuse is necessarily better than the
> use of an extension, but that might depend on your use-case. My hope is
> that we can eventually come up with a way to avoid both.
>

For the functional aspect of preventing reuse: I think we need to consider
solutions in terms of whether the DS or Strongly Consistent or Eventually
Consistent. A Strongly Consistent DS can allow devices to check that
they've processed all of the messages sent to a group before sending their
own message. This would solve the problem. With an Eventually Consistent
DS, devices may simply need to retain encryption keys for a short while
after they're used. Clients with an Eventually Consistent DS would
generally already be retaining secrets longer than the deletion schedule
advises, so it would not be unusual.


> # 5.2 Joining Externally
>
> - The process of discarding Welcomes is not quite clear to me. Is that
> meant to be done by the other emulator clients once they come back online?
> Or do we assume that the new emulator client can somehow access the pending
> messages of the offline clients? In the latter case, how would the new
> client even know what groups they are for? In any case, we should be very
> clear about things that do or don’t work when allowing external joins this
> way.
>

Yes, there's an assumption that the new device can discard Welcomes sent to
the virtual client before the external join happened. The new device can
ask the DS for the list of groups that the virtual client is a member of --
the DS has this information as a result of supporting External Joins in the
first place.


> Overall, the protocol looks like a good approach to me. Do you want to
> create a PR against the existing virtual clients doc, or do you prefer to
> maintain a separate document for now?
>

I'm not sure what the best resolution would be


> Cheers,
> Konrad
>
>
> Am 11.03.2024 um 04:51 schrieb Brendan McMillion <
> [e-mail]>:
>
> Hi mls@
>
> I wrote a draft today on how I would propose implementing the subgroups /
> virtual clients feature. I'm not currently able to submit it to the
> datatracker, but it is here:
> https://bren2010.github.io/draft-subgroups/draft-mcmillion-mls-subgroups.html
>
> Handling all of the edge cases I could think of, it still came out to be
> quite a simple proposal. Any feedback would be appreciated
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>
>
>