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

[Jason Bolduc <[e-mail]>]

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