ActivityPub MLS - Message Ordering, Metadata, and Bears (Oh My!)

This is related to E2ee group messaging in ActivityPub but I wanted to start a focused discussion in a somewhat central place.

Right now, IETF RFC 9420 (Messaging Layer Security) provides a wonderful cryptographic primitive for efficiently managing a shared symmetric key for a large number of group members. However, there are two challenges that make its adoption for the Fediverse challenging.

  1. The “Authentication Service” is a black box abstraction that confuses some people.
  2. The “Delivery Service” is simple to imagine for a centralized service, but federation carries challenges not addressed by the RFC. There is ongoing work on Internet Drafts at IETF, in the MLS working group, to cover the federation and decentralization use cases. See draft-xue-mls-decentralized-00 - Distributed and Decentralized Uses of MLS for more information.

Point 1 is something I’m working on (see: my writing and open source work on Key Transparency).

Point 2 is the focus on this discussion.

As stated in draft-xue-mls-decentralized-00 - Distributed and Decentralized Uses of MLS, commit ordering in a federated or decentralized environment (i.e., the Fediverse) is challenging due to potential disagreements on the order in which to apply commits to the group key agreement protocol.

A related concern is metadata (i.e., how much information does a MLS-protected encrypted chat reveal to every instance participating in the discussion?).

The two folks I’ve been discussing this with are @benpate and @eprodrom, but I probably don’t have the most up-to-date understanding of where the conversation currently is, or what outcomes have already been decided. I’m opening this topic so we can have a public place to point folks to.

2 Likes

Great idea. Thanks @Soatok !

Let’s rock :sign_of_the_horns:t2:

commit ordering in a federated or decentralized environment (i.e., the Fediverse) is challenging due to potential disagreements on the order in which to apply commits to the group key agreement protocol.

It shouldn't be a problem if a private conversation has an owner (=actor), who maintains an ordered collection of messages. Something similar to FEP-171b.