Summary

  • RFC 9420 makes a Proposal-and-Commit transition into a new MLS epoch a well-defined cryptographic event among authenticated clients.
  • That event does not establish a human consensus, business authorisation, complete delivery record, application acknowledgement or downstream effect; those are separate claims with separate owners.

“The group agreed” is one of the most compressed sentences in technical management. It can mean that a chat message was sent, that a threshold vote passed, that a change request was approved, that every accountable person acknowledged it, or merely that a system advanced to a state with a new number. Those are not interchangeable events. They leave different evidence, have different failure modes and put responsibility in different places.

Messaging Layer Security, specified in RFC 9420, does an important narrower job. It provides continuous authenticated key exchange for a group of clients. Its core unit is not a team, a department or a collection of people. It is a group of cryptographic clients sharing state. The group’s history is a linear sequence of epochs; in each epoch, a specific set of authenticated clients holds shared cryptographic state.

That definition is already a useful restraint. RFC 9420 defines a client by the keys it holds. It does not say that the client is a natural person, that one person has one client, that a client’s controller has read a message, or that a key-bearing endpoint may speak for an organisation. A protocol can authenticate the participation of a client in the authentication environment it is given. It cannot silently import every social, legal and operational fact that a business sentence such as “the group agreed” carries.

The state transition itself is precise. A Proposal suggests a change to the group: an addition, an update, a removal or another defined action. A Commit implements the changes proposed in a set of Proposals. When a client creates or processes a Commit, it advances the ratchet tree and GroupContext from an old state to a new state. The GroupContext records values including the group identifier, the new epoch, a tree hash and a confirmed transcript hash.

Where members are added, the Commit creator constructs the corresponding Welcome at the same time, providing the materials by which new clients can establish their copy of the resulting cryptographic state.

That chain supports a strong and limited observation: under the protocol’s validation rules, a particular client processed a particular state transition for a particular MLS group. The transcript and confirmation machinery bind defined protocol material across epochs. The ratchet construction supports confidentiality and removes old members from future group secrets under the conditions the protocol describes. A valid Commit is not merely an assertion printed on a dashboard.

But it is still an assertion about a protocol state. The word “Commit” is a trap for readers who bring institutional meaning to a technical verb. In MLS it does not mean a board resolution, an executed contract, a completed operational change or a recorded approval. It means that the protocol has incorporated a defined list of Proposals and advanced the group state. A Welcome does not mean an employee onboarding event. It means the message structure that equips an added client to join an MLS state. A group epoch does not mean an organisation has reached a new policy epoch.

It means the members of that protocol group have a new shared cryptographic context.

RFC 9420’s delivery model makes the boundary sharper. MLS assumes an Authentication Service that lets group members authenticate credentials and a Delivery Service that routes messages. It assumes the former is trusted and treats the latter as largely untrusted. The protocol is designed so a compromised Delivery Service cannot forge a valid MLS message. Yet the RFC is equally clear about what remains: the service can selectively delay or remove messages, permanently block a member’s traffic and, when an application lets the service resolve simultaneous Commits, influence which Commit is applied.

This is not an abstract edge case for an evidence model. A valid Commit can establish that one state transition was processed; it cannot prove that every intended client received every relevant message in a usable time window. The Delivery Service can make loss look like loss rather than an attack. Apart from a defined sender-data generation value, RFC 9420 leaves loss detection to the application. A control room that needs a reliable delivery record must produce one at that layer. It should not convert the absence of a cryptographic forgery into proof of complete circulation.

The acknowledgement boundary is even more direct. RFC 9420 describes how, in an asynchronous application, clients that could recognise a malformed Commit may be offline. A resulting state may become the basis for later Commits; when the affected clients return, they may be unable to catch up. The RFC says an application can require successful-processing acknowledgements before regarding a Commit as accepted. It also says that MLS does not provide a built-in mechanism for those acknowledgements.

That sentence should change the design review. “The Commit exists” and “the application regards the Commit as accepted” are deliberately separate states. So are “the application recorded sufficient acknowledgements” and “the responsible people made a decision.” The first is a protocol fact. The second is an application policy outcome. The third is evidence gathered under that policy. The fourth belongs to the institution that assigns authority and records its own acts.

Keeping those layers separate is not a criticism of MLS. It is how MLS can be used honestly. The protocol delivers a portable, cryptographically coherent representation of a group’s key state. The Authentication Service supplies one kind of credential binding. The Delivery Service exposes a delivery path with specified residual risks. An application may define acknowledgements, timeouts, conflict handling and admission policy. A local organisation may then decide what action, if any, is allowed. Each step can be excellent. None becomes evidence for the next merely by sharing the same word, group.

For leaders designing a control around MLS, the record should preserve the distinctions rather than overwrite them. Record the group identifier and epoch; the Commit and relevant proposal references; the credential and authentication-policy context; the delivery observations; the application’s acknowledgement rule, threshold and timeout; the local decision record; and the executed action, if one occurred. A later reviewer should be able to tell whether a state transition happened, whether enough endpoints processed it, whether the organisation approved anything and whether an external effect followed.

A single green “group committed” status cannot answer all four questions.

Lu Heng’s separation of representation, local decision and running result is useful here as a discipline, not as a claim about MLS. A protocol state can be exact, inspectable and useful while remaining only one layer of reality. The error is not trusting the Commit for what it proves. The error is allowing its precision to borrow the authority of a decision that a different system, person or institution must still make.

Sources