Messaging Layer Security (MLS) Targeted Messages

Introduction MLS application messages make sending encrypted messages to all group members easy and efficient. Sometimes application protocols require that a group member sends a message only to specific members of the same group, either for privacy or for efficiency reasons. Targeted messages are a way to achieve this without having to create a new group with the sender and the specific recipients, which might not be possible or desired. Instead, this document defines the format and encryption of a message that is sent from a member of an existing group to another member of that group. The goal is to provide a one-shot messaging mechanism offering confidentiality and authentication, reusing mechanisms from and . Targeted messages can be used as a building block for more complex messaging protocols.

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.

Format This document defines the mls_targeted_message WireFormat, where the content is a TargetedMessage. A TargetedMessage is carried in the MLSMessage envelope defined in : ; uint64 epoch; uint32 recipient_leaf_index; opaque authenticated_data; opaque encrypted_sender_auth_data; opaque ciphertext; } TargetedMessage; struct { uint32 sender_leaf_index; opaque signature; opaque kem_output; } TargetedMessageSenderAuthData; struct { opaque group_id; uint64 epoch; uint32 recipient_leaf_index; opaque authenticated_data; TargetedMessageSenderAuthData sender_auth_data; } TargetedMessageTBM; struct { ProtocolVersion version = mls10; WireFormat wire_format = mls_targeted_message; opaque group_id; uint64 epoch; uint32 recipient_leaf_index; opaque authenticated_data; uint32 sender_leaf_index; opaque kem_output; } TargetedMessageTBS; struct { opaque group_id; uint64 epoch; opaque label = "MLS 1.0 targeted message psk"; } PSKId; struct { opaque application_data; opaque padding[length_of_padding]; } TargetedMessageContent; ]]>

Authentication A targeted message is authenticated by the sender's signature. The sender uses the signature key of its LeafNode. The signature scheme is determined by the cipher suite of the MLS group. The signature is computed over the serialized TargetedMessageTBS struct and is included in the TargetedMessageSenderAuthData.signature field: The recipient MUST verify the signature: In addition, targeted messages are authenticated using a pre-shared key (PSK), exported through the MLS exporter for the epoch specified in the TargetedMessage: The targeted_message_psk is used as the psk parameter in the Hybrid Public Key Encryption (HPKE) encryption. The corresponding psk_id parameter is the serialized PSKId struct.

Additional Authenticated Data (AAD) Targeted messages can include additional authenticated data (AAD) in the TargetedMessage.authenticated_data field. This field is used to carry application-specific data that is authenticated but not encrypted. The AAD is included in the TargetedMessageTBM struct.

Encryption Targeted messages use HPKE to encrypt the message content to a specific group member. Unlike the HPKE Base mode used in , targeted messages use HPKE PSK mode (). The PSK is derived from the MLS group key schedule, binding the encryption to the group state and providing authentication that the sender holds the group's PSK.

Padding The TargetedMessageContent.padding field is set by the sender, by first encoding the application data and then appending the chosen number of zero bytes. A receiver identifies the padding field in a plaintext decoded from TargetedMessage.ciphertext by first decoding the application data; then the padding field comprises any remaining octets of plaintext. The padding field MUST be filled with all zero bytes. A receiver MUST verify that there are no non-zero bytes in the padding field, and if this check fails, the enclosing TargetedMessage MUST be rejected as malformed. This check ensures that the padding process is deterministic, so that, for example, padding cannot be used as a covert channel.

Application Data Encryption The TargetedMessageContent struct is serialized and encrypted using HPKE. The HPKE context is a TargetedMessageContext struct with the following content, where group_context is the serialized context of the MLS group: ; opaque context; } TargetedMessageContext; label = "MLS 1.0 TargetedMessageData" context = group_context ]]> The TargetedMessageContext struct follows the same structure as EncryptContext in , but uses PSK mode rather than Base mode. The TargetedMessageContext struct is serialized as hpke_context and is used by both the sender and the recipient. The recipient's leaf node HPKE encryption key from the MLS group is used as the recipient's public key recipient_node_public_key for the HPKE encryption. The TargetedMessageTBM struct is serialized as targeted_message_tbm, and is used as the aad parameter for the HPKE encryption. The sender computes TargetedMessageSenderAuthData.kem_output and TargetedMessage.ciphertext: The recipient decrypts the content as follows: The functions SealPSK and OpenPSK are defined in .

Sender Data Encryption TargetedMessageSenderAuthData is encrypted similarly to MLSSenderData as described in . It contains the sender's leaf index, the signature over TargetedMessageTBS, and the Key Encapsulation Mechanism (KEM) output of the HPKE encryption. The key and nonce provided to the Authenticated Encryption with Associated Data (AEAD) are computed as the Key Derivation Function (KDF) of the first KDF.Nh bytes of the ciphertext generated in . If the length of the ciphertext is less than KDF.Nh, the whole ciphertext is used. In pseudocode, the key and nonce are derived as: The Additional Authenticated Data (AAD) for the encrypted_sender_auth_data ciphertext is the first three fields of TargetedMessage: ; uint64 epoch; uint32 recipient_leaf_index; } SenderAuthDataAAD; ]]>

Recipient Validation Upon receiving a TargetedMessage, the recipient MUST perform the following validation steps:

Verify that group_id matches a group the recipient is a member of.
Verify that epoch corresponds to the current epoch or a past epoch for which the recipient still has the necessary key material.
Verify that recipient_leaf_index matches the recipient's own leaf index in the specified epoch.
After decrypting TargetedMessageSenderAuthData, verify that sender_leaf_index refers to a non-blank leaf in the ratchet tree of the specified epoch.
Verify the signature as described in .

The recipient MUST NOT process or act on the decrypted TargetedMessageContent until all of the above validation steps have completed successfully. In particular, the content MUST NOT be passed to the application before the sender's signature has been verified. If any of these checks fail, the TargetedMessage MUST be rejected.

Security Considerations This section describes the security properties of targeted messages and their limitations relative to MLS application messages .

Authentication Targeted messages use two complementary authentication mechanisms. The sender's signature () binds the message to the sender's identity: the recipient verifies the signature against the sender's LeafNode signature key, confirming that the holder of that key produced the message. The PSK exported from the group key schedule provides a second layer that proves group membership. Per , HPKE PSK mode provides outsider authentication, ensuring that an entity that does not know the PSK cannot forge a valid ciphertext. It does not, however, authenticate which PSK holder produced the message. Sender identity relies entirely on the signature. Because the PSK is derived from the MLS key schedule, it is only valid for a specific group and epoch. The Forward Secrecy and Post-Compromise Security guarantees of the group key schedule therefore extend to targeted messages. The PSK also ensures that an attacker needs access to the private group state in addition to the HPKE and signature private keys, improving confidentiality guarantees against passive attackers and authentication guarantees against active attackers.

Signature Verification Before Processing The decryption flow necessarily produces plaintext before the signature can be verified: the recipient first decrypts the sender authentication data () to obtain the sender's leaf index, KEM output, and signature, then decrypts the HPKE ciphertext to obtain the TargetedMessageContent, and finally verifies the signature over the TargetedMessageTBS structure. Because the PSK is shared among all group members and each member's HPKE public key is available in the ratchet tree, any group member can construct HPKE ciphertext that decrypts successfully while claiming a different sender identity. The signature is the sole mechanism that binds the message to the claimed sender. requires that the recipient not act on the decrypted content until signature verification has succeeded.

Forward Secrecy Targeted messages encrypt directly to the recipient's leaf node HPKE encryption key. Unlike application messages in , which derive per-message keys from a secret tree, targeted messages have no per-message key derivation. Compromising the recipient's leaf private key therefore exposes all targeted messages encrypted to that key within the epoch. Forward secrecy is at epoch granularity only: it depends on the key schedule advancing to a new epoch and on the recipient deleting the previous epoch's leaf private key. Applications that require stronger forward secrecy guarantees SHOULD advance the epoch frequently.

Sender Identity Confidentiality The sender_auth_data_secret used to encrypt the TargetedMessageSenderAuthData is derived from the MLS exporter () and is available to all group members. Sender identity is therefore protected from the Delivery Service and from entities outside the group, but not from other group members who obtain the encrypted message.

Replay Protection Targeted messages do not include a generation counter or nonce at the protocol level. A captured targeted message can therefore be replayed within the same epoch and will pass all validation checks. However, targeted messages are a stateless one-shot mechanism: replaying a message causes the recipient to see duplicate content but does not change any group state. Applications that require replay detection SHOULD include a unique nonce in the authenticated_data field and track previously seen values.

IANA Considerations

MLS Wire Formats The mls_targeted_message MLS Wire Format is used to send a message to a subset of members of an MLS group.

Value: 0x0006 (suggested)
Name: mls_targeted_message
Recommended: Y
Reference: RFC XXXX

MLS Signature Labels

TargetedMessageTBS

Label: "TargetedMessageTBS"
Recommended: Y
Reference: RFC XXXX

MLS Exporter Labels

targeted message

Label: "targeted message"
Recommended: Y
Reference: RFC XXXX