MLS Wire Formats for PublicMessage and PrivateMessage without authenticated

Introduction Sometimes it is desirable to have additional authenticated data to be included in the computation of MLSMessage constructions, but not to have it sent on the wire as part of these messages. A use-case is applications that want to have some information available to the server together with a MLSMessage and at the same time want to prove the authenticity of the information to other clients. An example of this is the case of delivery receipts where the server needs to know that a message from Alice has been delivered to Bob, but at the same time it wants Alice to be able to verify that the delivery receipt indeed comes from Bob. This document proposes an extension to support new wire formats for MLS PrivateMessage and PublicMessage to support such cases. Applications will inject additional data as part of the MLSMessage computation, but the additional data is not included in the MLSMessage. Note that it is the application's responsibility to know what needs to be used as additional data when it processes messages with these new wire formats.

Extension Definition ; } ExtensionContent; ]]> extension_type is a unique uint16 identifier registered in MLS Extension Types IANA registry (see Section 17.3 of ). This extension uses the mls_extension_message WireFormat as defined in Section 2.1.7.1 of the Extensions Framework, where the extension_data is TLS-serialized MessageWithoutAAD.

Message Framing ; uint64 epoch; Sender sender; ContentType content_type; select (FramedContent.content_type) { case application: opaque application_data; case proposal: Proposal proposal; case commit: Commit commit; }; } FramedContentWithoutAAD; ]]>

Content Authentication FramedContentWithoutAAD is authenticated using the same procedure for FramedContent described in Section 6.1 of . A difference is that in the FramedContentTBS definition, we have FramedContent with authenticated_data being injected from the outside by the application. Moreover, the signature in the FramedContentAuthData is computed by using SafeExtension. where LabeledExtensionContent is defined as: with authenticated_data being injected to FramedContent by the application.

PublicMessageWithoutAAD The membership_tag in the PublicMessageWithoutAAD authenticates the sender's membership in the group. It is computed as follows: with AuthenticatedContentTBM and membership_key as defined as in the . authenticated_data in the FramedContent is injected by the application.

PrivateMessageWithoutAAD ; uint64 epoch; ContentType content_type; opaque encrypted_sender_data; opaque ciphertext; } PrivateMessageWithoutAAD; ]]> Similar to PrivateMessage, encrypted_sender_data and ciphertext are encrypted using the AEAD function specified by the cipher suite in use, using the SenderData and PrivateMessageContent structures as input. The SenderData is encrypted using the sender_data_secret of the group. The actual message content is encrypted using the key derived as follows:

Derive a secret as defined in Section 2.1.5 of the Extensions Framework: DeriveExtensionSecret(Secret, Label) = ExpandWithLabel(epoch_secret, "ExtensionExport " + ExtensionType + " " + Label)
Use the the secret in lieu of encryption_tree to seed the Secret Tree (Section 9 of ).
Follow the procedure of the Secret Tree to generate encryption keys and nonces for the encryption of the message content.

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.

Security Considerations No implications on the security of the base MLS protocol due to the use of SafeExtension.

IANA Considerations This document requests the addition of various new values under the heading of "Messaging Layer Security".