MLS A. Pham Internet-Draft Google Intended status: Informational M. Mularczyk Expires: 24 April 2025 Amazon R. Robert Phoenix R&D P. Slatala Google 21 October 2024 MLS Wire Formats for PublicMessage and PrivateMessage without authenticated_data draft-pham-mls-additional-wire-formats-00 Abstract This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD. About This Document This note is to be removed before publishing as an RFC. 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Pham, et al. Expires 24 April 2025 [Page 1] Internet-Draft Wire formats without authenticated_data October 2024 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Extension Definition . . . . . . . . . . . . . . . . . . . . 3 3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3 4. Content Authentication . . . . . . . . . . . . . . . . . . . 4 5. PublicMessageWithoutAAD . . . . . . . . . . . . . . . . . . . 4 6. PrivateMessageWithoutAAD . . . . . . . . . . . . . . . . . . 5 7. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. 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. Pham, et al. Expires 24 April 2025 [Page 2] Internet-Draft Wire formats without authenticated_data October 2024 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. 2. Extension Definition struct { ExtensionType extension_type; opaque extension_data; } 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 (https://messaginglayersecurity.rocks/mls-extensions/draft-ietf-mls- extensions.html#wire-formats), where the extension_data is TLS- serialized MessageWithoutAAD. enum { PublicMessageWithoutAAD(0), PrivateMessageWithoutAAD(1), } MessageWithoutAAD; 3. Message Framing Pham, et al. Expires 24 April 2025 [Page 3] Internet-Draft Wire formats without authenticated_data October 2024 uint16 WireFormat; struct { opaque group_id; 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; 4. 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. 5. PublicMessageWithoutAAD Pham, et al. Expires 24 April 2025 [Page 4] Internet-Draft Wire formats without authenticated_data October 2024 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. 6. PrivateMessageWithoutAAD struct { opaque group_id; 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 (https://messaginglayersecurity.rocks/mls-extensions/ draft-ietf-mls-extensions.html#name-exporting-secrets): Pham, et al. Expires 24 April 2025 [Page 5] Internet-Draft Wire formats without authenticated_data October 2024 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. 7. 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. 8. Security Considerations No implications on the security of the base MLS protocol due to the use of SafeExtension. 9. IANA Considerations This document requests the addition of various new values under the heading of "Messaging Layer Security". 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, . Authors' Addresses Anh Pham Google Pham, et al. Expires 24 April 2025 [Page 6] Internet-Draft Wire formats without authenticated_data October 2024 Email: anhph@google.com Marta Mularczyk Amazon Email: mulmarta@amazon.com Raphael Robert Phoenix R&D Email: ietf@raphaelrobert.com Peter Slatala Google Email: psla@google.com Pham, et al. Expires 24 April 2025 [Page 7]