Summary

  • In MLS, every group member can derive the common-framing AEAD keys for sender chains in the epoch. Opening that ciphertext proves only that a group member—or an attacker holding the relevant shared secret—formed it.
  • A sender signature is a separate and stronger receipt. Credential validation, application authorization, delivery and observed business outcome remain separate again.
  • Recovery must name the compromised capability and the evidence produced at each layer. A fresh epoch is valuable cryptographic state, not an automatic incident-closure certificate.

The incident console has a seductive habit. One cryptographic check turns green, and the entire event seems to inherit that colour: the message was authentic, the expected person sent it, the action was authorised, every intended device received it, and the system has recovered. Each clause sounds close to the previous one. None follows automatically.

That distinction is unusually visible in RFC 9750, the MLS Architecture. Messaging Layer Security protects groups whose members may have several clients and whose state changes over time. Its common framing uses authenticated encryption. Yet the architecture explicitly calls that AEAD authentication weak in one precise sense: all group members have the group secrets and can compute the AEAD keys for all sender chains. Successful decryption therefore establishes that some member, or someone with compromised AEAD material, produced the ciphertext. It does not select one client from the group.

This is not a defect in authenticated encryption. It is a boundary around the evidence the key can produce. A shared capability can prove membership in a set of capable actors; it cannot, by itself, distinguish one holder from another. The operational error begins when a system labels this set-level evidence as a named-sender verdict.

Two cryptographic receipts, not one

MLS adds a stronger origin mechanism. RFC 9420 requires a digital signature on each message. For a member sender, verification uses the signature key in the member's LeafNode at the indicated leaf index. The signature covers the content, its wire form and the GroupContext for the current epoch. That construction binds the message to a particular signing capability in a particular group state.

The separation matters during compromise. If an attacker obtains group AEAD material, the attacker may be able to encrypt under those keys. Without the selected client's signature capability, however, the attacker cannot make the message verify as that valid client. Conversely, possession of a signature key or access to a signing oracle is a different and often more serious failure: it can produce the stronger receipt even if the raw key never leaves protected hardware.

An audit event should preserve both results. “AEAD opened” and “sender signature verified at leaf index X for epoch Y” are not verbose duplicates. They represent different capabilities, different compromise paths and different recovery actions. Combining them into “message authenticated” makes the record shorter by deleting the information investigators need most.

The distinction also explains why key placement deserves care. RFC 9750 recommends prioritising protection of signature private keys and discusses hardware security modules or secure enclaves. Frequently changing group secrets may be impractical to protect in precisely the same fashion. Architecture should reflect that asymmetry rather than pretending all secrets have identical lifecycles and consequences.

A client is not yet a person or an office

Even a valid sender signature stops short of many public claims. MLS operates on clients. One user may control several clients, each with its own signature key. The Authentication Service issues credentials, checks an identity-to-key binding against a reference identifier and decides whether credentials describe the same client. Those are separate institutional decisions surrounding the protocol.

A verified signature plus a valid credential can identify a client under the Authentication Service's rules. It does not automatically prove that a human personally pressed a button, that an executive held a particular office at that moment, or that organisational policy authorised the operation. Hardware can be delegated. Sessions can be automated. A signing service can become an oracle. Roles can be revoked in one system while a credential remains syntactically valid in another.

The application owns the next boundary. RFC 9750 says MLS itself does not enforce access control over group operations. Applications decide who may add or remove members, approve sensitive content, commit a state change or exercise an administrative role. A valid Proposal describes a prospective change; a valid Commit changes group state. Neither artefact alone says that the correct business approver authorised the change.

This is where interface language becomes governance. A badge reading “verified executive action” may silently combine a signature check, a credential lookup and a policy assumption. A more honest interface names the receipt: “client signature verified”; “credential current”; “role policy approved.” The extra words prevent cryptography from acquiring institutional authority by visual implication.

Delivery remains outside the envelope

The Delivery Service routes MLS messages and distributes initial key material. Depending on the deployment, it may offer strong ordering or eventual consistency. It can suppress messages, deliver stale material or present different valid-looking histories to clients. MLS aims to prevent a compromised Delivery Service from reading content or forging acceptable client messages, but confidentiality and origin verification do not create availability or convergence.

Ciphertext accepted by one device is therefore not evidence that every intended device fetched it, processed the same epoch, displayed the content or caused a person to act. A serious delivery claim needs its own chain: service acceptance, fan-out, per-client fetch, cryptographic processing, epoch convergence, reader presentation and—if relevant—an independently observed outcome.

The newly added client example is especially useful. Until that client has joined and contributed to group state in a way other members can verify, the group cannot safely infer that it is operational merely because a Welcome message was issued. Dispatch is not receipt; receipt is not decryption; decryption is not adoption of the same current state.

Recovery requires the name of the secret

“The keys were rotated” is too imprecise to close an MLS incident. Ratchet-secret compromise can expose current and future AEAD keys for a sender chain during an epoch while correctly deleted past keys remain protected. Broader group-secret compromise can affect encryption and decryption across compromised epochs. Signature-key compromise changes attribution risk. Access to a signing oracle can be operationally equivalent to key extraction while leaving a hardware audit that misleadingly says the private key never moved.

For a passive compromise, an honest Commit after remediation can establish fresh epoch secrets subject to the protocol's post-compromise security conditions. An active attacker with continuing protocol access is harder. Removing the compromised party is the operation that restores secrecy for later epochs when the remaining members are honest. The protocol transition is necessary evidence, but incident closure also needs proof that the bad client was removed or updated, relevant credentials were invalidated, replacement devices were admitted correctly, application roles were restored and recipients converged.

The useful recovery record therefore names both the affected capability and the boundary of the remedy. “Epoch advanced from E to E+1 after removal of client C” supports a narrower conclusion than “secure again.” The narrower statement is stronger because it can be tested.

Build an evidence ladder

Operational systems should make the reasoning explicit. A practical ladder begins with eight independently recorded questions:

  1. Did the ciphertext parse and did the AEAD open?
  2. Were epoch, generation and replay state accepted?
  3. Did the sender signature verify against the indicated member or allowed external sender?
  4. Did the Authentication Service validate the credential against the expected client reference?
  5. Was that client a current member of the group state being evaluated?
  6. Did application policy authorise this specific operation?
  7. Did the Delivery Service and intended clients produce the required delivery and processing receipts?
  8. Was the asserted human or business outcome independently observed?

Each rung can depend on the previous one, but none should impersonate the next. This is the core leadership lesson in RFC 9750: a mechanism becomes governable when its receipts retain the scope of the mechanism that produced them.

RFC 9750 is an Informational architecture document, while RFC 9420 is the Standards Track protocol specification. Neither source establishes that a named product implements these controls, nor do they document a measured exploit or deployment outcome. The value lies in the architecture's disciplined partition of claims. That partition gives buyers better requirements, operators better telemetry and incident commanders recovery statements that can survive scrutiny.

Sources