Messaging Layer Security (MLS) Targeted Messages

4.1. 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.¶

5.1. 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.¶

5.2. 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:¶

struct {
  opaque label<V>;
  opaque context<V>;
} TargetedMessageContext;

label = "MLS 1.0 TargetedMessageData"
context = group_context

The TargetedMessageContext struct follows the same structure as EncryptContext in Section 5.1.3 of [RFC9420], 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:¶

(kem_output, ciphertext) = SealPSK(
                                        /* pkR */
                                        recipient_node_public_key,
                                        /* info */
                                        hpke_context,
                                        /* aad */
                                        targeted_message_tbm,
                                        /* pt */
                                        targeted_message_content,
                                        /* psk */
                                        targeted_message_psk,
                                        /* psk_id */
                                        psk_id)

The recipient decrypts the content as follows:¶

targeted_message_content = OpenPSK(kem_output,
                  recipient_node_private_key,
                  hpke_context,
                  targeted_message_tbm,
                  ciphertext,
                  targeted_message_psk,
                  psk_id)

The functions SealPSK and OpenPSK are defined in [RFC9180].¶

5.3. Sender Data Encryption

TargetedMessageSenderAuthData is encrypted similarly to MLSSenderData as described in Section 6.3.2 of [RFC9420]. 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 Section 5.2. 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:¶

sender_auth_data_secret =
  MLS-Exporter("targeted message", "sender auth data secret", KDF.Nh)

ciphertext_sample = ciphertext[0..KDF.Nh-1]

sender_auth_data_key = ExpandWithLabel(sender_auth_data_secret,
                           "key", ciphertext_sample, AEAD.Nk)
sender_auth_data_nonce = ExpandWithLabel(sender_auth_data_secret,
                             "nonce", ciphertext_sample, AEAD.Nn)

The Additional Authenticated Data (AAD) for the encrypted_sender_auth_data ciphertext is the first three fields of TargetedMessage:¶

struct {
  opaque group_id<V>;
  uint64 epoch;
  uint32 recipient_leaf_index;
} SenderAuthDataAAD;

7.1. Authentication

Targeted messages use two complementary authentication mechanisms. The sender's signature (Section 4) 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 Section 9.1 of [RFC9180], 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.¶

7.2. Signature Verification Before Processing

The decryption flow necessarily produces plaintext before the signature can be verified: the recipient first decrypts the sender authentication data (Section 5.3) 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. Section 6 requires that the recipient not act on the decrypted content until signature verification has succeeded.¶

7.3. Forward Secrecy

Targeted messages encrypt directly to the recipient's leaf node HPKE encryption key. Unlike application messages in [RFC9420], 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.¶

7.4. Sender Identity Confidentiality

The sender_auth_data_secret used to encrypt the TargetedMessageSenderAuthData is derived from the MLS exporter (Section 5.3) 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.¶

7.5. 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.¶

8.1. 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¶

8.2. MLS Signature Labels

8.3. MLS Exporter Labels