Subject: [MLS] Supporting Large Groups

From: Brendan McMillion <[email-masked]>
Date: Wed, 26 Sep 2018 13:05:32 -0700

Hello mls@

My current understanding of the MLS protocol is that every user must be
individually invited to every chat room that they're a member of. This has
a lot of bad usability and performance properties for the case where you
want to invite the same large set of people to several different rooms. For
example, you could think about "[email-masked]" being invited to
rooms for "Product A", "Team B", etc. I think it would be easy enough to
address this in the standard:

Rather than only being able to add one user at a time, you could introduce
a mailing list-type concept where many people are represented by a single
email address / public key. Group membership, and therefore the group
public key, would be maintained by the same system that stores user
identity keys.

I think there are probably a lot of valid ways to construct a group public
key, so standardizing a specific construction would be less useful than
just defining the necessary properties and how it would interact with the
protocol. What makes sense to me is: groups have only init keys which are
known to all group members, and no identity keys. This means that group
members can read messages but not send them (with the exception of an
Update message). To speak in a room, a group member must first send an Add
message for themselves. They can send the Add message because they know all
of the room secrets, through their knowledge of the group init private key.

An Update message can be sent on behalf of a group to occasionally update
the group init key, without requiring any specific member of the group to
join the room. Rather than signing the message to authenticate it, they
would have to provide some evidence from the Key Store that this is really
the group's updated init key. Note that in the interest of efficiency, a
group init key would likely be semi-static and re-used between several
rooms, unlike user init keys which are only used once.

Any comments or suggestions are welcome.