Re: [MLS] MLS Virtual Clients (subgroups/user-groups) and Paired MLS

[Brendan McMillion <[e-mail]>]

Hi Konrad

Thank you for sharing these! I read the Virtual Clients draft and had some
thoughts:

# 4.1. External remove proposals

I'm confused about this section. If we had an external proposal to remove
an inactive device in a subgroup, then another device in the subgroup could
commit that proposal. If none of the devices in the subgroup came online
for such a long time that it impaired the security of the supergroup, then
we should simply send an external remove proposal in the supergroup. We
can't allow a situation where a member of a subgroup is offline for a long
time, or compromised, and this doesn't percolate up to the supergroup.
Generally I think this point about aligning the security properties of the
subgroup and supergroup is under-considered.

# 4.2. External joins

This subsection is quite short and brushes over one of the really important
problems the draft needs to solve: how do we add a new device to a
subgroup? If another device is online, how specifically can secret state be
shared? If there are no other devices online, what specifically does the
lone device need to do?

# 5. Client Emulation

"An emulator client E in G creates a new virtual client V of G by assigning
the V a fresh virtual client ID" -- The mathematical style of notation is
quite dense and would benefit from being rewritten in plain language.

This section also mentions that each virtual client has its own signature
key pair. The "ephemeral" issuance of signature key pairs is going to be
incompatible with many AS designs.

This section also briefly mentions that secrets used in the supergroup are
derived deterministically from exporter secrets from the subgroup. It's not
clear to me from the draft how the epoch that the exporter secret came from
is ever communicated.

# 5.2. DS/AS Details

We should require here that the DS and AS provide anonymity as to which
device in a subgroup is sending a message.

# 5.5. Challenge-based application message encryption

This whole system seems wrong and unnecessary to me. Virtual Clients would
ideally not require any changes to the MLS wire format. When sending
application messages, there is the *functional* problem of preventing
multiple messages from being encrypted with the same key (functional,
because it may cause messages to become unreadable if the encryption key is
deleted). I think we could largely ignore this and assume that devices will
be able to coordinate through the DS. Then there is the *security* problem
of preventing nonce reuse. The MLS protocol already has a "reuse_guard" for
this purpose, and we could simply compute reuse_guard = PRP(unique
identifier || random data) to ensure that no two devices in a subgroup will
choose the same reuse guard.


On Thu, Dec 14, 2023 at 8:30 AM Konrad Kohbrok <[e-mail]>
wrote:

> Hi everyone,
>
> Today two drafts have been published that relate to two individual topics
> that we have discussed over the past interims: Subgroups (also called
> user-groups) and MLS pairing (also called guardianship).
>
> The virtual clients (or subgroups) draft (
> https://datatracker.ietf.org/doc/draft-kohbrok-mls-virtual-clients/)
> describes how multiple clients can collaborate in emulating a virtual
> client by forming a subgroup underneath a leaf in one or more MLS groups.
> This can be used, for example, to allow a user’s devices to share
> membership in one or more groups, or generally to model any hierarchical
> structure using MLS groups. While this introduces some complexity, it also
> brings performance benefits, as trees generally shrink and updates in a
> subgroup can be re-used across multiple higher-level groups.
>
> The Paired MLS draft (
> https://datatracker.ietf.org/doc/html/draft-fondevik-mls-pairedmls)
> allows two MLS clients to pair up, following the protocol described here:
> https://eprint.iacr.org/2023/1761. Paired-up devices share a randomness
> source, thus allowing one client to issue PCS updates for the other. This
> allows a client with more resources to take load off of another, weaker
> client. This is achieved by the two clients sharing an “anchor”, i.e. a
> single leaf in one or more MLS groups.
>
> As you may have noticed, the “anchor” concept in Paired MLS is
> conceptually the same as that of subgroups, which is why we wanted to
> jointly announce them to the WG.
>
> We are confident that both documents are of interest to the WG and are
> looking forward to feedback and discussions on the list and in the next
> interims.
>
> Both documents are still works in progress. In particular, we’re still in
> the process of lining up terminology, but we’re confident that they are
> mature enough to open up the discussion.
>
> Cheers,
>
> Konrad
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>