[MLS] Re: virtual-clients and room-policy's multi_device flag

[Konrad Kohbrok <[e-mail]>]

Hi Jason,

The MIMI draft was not really written with the virtual-clients draft in mind.

One of the goals of the virtual clients draft is to hide much of the multi-client related metadata from other group members (and the Hub in case of MIMI). So the fact that the Hub can’t enforce MIMI policy is kind of by design.

We could add a note to the MIMI policy draft saying that the Hub can’t effectively enforce this particular policy if clients do virtual-clients style multi-device. Personally, I don’t think that’s necessary, but if you have a strong opinion I’d be happy to review a PR.

Cheers,
Konrad


> On 8. Jul 2026, at 20:57, Jason Bolduc <[e-mail]> wrote:
> 
> Hi all,
> 
> While implementing both draft-ietf-mls-virtual-clients-01 and the MIMI room policy (draft-ietf-mimi-room-policy-04) we ran into an interaction between the two documents that neither talks about.
> 
> BaseRoomPolicy (room-policy §5) defines `multi_device`: "If false only a single client can be an MLS member at one time." It also defines `max_clients`, with normative force: "When max_clients has a value, the room's associated MLS group MUST NOT have more clients than the provided value." Both are expressed in terms of clients in the MLS group.
> 
> Virtual clients deliberately break the client==device equivalence: a user's N devices jointly operate one leaf, and the emulation group behind that leaf is invisible to the room. That invisibility is the mechanism's stated metadata-hiding goal (virtual-clients §4.2, §8). So a room with `multi_device = false` admits a five-device user without any violation as written, and a room whose policy says `max_clients = 10` can carry fifty devices while every hub-side count stays at ten. 
> 
> The count itself is not the problem: a hub can still enumerate leaves accurately, and the MUST NOT is still enforceable. `max_clients` and 'multi_device' bound leaves, and with virtual clients a leaf is no longer one device, so if the intent was to bound the number of endpoints holding the room's keys, that intent is no longer served even though every count is correct. `max_users` does not have this problem, since it counts participant-list entries rather than MLS clients, which suggests the member-counting fields were not written with a member/device split in mind.
> 
> Whether that's a bug depends on what the flag intends, and the document doesn't say:
> - If 'multi_device=false' is a performance/simplicity bound (one leaf per user), virtual clients are compatible with it.
> - If it is a security semantic ("I want to talk to exactly one device"), it is now unenforceable by construction, and a room policy cannot restore it: no room-visible artifact distinguishes a virtual client from a plain one unless the deployment chooses to reveal it (the DerivationInfo component is visible in the tree, but its absence proves nothing about a foreign provider's client implementation).
> 
> We'd suggest room-policy state the intent explicitly, and virtual-clients note the interaction in its privacy considerations. If the intent is the security semantic, that likely needs credential-level support (an AS-attested "this leaf is not emulated" claim) rather than a policy bit, though that is not simple either, since the Authentication Service cannot easily verify non-emulation...
> 
> We can write up a more detailed document, if useful, with code that we're already using. We hit this because our implementation sits on both sides: an MLS deployment adding virtual-clients multi-device, federating via MIMI.
> 
> Thanks,
> Jason
> _______________________________________________
> MLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]