Re: [MLS] Supporting Large Groups

[Richard Barnes <[e-mail]>]

Hi Brendan,

I'd like to argue that this can be done by a client implementation without
affecting the overall protocol.  If an implementation can keep a group of
clients in sync with regard to the appropriate secrets (primarily init
keys, and a (leaf DH key, signature key) pair per group), then they can
effectively act collectively as one member of the overall group.  You could
even imagine doing this by using MLS to sync across the subgroup.

By the same token, since this can be done via sync within a subgroup, it
doesn't seem like we need to do anything to the base MLS spec to support
this style of composition.  If folks have an interest in having a standard
way to sync stuff, it might make an interesting follow-on spec.

That said, the whole point of MLS vs. earlier linear / N^2 protocols is to
be able to scale farther.  Exactly how much farther will depend on your
specific tolerances, but ISTM that O(10^5) should be acheivable with
relatively modest overhead.

--Richard


On Wed, Sep 26, 2018 at 10:05 PM Brendan McMillion <brendan=
[e-mail]> wrote:

> 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 "[e-mail]" 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.
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>