Private External Message extensions for Messaging Layer Security (MLS)

Introduction The MLS protocol was designed to support both a model where the Distribution Service (DS) sees the contents of MLS handshake messages and often assumes a policy enforcement role, and a model where the DS is merely responsible for forwarding handshake messages and possibly enforcing ordering of messages. In the first model clients send every handshake as a PublicMessage (or a SemiPrivateMessage ), whereas in the second model the clients send in-group handshakes as a PrivateMessage. As of this writing there are non-trivial commercial deployments using both the PublicMessage model (ex: Cisco, Amazon, Ring Central, Wire) and the PrivateMessage model (ex: XMTP, Germ). In the PrivateMessage model, group members enjoy substantially more privacy from the DS. In the PublicMessage model, the DS usually can provide (authorized) non-members with enough information that they can join a group via an external commit. Even in the PublicMessage model, some (usually large) groups use external proposals to join. In the PrivateMessage model, (authorized) non-members can also join using external proposals (or rarely using external commits if the GroupInfo is shared by an existing member), however the joiner is currently forced to send the proposal (or commit) as a PublicMessage and therefore reveal potentially private information such as their credential and capabilities to the DS. This extension allows groups using PrivateMessage to maintain the privacy of external handshake messages by encrypting them to a public key derived from the group's epoch secret. It also provides a way to convey that public key safely to prevent active attacks.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Mechanism

External Encryption Key Derivation Groups using this extension derive a dedicated HPKE key pair from the next epoch secret for encrypting external messages. When creating a provisional commit, the committer first computes the epoch secret that will result from processing the provisional commit, then derives the external encryption key from that epoch secret. This ensures that removed members cannot decrypt external messages, as they do not have access to the next epoch secret.

Computing the Next Epoch Secret When a member creates a provisional commit, they compute the next epoch secret before sending the commit, following the key schedule defined in . The next epoch secret is derived through the standard MLS key schedule: the commit_secret (from the commit's UpdatePath) and the current epoch's init_secret produce the joiner_secret, which is combined with any PSK secrets to produce the epoch_secret for the new epoch. This document refers to this value as epoch_secret_next.

Deriving the External Encryption Key The external encryption key is then derived from the next epoch secret: Where:

epoch_secret_next is the epoch secret computed for the next epoch
ExpandWithLabel is defined in
KEM.DeriveKeyPair is defined in
KDF.Nh is the size of an output from KDF.Extract for the cipher suite, as defined in

The epoch field in ExternalEncryptionInfo MUST be set to current_epoch + 1. The public key is made available to external senders via the ExternalEncryptionInfo structure (). All group members in the new epoch can derive the same key pair from their shared next epoch secret.

Additional information shared in every commit Groups participating in this mechanism include a root_private_signature_key component (see ) in the GroupContext of type RootPrivateSignature, containing a unique random private signature key corresponding to the group's cipher suite. Whenever a commit removes a member from a group, this component MUST be replaced with a new unique random private signature key. Members sending a commit need to calculate the future epoch_secret, external_encryption_secret, and external_encryption_public_key for the new epoch that would result if the commit is accepted. The commit sender includes one additional Additional Authentication Data (AAD) component (see ) of type ExternalEncryptionInfo in every commit (including commits sent in a PrivateExternalMessage). The ExternalEncryptionInfo includes the external_encryption_public_key for the future epoch.

Note: SafeSignWithLabel is not used, because there are two different component IDs represented.

; } RootPrivateSignature; struct { ProtocolVersion version = mls10; opaque group_id; uint64 epoch; CipherSuite ciphersuite; HPKEPublicKey external_encryption_public_key; SignaturePublicKey root_public_signature_key; } ExternalEncryptionInfoTBS; struct { CipherSuite ciphersuite; HPKEPublicKey external_encryption_public_key; SignaturePublicKey root_public_signature_key; /* SignWithLabel(root_private_signature_key, */ /* "ExternalEncryptionInfoTBS", ExternalEncryptionInfoTBS) */ opaque external_encryption_signature; } ExternalEncryptionInfo; ]]> The epoch field in ExternalEncryptionInfoTBS indicates the epoch for which the external encryption key is valid. Since the key is derived from the next epoch secret, this field MUST be set to current_epoch + 1, where current_epoch is the epoch number at the time the provisional commit is created. Once the commit is processed and the group advances to the new epoch, the epoch field will match the group's current epoch.

Sending an external proposal or external commit to the group A non-member client that wishes to send a message to the group first obtains the ExternalEncryptionInfo from the group's most recent commit. Before using the external_encryption_public_key, the external sender MUST verify the external_encryption_signature by computing VerifyWithLabel using the embedded root_public_signature_key and the label "ExternalEncryptionInfoTBS" over the reconstructed ExternalEncryptionInfoTBS. If verification fails, the ExternalEncryptionInfo MUST be rejected. The external sender then constructs a PublicMessage called external_message_plaintext. The sender_type in the inner PublicMessage MUST NOT be member, since this mechanism is for external senders only. The PrivateExternalMessage wire format wraps that external_message_plaintext by encrypting it to the external_encryption_public_key. The PrivateExternalMessageContext is an empty struct, serialized to a zero-length byte string: ; uint64 epoch; ContentType content_type; opaque authenticated_data; HPKECiphertext encrypted_public_message; } PrivateExternalMessage; ]]> The encryption and message construction are as follows: The PrivateExternalMessage is sent as a new variant of MLSMessage:

Decryption and verification by members Members receiving a PrivateExternalMessage MUST verify that the group_id matches a known group and that the epoch field matches their current epoch. If either check fails, the message MUST be rejected. To decrypt the message, members derive the external encryption key pair from their current epoch secret. Since the ExternalEncryptionInfo was created using the next epoch secret (which is now the members' current epoch secret), the derivation will produce the correct key: If decryption fails, the message MUST be rejected. Members then verify that the following values in the PrivateExternalMessage match their corresponding field in the external_message_plaintext.content:

group_id,
epoch,
content_type, and
authenticated_data

If any of these checks fail, the message MUST be rejected. Members MUST also verify that the sender_type in the decrypted external_message_plaintext is not member. Messages from group members MUST NOT be wrapped in a PrivateExternalMessage. Finally, they process the external_message_plaintext as if it were a regular PublicMessage.

Security Considerations An established MLS group which only exchanges handshakes using MLS PrivateMessage enjoys a high level of privacy for its members. The GroupContext and the ratchet tree, including the contents of the credentials in MLS leaf nodes is not visible to outsiders nor to the DS. However, during the process of joining, private information is often leaked to the DS. This mechanism focuses on improving the privacy for the external joining mechanisms. There are three mechanisms for potential new members to join an MLS group: an existing member gets a KeyPackage (KP) for the new member and commits an Add proposal with the KP; the joiner sends an external proposal asking to join the group that needs to be committed by an existing member; or the joiner fetches the GroupInfo of the group (usually from the DS) and sends an external commit. In the base MLS protocol , an external join or external commit needs to be sent as an MLS PublicMessage, which greatly reduces the privacy of the group.

Security of External Proposals External Add proposals in are sent using an MLS PublicMessage, which is integrity protected but reveals the public signature key, MLS capabilities, MLS credential to the DS, and KeyPackageRef (used to correlate Welcome messages). If a public key representing the entire target MLS group is available, the external proposer can encrypt this information to all group members without revealing it to the DS. The external proposer needs a way to get this public key and not the key of an active attacker, and the DS and members need a reasonable authorization and rate limiting mechanisms to prevent from being overwhelmed by such encrypted requests. The ExternalEncryptionInfo defined in contains a per-group, per-epoch signature key shared by all members of the group. The ExternalEncryptionInfo could be posted in transparency ledger, shared as gossip, or additionally signed by a specific member. The specific mechanism can be tailored to a specific application as needed. Application protocols above the MLS layer would also need to provide authorization. For example, in the MIMI protocol this could be a join code. Other techniques such as using single or limited use pseudonymous tokens, privacy pass , or anonymous credit tokens are all reasonable options. The privacy of some of these techniques could also be reinforced by using Oblivious HTTP .

Use of Next Epoch Secret This specification derives the external encryption key from the next epoch secret (the epoch that results from processing the commit) rather than the current epoch secret. This design choice is critical for maintaining post-compromise security. If the external encryption key were derived from the current epoch secret, removed members would be able to decrypt external messages sent after their removal, because they possess the current epoch secret. By deriving the key from the next epoch secret, removed members do not have access to the keying material and cannot decrypt external messages. This approach follows the same pattern as Welcome messages in , which are encrypted using keys from the new epoch rather than the current epoch.

Security of External Commits External commits in are sent as PublicMessage and reveal the joiner's credential, public signature key, capabilities, and UpdatePath (including HPKE public keys for every node on the joiner's direct path). This allows the DS to learn the identity of the joiner and correlate it with other group memberships. When wrapped in a PrivateExternalMessage, the DS can only observe the group_id, epoch, content_type, and authenticated_data fields in the outer wrapper. The joiner's credential, signature key, capabilities, and UpdatePath are encrypted and visible only to group members. However, some metadata leakage remains:

The DS can observe that an external commit occurred (from the content_type field and the subsequent epoch change).
The DS can observe the size of the encrypted message, which may reveal information about the joiner's credential size or the depth of the ratchet tree.
The Welcome message sent back to the joiner is a separate message that the DS can observe and correlate with the external commit.

The ExternalEncryptionInfo signature prevents a malicious DS from substituting its own HPKE public key to perform an active attack. Without this signature, the DS could decrypt the external commit, inspect the joiner's credentials, then re-encrypt with the legitimate key and forward it, completely defeating the privacy goal. Note that the external_pub key (used for the ExternalInit proposal within the commit) and the external_encryption_public_key (used for the PrivateExternalMessage encryption) serve different purposes. The former is part of the MLS key schedule for deriving the init_secret; the latter protects the confidentiality of the external commit message itself. Both are derived from the epoch secret but from different labeled expansions.

Security of KeyPackages In the classical usage of MLS, a member of a group fetches a KeyPackage, commits an Add proposal containing that KeyPackage, then sends a Welcome to the new member. In order to forward a Welcome message to the correct recipient, the DS needs to be able to associate the KeyPackageRef with some resource that eventually delivers to the appropriate client. As long as KeyPackages are exchanged securely out-of-band, this extension extends the privacy of the MLS GroupContext and ratchet tree to external joiners. When the DS knows the relationship between a fetched KeyPackage and the requesting user or target group, the DS can then link an added member (via its KeyPackageRef) to the requesting user or target group. An appropriate privacy-preserving mechanism (e.g., via Oblivious HTTP ) can associate a KeyPackageRef with the target member, without a correlation to the requesting user or target group. Applications SHOULD consider using such privacy-preserving mechanisms for KeyPackage retrieval when deploying this extension.

Security of Welcomes Welcome messages in are encrypted to the new member's KeyPackage and contain the GroupInfo and path_secret values needed to initialize the new member's state. The Welcome message itself does not reveal group contents to the DS. However, the DS can observe:

That a Welcome message was sent (confirming a successful join).
The KeyPackageRef in the Welcome, which allows the DS to correlate the Welcome with a previously fetched KeyPackage and identify the new member.

This extension does not modify the Welcome message format. Applications concerned about Welcome correlation SHOULD consider additional measures such as using pseudonymous KeyPackage distribution or Oblivious HTTP for Welcome delivery.

IANA Considerations IANA, please replace the value RFC XXXX with the name of this document.

MLS Wire Formats This document requests the addition of a new entry to the "MLS Wire Formats" registry defined in :

Value	Name	Recommended	Reference
TBD1	mls_private_external_message	Y	RFC XXXX

MLS Signature Labels This document requests the addition of a new entry to the "MLS Signature Labels" registry defined in :

Label	Recommended	Reference
ExternalEncryptionInfoTBS	Y	RFC XXXX

MLS Public Key Encryption Labels This document requests the addition of a new entry to the "MLS Public Key Encryption Labels" registry defined in :

Label	Recommended	Reference
PrivateExternalMessageContent	Y	RFC XXXX

MLS Extension Types This document requests the addition of a new entry to the "MLS Extension Types" registry defined in . This extension type is used to identify the ExternalEncryptionInfo AAD component (see ):

Value	Name	Message(s)	Recommended	Reference
TBD2	external_encryption_info	GI	Y	RFC XXXX

MLS Component Types This document registers two new MLS Component Types in the Specification Required range:

root_private_signature_key MLS Component Type

Value: TBD3 (suggested value 0x000A)
Name: root_private_signature_key
Where: GC
Recommended: Y
Reference: RFC XXXX

external_encryption_public_key MLS Component Type

Value: TBD4 (suggested value 0x000B)
Name: external_encryption_public_key
Where: AD
Recommended: Y
Reference: RFC XXXX