]> Phoenix R&D GmbH

ietf@raphaelrobert.com

Security Messaging Layer Security MLS MLS targeted messages allow sending encrypted messages to a specific member of an MLS group. 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 mandate that messages are only sent to specific group members, 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, targeted messages define 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 that provides confidentiality and authentication, reusing mechanisms from , in particular . 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 extension defines the mls_targeted_message WireFormat, where the content is a TargetedMessage. ; 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 { opaque group_id; uint64 epoch; uint32 recipient_leaf_index; opaque authenticated_data; uint32 sender_leaf_index; opaque kem_output; opaque ciphertext; } 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 the its LeafNode. The signature scheme used is the signature scheme specified in 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 SenderAuthDataAAD.epoch: The targeted_message_psk is used as the psk parameter to the 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 TargetedMessagesTBM struct.

Encryption Targeted messages uses HPKE to encrypt the message content between two leaves.

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.

Sender data encryption In addition, TargetedMessageSenderAuthData is encrypted similarly to MLSSenderData as described in . The TargetedMessageSenderAuthData.sender_leaf_index field is the leaf index of the sender. The TargetedMessageSenderAuthData.signature field is the signature of the TargetedMessageTBS structure. The TargetedMessageSenderAuthData.kem_output field is 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 the following section. 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 SenderAuthData ciphertext is the first three fields of TargetedMessage: ; uint64 epoch; uint32 recipient_leaf_index; } SenderAuthDataAAD; ]]>

Application data encryption The TargetedMessageContent struct contains the application data to be sent to the recipient. The application_data field contains the application data to be sent, and the padding field contains padding bytes to ensure that the ciphertext is of a length that is a multiple of the AEAD tag length. The TargetedMessageContent struct is serialized and then 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 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, an 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 .

Security Considerations In addition to the sender authentication, Targeted Messages are authenticated by using a pre-shared key (PSK) between the sender and the recipient. The PSK is exported from the group key schedule using the label "targeted message psk". This ensures that the PSK is only valid for a specific group and epoch, and the Forward Secrecy and Post-Compromise Security guarantees of the group key schedule apply to the targeted messages as well. The PSK also ensures that an attacker needs access to the private group state in addition to the HPKE/signature's private keys. This improves confidentiality guarantees against passive attackers and authentication guarantees against active attackers.`

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

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.

Acknowledgments TODO acknowledge.