What a ‘Ghost User’ Would Actually Require in an MLS Commit

The GCHQ “ghost user” idea, as described in secondary reporting, is not a cipher break. It is a proposal to have a service provider silently add an authorized endpoint to an encrypted conversation so that future messages are encrypted to that endpoint as well, without the visible membership or device-change signals users normally rely on. The concept is attributed to GCHQ officials and has been summarized in outlets such as TechBloat and UMA Technology; the primary NCSC PDF was not retrievable when this article was prepared, so the description here is explicitly secondhand and should be treated as such.

No retrieved source shows GCHQ proposing a specific mechanism inside MLS, TreeKEM, or any named protocol. So the useful question is narrower: if an MLS-based messenger were compelled to implement something like this, where in RFC 9420 would it have to live, and what would existing members be able to observe? The answer is that the cryptography would keep working. The thing that would be removed is the application-layer honesty about who is in the group.

MLS membership is a key-holding fact, not a UI state

RFC 9420 defines a client as “an agent that uses this protocol to establish shared cryptographic state with other clients,” and is explicit that “a client is defined by the cryptographic keys it holds.” A member is “a client that is included in the shared state of a group and hence has access to the group’s secrets” (RFC 9420, §2).

That definition matters for the ghost-user discussion. In MLS, being in the group is not a flag the server sets; it is possession of the epoch secret. If an endpoint can decrypt the group’s messages, it is a member in the protocol’s sense, whether or not any client renders it in a roster.

The ratchet tree is the data structure that encodes this. RFC 9420 §3.1 describes it as representing “the membership of the group, providing group members a way to authenticate each other and efficiently encrypt messages to subsets of the group,” and notes that “each epoch has a distinct ratchet tree.” Adding a participant is therefore a tree operation, not a metadata edit.

The Add path: KeyPackage, Proposal, Commit, Welcome

Adding a member in MLS follows a fixed sequence. A KeyPackage is “a signed object describing a client’s identity and capabilities, including a hybrid public key encryption (HPKE) public key that can be used to encrypt to that client” (RFC 9420 §2). A Proposal “proposes a change to the group, e.g., adding or removing a member,” and a Commit “implements the changes to the group proposed in a set of Proposals” (RFC 9420 §2).

The Commit is the epoch transition. RFC 9420 §3 states that “a Commit message initiates a new epoch by instructing members of the group to implement a collection of proposals.” The new member’s state is bootstrapped separately: “a Welcome message provides a new member to the group with the information to initialize their state for the epoch in which they were added” (RFC 9420 §2).

For a ghost-user feature, the cryptographic work is unremarkable. The ghost endpoint would need a KeyPackage with a valid signature and an HPKE public key, an Add proposal referencing it, a Commit that advances the epoch, and a Welcome message delivered to the ghost. Every existing member would process that Commit and move to the new epoch. Nothing in the cipher suite would fail.

What existing members would actually see

Here the specification and the user experience diverge, and it is worth being precise about which is which.

At the protocol level, a Commit changes the group context and the tree. RFC 9420 §7.8 and §7.9 define tree hashes and parent hashes, and the table of contents lists subsections “Using Parent Hashes” and “Verifying Parent Hashes” (RFC 9420 datatracker entry). These are consistency mechanisms: they let members confirm they share the same view of the tree and that parent nodes were computed correctly. They are not user-facing notifications, and they do not by themselves tell a human that a new leaf appeared. A client that processes the Commit correctly will have the new leaf in its tree; whether it displays that leaf is a separate decision.

At the application level, RFC 9750 is direct: “MLS does not itself enforce any access control on group operations. For instance, any member of the group can send a message to add a new member or to evict an existing member… MLS-using applications are responsible for setting their own access control policies” (RFC 9750 §3.5).

That sentence is the hinge. The protocol will accept an Add from any member unless the application imposes a policy. The protocol will advance the epoch. The protocol will derive new secrets that include the new leaf. What the protocol does not do is decide whether the client shows the user a “member added” event. That is application behavior, and it is exactly the layer a ghost-user requirement would target.

Where a ghost would have to live

Stated as reasoning rather than as a finding about any deployed system, a ghost-user feature in an MLS messenger would require changes at two layers:

1. Membership and commit validation. The application would have to accept an Add proposal and Commit from a proposer it would not normally authorize, or from a server-side component acting with provider authority. RFC 9750 §3.5 leaves this to application policy, so the change is a policy change, not a protocol violation.
2. Client rendering. The client would have to process the Commit and advance epochs while suppressing or altering the membership delta it presents to the user. Again, this is application behavior; RFC 9420 does not mandate a particular UI.

Neither change breaks the cipher. The epoch secret still derives correctly, the tree hashes still verify among honest clients, and the ghost endpoint still decrypts. What breaks is the user’s ability to know who is in the conversation.

A hypothetical illustration, clearly labeled as hypothetical: consider a three-member MLS group. A fourth KeyPackage is added via a Commit. The three existing clients process the Commit, verify the tree and parent hashes, and advance to the new epoch. If one client is modified not to render the fourth leaf, the protocol still functions end to end. The user’s model of the group is what has been altered.

What the spec does and does not give you for detection

It is tempting to say MLS “detects” unauthorized additions. It does not, in the sense a user would care about. Tree hashes and parent hashes detect divergent views and malformed parent computations between clients. They are consistency checks, not audit logs, and they do not distinguish an authorized Add from an unauthorized one. RFC 9420 §16.9 discusses Delivery Service compromise and §16.10 Authentication Service compromise; the spec assumes a trusted AS and a largely untrusted DS, and is designed to protect confidentiality and integrity even with a compromised DS (RFC 9420 §3). But a DS that merely delivers a valid Commit is doing its job. The question of whether the Commit should have been accepted is an application policy question.

RFC 9750 §3.5 is the honest summary: access control is the application’s problem. A messenger that wants to make silent additions hard should implement and document a policy — for example, requiring that Add proposals be signed by a designated administrator, or surfacing every membership change with the proposer’s identity and the new leaf’s credential. Those are application choices, and they are the right place to look when evaluating any exceptional-access proposal.

A reproducible reading path

Readers who want to check the claims above against primary text can do so without special tooling:

• RFC 9420 §2 for the definitions of client, member, KeyPackage, Proposal, Commit, and Welcome.
• RFC 9420 §3 for the statement that a Commit initiates a new epoch by instructing members to implement proposals.
• RFC 9420 §3.1 for the ratchet tree as the membership structure, with a distinct tree per epoch.
• RFC 9420 §7.8 and §7.9 for tree hashes and parent hashes, including the “Using” and “Verifying” subsections.
• RFC 9750 §3.5 for the statement that MLS does not enforce access control and that applications set their own policies.

For implementation-level questions, the mlswg/mls-implementations repository lists existing implementations and interop material; it is the appropriate starting point for asking which clients expose commit-construction APIs and how they render membership changes. This article does not assert how any specific messenger renders those changes, because no primary source for a named implementation was retrieved.

FAQ

Does RFC 9420 require clients to notify users when a member is added?

The retrieved text does not establish a requirement either way. RFC 9420 defines protocol messages and processing rules; user-facing notification is not specified there. RFC 9750 §3.5 places access control with the application, which is where notification policy would also sit.

Would a ghost user break the cryptography?

No. The Add/Commit/Welcome machinery is designed to add members. A ghost endpoint with a valid KeyPackage would be a member in the protocol’s sense, and the epoch secret would derive normally. The compromise is to the transparency guarantee, not to the cipher.

Can tree hashes or parent hashes reveal an unauthorized leaf?

They can reveal that two clients disagree about the tree, or that parent nodes were computed incorrectly. They do not label a leaf as authorized or unauthorized. That determination requires application policy.

Did GCHQ propose this specifically for MLS?

No retrieved source shows GCHQ proposing an MLS-specific mechanism. The secondary reporting describes the concept generically. This article analyzes where such a feature would have to live in MLS if it were implemented, not what GCHQ proposed for MLS.

What is the practical takeaway for someone evaluating an MLS messenger?

Ask which layer enforces membership policy and how membership changes are surfaced. RFC 9750 §3.5 makes clear that the protocol will not answer that for you. A messenger that documents an administrator-signed Add policy and renders every membership delta with the proposer’s credential is doing the work that a silent-addition feature would have to undo.