MLS Wire Formats for PublicMessage and PrivateMessage without authenticated_data
Internet-Draft draft-pham-mls-additional-wire-formats-00
Anh Pham
Google
anhph@google.com
Marta Mularczyk
Amazon
mulmarta@amazon.com
Raphael Robert
Phoenix R&D
ietf@raphaelrobert.com
Peter Slatala
Google
psla@google.com
21 October 2024
AREA
MLS
additional authenticated data
AAD
Wire formats
This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD.
About This Document
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-pham-mls-additional-wire-formats/.
Discussion of this document takes place on the mls Working Group mailing list (mailto:mls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mls/. Subscribe at https://www.ietf.org/mailman/listinfo/mls/.
Source for this draft and an issue tracker can be found at https://github.com/anhph0/mls-additional-wire-formats.
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

struct {
    ExtensionType extension_type;
    opaque extension_data<V>;
} ExtensionContent;

extension_type is a unique uint16 identifier registered in MLS Extension Types IANA registry (see Section 17.3 of [RFC9420]). 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.

enum {
    PublicMessageWithoutAAD(0),
    PrivateMessageWithoutAAD(1),
} MessageWithoutAAD;

Message Framing

uint16 WireFormat;

struct {
    opaque group_id<V>;
    uint64 epoch;
    Sender sender;

    ContentType content_type;
        select (FramedContent.content_type) {
            case application:
                opaque application_data<V>;
            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 [RFC9420]. 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.

SignWithLabel(SignatureKey, "LabeledExtensionContent", LabeledExtensionContent)

where LabeledExtensionContent is defined as:

label = Label
extension_type = ExtensionType
extension_data = FramedContent

with authenticated_data being injected to FramedContent by the application.
PublicMessageWithoutAAD

struct {
    FramedContentWithoutAAD content;
    FramedContentAuthData auth;
    select (PublicMessageWithoutAAD.content.sender.sender_type) {
        case member:
            MAC membership_tag;
        case external:
        case new_member_commit:
        case new_member_proposal:
            struct{};
    };
} PublicMessageWithoutAAD;

The membership_tag in the PublicMessageWithoutAAD authenticates the sender's membership in the group. It is computed as follows:

membership_tag = MAC(membership_key, AuthenticatedContentTBM)

with AuthenticatedContentTBM and membership_key as defined as in the [RFC9420]. authenticated_data in the FramedContent is injected by the application.
PrivateMessageWithoutAAD

struct {
    opaque group_id<V>;
    uint64 epoch;
    ContentType content_type;
    opaque encrypted_sender_data<V>;
    opaque ciphertext<V>;
} 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 [RFC9420]).
- 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 [RFC2119] [RFC8174] 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".
Normative References
[RFC9420]

The Messaging Layer Security (MLS) Protocol
R. Barnes
B. Beurdouche
R. Robert
J. Millican
E. Omara
K. Cohn-Gordon
July 2023
RFC 9420
DOI 10.17487/RFC9420
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174