2.1.1.Description

An AppAck proposal is used to acknowledge receipt of application messages.Though this information implies no change to the group, it is structured as aProposal message so that it is included in the group's transcript by beingincluded in Commit messages.¶

struct {    uint32 sender;    uint32 first_generation;    uint32 last_generation;} MessageRange;struct {    MessageRange received_ranges<V>;} AppAck;

An AppAck proposal represents a set of messages received by the sender in thecurrent epoch. Messages are represented by thesender andgeneration valuesin the MLSCiphertext for the message. Each MessageRange represents receipt of aspan of messages whosegeneration values form a continuous range fromfirst_generation tolast_generation, inclusive.¶

AppAck proposals are sent as a guard against the Delivery Service droppingapplication messages. The sequential nature of thegeneration field providesa degree of loss detection, since gaps in thegeneration sequence indicatedropped messages. AppAck completes this story by addressing the scenario wherethe Delivery Service drops all messages after a certain point, so that a latergeneration is never observed. Obviously, there is a risk that AppAck messagescould be suppressed as well, but their inclusion in the transcript means that ifthey are suppressed then the group cannot advance at all.¶

The schedule on which sending AppAck proposals are sent is up to the application,and determines which cases of loss/suppression are detected. For example:¶

• The application might have the committer include an AppAck proposal whenever aCommit is sent, so that other members could know when one of their messagesdid not reach the committer.¶
• The application could have a client send an AppAck whenever an applicationmessage is sent, covering all messages received since its last AppAck. Thiswould provide a complete view of any losses experienced by active members.¶
• The application could simply have clients send AppAck proposals on a timer, sothat all participants' state would be known.¶

An application using AppAck proposals to guard against loss/suppression ofapplication messages also needs to ensure that AppAck messages and the Commitsthat reference them are not dropped. One way to do this is to always encryptProposal and Commit messages, to make it more difficult for the Delivery Serviceto recognize which messages contain AppAcks. The application can also haveclients enforce an AppAck schedule, reporting loss if an AppAck is not receivedat the expected time.¶

2.2.1.Description

MLS application messages make sending encrypted messages to all group memberseasy and efficient. Sometimes application protocols mandate that messages areonly sent to specific group members, either for privacy or for efficiencyreasons.¶

Targeted messages are a way to achieve this without having to create a new groupwith the sender and the specific recipients - which might not be possible ordesired. Instead, targeted messages define the format and encryption of amessage that is sent from a member of an existing group to another member ofthat group.¶

The goal is to provide a one-shot messaging mechanism that providesconfidentiality and authentication.¶

Targeted Messages reuse mechanisms from[mls-protocol], in particular[hpke].¶

2.2.2.Format

This extensions introduces a new message type to the MLS protocol,TargetedMessage inWireFormat andMLSMessage:¶

enum {  ...  mls_targeted_message(6),  ...  (255)} WireFormat;struct {    ProtocolVersion version = mls10;    WireFormat wire_format;    select (MLSMessage.wire_format) {        ...        case mls_targeted_message:            TargetedMessage targeted_message;    }} MLSMessage;

TheTargetedMessage message type is defined as follows:¶

struct {  opaque group_id<V>;  uint64 epoch;  uint32 recipient_leaf_index;  opaque authenticated_data<V>;  opaque encrypted_sender_auth_data<V>;  opaque hpke_ciphertext<V>;} TargetedMessage;enum {  hpke_auth_psk(0),  signature_hpke_psk(1),} TargetedMessageAuthScheme;struct {  uint32 sender_leaf_index;  TargetedMessageAuthScheme authentication_scheme;  select (authentication_scheme) {    case HPKEAuthPsk:    case SignatureHPKEPsk:      opaque signature<V>;  }  opaque kem_output<V>;} TargetedMessageSenderAuthData;struct {  opaque group_id<V>;  uint64 epoch;  uint32 recipient_leaf_index;  opaque authenticated_data<V>;  TargetedMessageSenderAuthData sender_auth_data;} TargetedMessageTBM;struct {  opaque group_id<V>;  uint64 epoch;  uint32 recipient_leaf_index;  opaque authenticated_data<V>;  uint32 sender_leaf_index;  TargetedMessageAuthScheme authentication_scheme;  opaque kem_output<V>;  opaque hpke_ciphertext<V>;} TargetedMessageTBS;struct {  opaque group_id<V>;  uint64 epoch;  opaque label<V> = "MLS 1.0 targeted message psk";} PSKId;

Note thatTargetedMessageTBS is only used with theTargetedMessageAuthScheme.SignatureHPKEPsk authentication mode.¶

2.2.3.Encryption

Targeted messages use HPKE to encrypt the message content between two leaves.The HPKE keys of theLeafNode are used to that effect, namely theencryption_key field.¶

In addition,TargetedMessageSenderAuthData is encrypted in a similar way toMLSSenderData as described in section 7.3.2 in[mls-protocol]. TheTargetedMessageSenderAuthData.sender_leaf_index field is the leaf index of thesender. TheTargetedMessageSenderAuthData.authentication_scheme field is theauthentication scheme used to authenticate the sender. TheTargetedMessageSenderAuthData.signature field is the signature of theTargetedMessageTBS structure. TheTargetedMessageSenderAuthData.kem_outputfield is the KEM output of the HPKE encryption.¶

The key and nonce provided to the AEAD are computed as the KDF of the firstKDF.Nh bytes of thehpke_ciphertext generated in the following section. If thelength of the hpke_ciphertext is less than KDF.Nh, the whole hpke_ciphertext isused. In pseudocode, the key and nonce are derived as:¶

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

ciphertext_sample = hpke_ciphertext[0..KDF.Nh-1]¶

sender_data_key = ExpandWithLabel(sender_auth_data_secret, "key", ciphertext_sample, AEAD.Nk)sender_data_nonce = ExpandWithLabel(sender_auth_data_secret, "nonce", ciphertext_sample, AEAD.Nn)```¶

The Additional Authenticated Data (AAD) for theSenderAuthData ciphertext isthe first three fields ofTargetedMessage:¶

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

2.2.4.Authentication

For ciphersuites that support it, HPKEmode_auth_psk is used forauthentication. For other ciphersuites, HPKEmode_psk is used along with asignature. The authentication scheme is indicated by theauthentication_schemefield inTargetedMessageContent. SeeSection 2.2.5for more information.¶

For the PSK part of the authentication, clients export a dedicated secret:¶

targeted_message_psk = MLS-Exporter("targeted message psk", "", KDF.Nh)¶

Th functionsSealAuth andOpenAuth are defined in[hpke]. Other functionsare defined in[mls-protocol].¶

2.2.5.Guidance on authentication schemes

If the group's ciphersuite does not support HPKEmode_auth_psk,implementations MUST chooseTargetedMessageAuthScheme.SignatureHPKEPsk.¶

If the group's ciphersuite does support HPKEmode_auth_psk, implementationsCAN chooseTargetedMessageAuthScheme.HPKEAuthPsk if better efficiency and/orrepudiability is desired. Implementations SHOULD consult[hpke-security-considerations] beforehand.¶

2.2.6.Security considerations

In addition to the sender authentication, Targeted Messages are authenticated byusing a preshared key (PSK) between the sender and the recipient. The PSK isexported 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 theForward Secrecy and Post-Compromise Security guarantees of the group keyschedule apply to the targeted messages as well. The PSK also ensures that anattacker needs access to the private group state in addition to theHPKE/signature's private keys. This improves confidentiality guarantees againstpassive attackers and authentication guarantees against active attackers.¶

3.1.1.targeted_messages_capability MLS Extension

Thetargeted_messages_capability MLS Extension Type is used in thecapabilities field of LeafNodes to indicate the support for the TargetedMessages Extension. The extension does not carry any payload.¶

Template:¶

• Value: 0x0006¶
• Name: targeted_messages_capability¶
• Message(s): LN: This extension may appear in LeafNode objects¶
• Recommended: Y¶
• Reference: RFC XXXX¶

3.1.2.targeted_messages MLS Extension

Thetargeted_messages MLS Extension Type is used inside GroupContext objects. Itindicates that the group supports the Targeted Messages Extension.¶

Template:¶

• Value: 0x0007¶
• Name: targeted_messages¶
• Message(s): GC: This extension may appear in GroupContext objects¶
• Recommended: Y¶
• Reference: RFC XXXX¶

3.2.1.AppAck Proposal

Template:¶

• Value: 0x0008¶
• Name: app_ack¶
• Recommended: Y¶
• Path Required: Y¶
• Reference: [RFC XXXX]¶