]> Phoenix R&D GmbH

ietf@raphaelrobert.com

Security Messaging Layer Security MLS This document defines targeted messages for the Messaging Layer Security (MLS) protocol. A targeted message allows a member of an MLS group to send an encrypted and authenticated message to another member of the same group without creating a new group. The mechanism reuses Hybrid Public Key Encryption (HPKE) and the MLS key schedule to provide confidentiality, authentication, and binding to the group state. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 member signals support for the mls_targeted_message WireFormat by listing it in the supported_wire_formats extension of its LeafNode, as defined in . A group requires all of its members to support the WireFormat by listing it in the required_wire_formats extension of its GroupContext. A sender MUST NOT send a TargetedMessage to a member whose LeafNode does not list mls_targeted_message in its supported_wire_formats extension, unless the required_wire_formats extension in the group's GroupContext includes mls_targeted_message. 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 { 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; opaque ciphertext_hash; } 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; ]]>

Cryptographic Algorithms All cryptographic operations on a targeted message use the cipher suite of the MLS group in which the message is sent (). In particular, the group's cipher suite determines:

• the Key Encapsulation Mechanism (KEM), Key Derivation Function (KDF), and Authenticated Encryption with Associated Data (AEAD) used for the HPKE encryption of the message content (),
• the KDF underlying the MLS-Exporter and ExpandWithLabel derivations ( and ), including the value KDF.Nh,
• the AEAD used to encrypt the sender authentication data (), including the values AEAD.Nk and AEAD.Nn,
• the hash function used to compute ciphertext_hash (), and
• the signature algorithm used to sign and verify the TargetedMessageTBS struct ().

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 ciphertext_hash field of TargetedMessageTBS is computed over the TargetedMessage.ciphertext field with the hash function of the group's cipher suite: Covering the ciphertext hash binds the signature to the encrypted message content. 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 content of this field is used as the aad parameter of the HPKE encryption ().

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 info is a serialized TargetedMessageContext struct with the following content: = "MLS 1.0 TargetedMessageData"; TargetedMessageContextData context; } TargetedMessageContext; ]]> The TargetedMessageContext struct follows the same convention as EncryptContext in , a label followed by application context. Unlike EncryptContext, the context field is typed rather than opaque, and the encryption uses PSK mode rather than Base mode. The context field binds the encryption to the recipient and sender leaf indices. The message is bound to the group state through the targeted_message_psk, as described in . The TargetedMessageContext struct is serialized as hpke_info and is used by both the sender and the recipient. The recipient's leaf node HPKE encryption key from the ratchet tree of the epoch specified in the TargetedMessage is used as the recipient's public key recipient_node_public_key for the HPKE encryption. The content of the TargetedMessage.authenticated_data field is used as the aad parameter for the HPKE encryption. The sender uses the single-shot SealPSK API: In full, the sender performs the following steps in order:

• Derive the targeted_message_psk () and the sender_auth_data_secret ().
• Compute kem_output and ciphertext by calling SealPSK with the serialized TargetedMessageContent as plaintext.
• Compute ciphertext_hash from ciphertext, construct the TargetedMessageTBS struct, and compute the signature as described in .
• Assemble the TargetedMessageSenderAuthData struct from sender_leaf_index, signature, and kem_output, and encrypt it as described in , using a sample of the ciphertext computed above.

The TargetedMessageSenderAuthData.kem_output field is set to kem_output, and the TargetedMessage.ciphertext field is set to ciphertext. The recipient learns the kem_output and the sender_leaf_index by decrypting encrypted_sender_auth_data before decrypting the content. The sender_leaf_index is needed to construct the TargetedMessageContextData struct: The functions SealPSK and OpenPSK are defined in .

Sender Data Encryption TargetedMessageSenderAuthData is encrypted similarly to SenderData as described in . It contains the sender's leaf index, the signature over TargetedMessageTBS, and the KEM output of the HPKE encryption. The key and nonce provided to the AEAD are computed as the 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. As with the targeted_message_psk, the sender_auth_data_secret is exported from the key schedule of the epoch specified in the TargetedMessage. 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 steps in order:

• Verify that group_id matches a group the recipient is a member of.
• Verify that epoch corresponds to the current epoch of that group, or to 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.
• Decrypt encrypted_sender_auth_data as described in and verify that sender_leaf_index refers to a non-blank leaf in the ratchet tree of the specified epoch.
• Compute ciphertext_hash from TargetedMessage.ciphertext and verify the signature as described in .
• Decrypt ciphertext as described in .
• Verify that the padding field of the decrypted TargetedMessageContent contains only zero bytes, as described in .

The signature MUST be verified before ciphertext is decrypted. The TargetedMessageTBS struct covers the ciphertext only through its hash, which the recipient computes from the wire-format ciphertext field, so signature verification does not depend on the decrypted content. Verifying first ensures that no plaintext is produced from a message whose claimed sender has not been authenticated. The decrypted TargetedMessageContent MUST NOT be passed to the application before all of the above steps have completed successfully. If any of these steps fails, the TargetedMessage MUST be rejected.

Messages from Past Epochs Processing a TargetedMessage for a past epoch requires the recipient to retain the following key material and state for that epoch:

• the exporter secret, or the targeted_message_psk and sender_auth_data_secret derived from it,
• the recipient's leaf node HPKE private key, and
• the leaf nodes of the ratchet tree, in order to look up the sender's leaf node.

Support for past epochs is OPTIONAL. Accepting only the current epoch is the most conservative behavior. Retaining key material from past epochs weakens the forward secrecy properties described in : targeted messages for an epoch remain decryptable for as long as that epoch's key material exists. Applications that accept messages from past epochs SHOULD bound the number of retained epochs and SHOULD delete the corresponding key material as soon as it is no longer needed.

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.

Group State Binding Targeted messages are bound to the group state through the targeted_message_psk. The key schedule of injects the serialized GroupContext into the derivation of each epoch's secrets, so the exporter-derived PSK commits to the full group state of the specified epoch, including the tree hash and the confirmed transcript hash.

Message Field Binding The HPKE encryption is bound to the fields of a targeted message at one or more layers. The group_id and epoch are bound through the psk_id and through the epoch-derived PSK, both of which enter the HPKE key schedule. The leaf indices of the recipient and the sender are bound through the HPKE info input, which carries the TargetedMessageContextData struct. The authenticated_data field is authenticated directly as the HPKE aad parameter. The kem_output is bound through the HPKE key schedule, which derives the encryption keys from the KEM shared secret. For the DHKEM variants used by the cipher suites of , the shared-secret derivation also includes the kem_output itself. Independently of these HPKE-layer bindings, the sender's signature over the TargetedMessageTBS struct covers all of the fields above together with the hash of the ciphertext.

Signature Verification Before Processing 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. The TargetedMessageTBS structure covers the kem_output and a hash of the ciphertext, both of which are available before content decryption: the former from the decrypted sender authentication data (), the latter from the wire format itself. therefore requires the recipient to verify the signature before decrypting the HPKE ciphertext, ensuring that plaintext is never produced from a message whose claimed sender has not been authenticated.

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 exporter secret. Applications that require stronger forward secrecy guarantees SHOULD advance the epoch frequently. Accepting targeted messages from past epochs requires retaining old key material and further weakens forward secrecy, as described in .

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. The encryption mechanism is the same as the one used for SenderData in , and the analysis of applies equally to targeted messages. In particular, using the same sender_auth_data_secret with the same ciphertext sample more than once would reuse an AEAD key and nonce pair; with the AEAD algorithms of the cipher suites defined in , the probability of two ciphertext samples colliding is no more than 2^-128.

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 single member 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 Public Key Encryption Labels Although targeted messages use the HPKE PSK mode directly rather than EncryptWithLabel, the label follows the same convention and is registered to prevent collisions with other uses of the same HPKE keys.

TargetedMessageData

• Label: "TargetedMessageData"
• Recommended: Y
• Reference: RFC XXXX

MLS Exporter Labels

targeted message

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

Normative References Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Phoenix R&D The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API.

Test Vectors The following test vectors exercise the receiver-side processing described in . Because the HPKE encapsulation is randomized, the sender-side operations are not reproducible from the inputs alone; sender implementations can be tested by round-tripping against a receiver implementation. All vectors use the mandatory-to-implement MLS cipher suite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. All values except cipher_suite, epoch, the leaf indices, and padding_length (all decimal) are hex-encoded. Each vector provides the group state held by the recipient:

• group_id and epoch: the group and epoch the message belongs to.
• exporter_secret: the exporter secret of that epoch, from which the targeted_message_psk and the sender_auth_data_secret are derived ( and ).
• sender_leaf_index and sender_leaf_node: the sender's leaf index and serialized LeafNode, which provides the signature public key.
• recipient_leaf_index and recipient_encryption_priv: the recipient's leaf index and leaf node HPKE private key.

as well as the message and its expected plaintext:

• targeted_message: a serialized MLSMessage with the mls_targeted_message WireFormat, containing the TargetedMessage.
• authenticated_data: the expected content of the TargetedMessage.authenticated_data field.
• application_data: the expected application data after decryption.
• padding_length: the expected length of the zero-filled padding field of the decrypted TargetedMessageContent.

A verifier performs the steps of on targeted_message and checks that all validation steps succeed, that the decrypted application data matches application_data, and that the padding has length padding_length.

Vector 1

Vector 2

Vector 3

Change Log draft-ietf-mls-targeted-messages-02:

• Replaced the TargetedMessageTBM struct with the TargetedMessageContextData struct, which carries the leaf indices and is used as the context field of the HPKE info.
• Used the content of the authenticated_data field directly as the HPKE aad parameter.
• Replaced the two-step SetupPSKS and Context.Seal flow with the single-shot SealPSK API, which is possible now that the AAD no longer depends on the kem_output.
• Added a security consideration describing how each message field is bound.
• Updated the test vectors.
• Specified how members signal support for the mls_targeted_message WireFormat with the supported_wire_formats and required_wire_formats extensions, and when a sender is allowed to send a TargetedMessage to a member. This adds a normative reference to draft-ietf-mls-extensions.
• Corrected the Forward Secrecy security consideration. Forward secrecy depends on the recipient deleting the previous epoch's exporter secret, not its leaf private key.
• Editorial fixes: described the TargetedMessageContext struct as the HPKE info parameter and renamed hpke_context to hpke_info, used the RFC 9420 name SenderData instead of MLSSenderData, expanded the KEM, KDF, and AEAD abbreviations at first use, spelled out MTI, and lowercased "forward secrecy" and "post-compromise security".

draft-ietf-mls-targeted-messages-01:

• Changed the intended status from Informational to Standards Track.
• Added a ciphertext_hash field to TargetedMessageTBS so that the signature covers the message content; TargetedMessageTBM now carries sender_leaf_index and kem_output directly.
• Replaced the single-shot SealPSK call with SetupPSKS followed by Context.Seal, and specified the full sender-side order of operations.
• Specified the recipient-side processing steps, including signature verification before content decryption.
• Emptied the context field of TargetedMessageContext; the group state binding is provided by the PSK, as described in the new Group State Binding security consideration.
• Added a Cryptographic Algorithms section binding all operations to the group's cipher suite.
• Bound the recipient's public key and the exported secrets to the epoch specified in the message, and added a Messages from Past Epochs section.
• Referenced the analysis of sender data encryption from RFC 9420 in the security considerations.
• Registered the "TargetedMessageData" MLS Public Key Encryption Label.
• Added a Test Vectors appendix.
• Editorial fixes: corrected the RFC 9180 section reference for PSK mode and aligned the IANA wire format description with the single-recipient design.

Acknowledgments