Summary

  • draft-mahy-mls-semiprivatemessage-07 lets an MLS group encrypt a commit or proposal for a designated external-receiver list while binding that external view to the content sent to members.
  • The external receiver can recover the per-message key and decrypt the handshake without decrypting SenderData; the draft makes sender-signature verification conditional on possessing the matching GroupContext.
  • Decryption, content equality, current-epoch group state, sender authentication, receiver-list authority and downstream acceptance need separate receipts. Revision 07 remains work in progress and its Security Considerations are explicitly incomplete.

Picture a federation service receiving an MLS commit. Its private key opens the HPKE wrapper. The recovered key and nonce open the handshake ciphertext. Padding is valid. The content hash matches the member-facing version. Every cryptographic light on the service's first panel turns green.

The service still may not be able to authenticate the sender.

That is not a contradiction in Semi-Private Messages in the Messaging Layer Security Protocol, revision 07. It is the document's most useful operational seam. The draft gives an external receiver enough material to decrypt an otherwise private commit or proposal, but says the receiver verifies the signature if it has a copy of the GroupContext. The context is where the current epoch, group extensions, sender credential and agreed receiver list meet.

The result is a clean warning against the word “verified.” Several different verifications occur, and they do not arrive together.

Why the message is semi-private

MLS ordinarily offers PublicMessage and PrivateMessage wire formats. A federation or distribution service may need to inspect commits and proposals that cross administrative domains, while publishing those handshakes to everyone would reveal more than necessary.

Revision 07 defines two linked extensions. external_receivers places a list of receiver HPKE public keys and credentials in GroupContext so members can agree on the list for the current epoch. mls_semiprivate_message creates a wire format restricted to proposals and commits. It is not an application-message bypass.

Use requires more than one client advertising support. The group must require the wire format and must have at least one external receiver in its context. Capability advertisement, group selection and actual message processing are therefore separate states.

For each listed receiver, the sender wraps a per-message key, nonce, reuse guard and sender_leaf_index using HPKE. The encryption context includes group ID, epoch and a hash derived from sender-leaf index and nonce. The receiver uses its private key to recover that material and then opens the common handshake ciphertext.

Same content is not the same as authenticated origin

The design adds framed_content_tbs_hash to the authenticated data. Its purpose is precise: a sender should not be able to give external receivers different commit or proposal content from the version given to members without detection.

That hash is valuable. It closes an equivocation surface inside one message. But it proves a narrower statement than many dashboards will imply.

Receipt What it proves What remains open
Receiver reference found The message contains an entry matching a hashed receiver descriptor The descriptor is still authorized for this epoch
HPKE opening succeeds The receiver private key opens its wrapped per-message material under the supplied context The MLS sender's identity and authorization
AEAD opening succeeds Ciphertext and authenticated data verify under the recovered key Current GroupContext and credential state
Content hash matches Members and external receiver were given the same FramedContentTBS Either side applied or accepted it
MLS signature verifies The sender signature validates against the relevant group state The external service was entitled to act
Downstream receipt succeeds A named service processed a named handshake Universal delivery, convergence or policy correctness

Members take a different path. They decrypt SenderData, locate the correct generation in the sender's handshake ratchet, recover the content key, check the contextual hashes and verify FramedContentAuthData.

An external receiver cannot decrypt encrypted_sender_data. The sender therefore includes the leaf index in the HPKE-wrapped material. That tells the receiver which leaf to consider; it does not itself supply the current leaf credential, extensions and epoch state needed to authenticate the signature. A leaf number is an address inside group memory, not a freestanding identity.

GroupContext is operational state, not decorative metadata

Treating GroupContext as a cacheable accessory creates the dangerous failure mode. A receiver may hold epoch N's context while opening a message that claims epoch N+1. It may retain a receiver key after the group removed its descriptor. It may learn a sender-leaf index whose credential changed. It may successfully decrypt a retransmitted object while its authorization window has closed.

The cryptographic context binds the group ID and epoch into the per-receiver wrapper. That prevents casual transplantation. It does not distribute the full GroupContext, set retention policy or prove freshness to the receiving application. Those are deployment obligations.

A useful receiver pipeline therefore refuses to compress state into one boolean. It records the group ID and epoch from the message; the exact GroupContext digest used; how and when that context was obtained; the external-receiver descriptor and credential digest; the HPKE result; the sender-leaf index; the content-hash result; whether signature verification ran; the credential and leaf state used; the local authorization decision; and the downstream outcome.

If signature verification cannot run because GroupContext is missing, the correct state is not “invalid” and not “verified.” It is “decrypted, content-bound, authentication pending.” That state may be unacceptable for a production action, but naming it accurately preserves the evidence needed to decide.

The receiver list is visible and governed

The draft improves privacy relative to sending the handshake as PublicMessage, but it does not hide the designated-receiver list from group members. The list lives in GroupContext. That visibility is a control surface: members agree to who may receive these handshakes for the epoch.

It is also an institutional question. Who proposes a new federation service? Which members or policies can approve it? When a receiver is removed, what happens to its old private keys and stored contexts? How is a disputed epoch handled? None of those questions is answered by successful HPKE decryption.

Lu Heng's Policy Mirror supplies the useful discipline: record the actor, rule, scope and consequence at the point where a technical list becomes delegated authority. The group extension is the protocol representation of that list. It is not the mandate that created it.

The uncertainty is part of the specification state

Revision 07 is an individual Internet-Draft, not a final standard. Its proposed IANA values are placeholders. Most importantly, the Security Considerations section states the intended privacy improvement and the visibility of the receiver list, then retains TODO More Security.

That sentence must survive editorial compression. It means the current document does not provide a finished security analysis on which an operator should base a categorical claim. A pilot can test the construction. It should not describe an incomplete draft as settled assurance.

The IANA MLS registry records assigned protocol parameters. It does not turn placeholder values in this draft into deployed assignments. RFC 8126 describes registry policy; it does not certify implementation or authorize an external receiver.

The external-receiver receipt

For every SemiPrivateMessage, retain: draft or negotiated protocol version; wire format; group ID and epoch; required-format evidence; exact GroupContext digest and acquisition time; receiver descriptor, credential and public-key digests; local admission authority; HPKE context and result; sender-leaf index; content type; framed_content_tbs_hash result; signature-verification state and input credential; receiver removal or rotation state; local policy decision; and downstream processing result.

The receipt should distinguish not_run, passed and failed for signature verification. A missing context is not a bad signature. A good signature is not proof that the receiver was authorized. A valid commit is not evidence that every member converged. These distinctions are cheap to record before the system turns them into one green icon.

Sources