MLS WG R. Mahy Internet-Draft Rohan Mahy Consulting Services Intended status: Informational 8 July 2024 Expires: 9 January 2025 Semi-Private Messages in the Messaging Layer Security (MLS) Protocol draft-mahy-mls-semiprivatemessage-00 Abstract This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. 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://rohanmahy.github.io/mls-semiprivate/draft-mahy- semiprivatemessage.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mls- semiprivatemessage/. Discussion of this document takes place on the MLS WG 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/rohanmahy/mls-semiprivatemessage. 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/. 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." Mahy Expires 9 January 2025 [Page 1] Internet-Draft MLS SemiPrivateMessage July 2024 This Internet-Draft will expire on 9 January 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Syntax and Usage . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. SemiPrivateMessage Wire Format . . . . . . . . . . . . . 6 5.2. External Receivers Extension Type . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document defines two extensions of MLS [RFC9420]. The first is the SemiPrivateMessage wire format Safe Extension (see Section 2.1.7.1 of [I-D.ietf-mls-extensions], which allows an otherwise PrivateMessage to be shared with a predefined list of external receivers. It is restricted for use only with commits or proposals. The second is the external_receivers GroupContext extension that contains the list of external receivers and allows members to agree on that list. SemiPrivateMessages are expected to be useful in federated environments where messages routinely cross multiple administrative domains, but the MLS Distribution Service needs to see the content of commits and proposals where group members would otherwise send handshakes using PublicMessage. Mahy Expires 9 January 2025 [Page 2] Internet-Draft MLS SemiPrivateMessage July 2024 2. 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. This document uses terminology extensively from MLS [RFC9420] and the Safe Extensions framework, defined in Section 2 of [I-D.ietf-mls-extensions]. 3. Syntax and Usage The external_receivers GroupContext extension is used for all members to agree on the list of external receivers in the current epoch. Its construction mirrors the syntax of the external_senders extension in [RFC9420]. struct { HPKEPublicKey external_receiver_public_key; Credential credential; } ExternalReceiver; The SemiPrivateMessage wire format Safe Extension also has an extension type which is carried in the GroupContext to indicate use of the wire format in a group (and in the Capabilities of LeafNodes). SemiPrivateMessage substantially reuses the construction of PrivateMessage, but like a Welcome message also contains information (key_and_nonce) necessary to decrypt the ciphertext and encrypted_sender_data, encrypted once for each external receiver in the external_receivers extension. The snippet below shows the syntax and encryption and decryption construction of key_and_nonce into encrypted_key_and_nonce Mahy Expires 9 January 2025 [Page 3] Internet-Draft MLS SemiPrivateMessage July 2024 struct { opaque key; opaque nonce; } MessageKeyAndNonce; MessageKeyAndNonce key_and_nonce; encrypted_key_and_nonce = EncryptWithLabel( external_receiver_pulic_key, "SemiPrivateMessageReceiver", private_message, key_and_nonce) key_and_nonce = DecryptWithLabel( external_receiver_private_key, "SemiPrivateMessageReceiver", private_message, encrypted_key_and_nonce.kem_output, encrypted_key_and_nonce.ciphertext) The KeyForExternalReceiver structure contains a hash of the ExternalReceiver as a reference and the encrypted_key_and_nonce. /* Using the hash function of the group ciphersuite */ ExternalReceiverRef = hash(ExternalReceiver) struct { ExternalReceiverRef external_receiver_ref; HPKECiphertext encrypted_key_and_nonce; } KeyForExternalReceiver; The SemiPrivateMessage and SemiPrivateContentAAD structs mirror the PrivateMessage and PrivateContentAAD structs and add the keys_for_external_receivers list. The SemiPrivateMessageContent struct is the same as PrivateMessageContent except for the addition of keys_for_external_receivers, and that application messages are not included. Encryption of the ciphertext and encrypted_sender_data proceed in the same way for SemiPrivateMessage as for PrivateMessage. Finally, the SemiPrivateMessage is wrapped in an ExtensionContent struct. Mahy Expires 9 January 2025 [Page 4] Internet-Draft MLS SemiPrivateMessage July 2024 struct { opaque group_id; uint64 epoch; ContentType content_type; opaque authenticated_data; KeyForExternalReceiver keys_for_external_receivers; opaque encrypted_sender_data; opaque ciphertext; } SemiPrivateMessage; struct { select (PrivateMessage.content_type) { case proposal: Proposal proposal; case commit: Commit commit; }; KeyForExternalReceiver keys_for_external_receivers; FramedContentAuthData auth; opaque padding[length_of_padding]; } SemiPrivateMessageContent; struct { opaque group_id; uint64 epoch; ContentType content_type; opaque authenticated_data; KeyForExternalReceiver keys_for_external_receivers; } SemiPrivateContentAAD; /* IANA-registered value for semi_private_message */ extension_type = TBD2 SemiPrivateMessage extension_data; 4. Security Considerations These two extensions provide a privacy improvement over sending handshake messages using PublicMessage. The handshake is shared with a specific list of receivers, and that list is visible as part of the GroupContext. TODO More Security. 5. IANA Considerations Mahy Expires 9 January 2025 [Page 5] Internet-Draft MLS SemiPrivateMessage July 2024 5.1. SemiPrivateMessage Wire Format The semi_private_message MLS Extension Type is used to signal support for the SemiPrivateMessage Wire Format (a Safe Extension). * Value: TBD1 (to be assigned by IANA) * Name: semi_private_message * Recommended: Y * Reference: RFC XXXX 5.2. External Receivers Extension Type The external_receivers extension contains a list of external receivers targeted in a SemiPrivateMessage. * Value: TBD2 (to be assigned by IANA) * Name: external_receivers * Message(s): GC. This extension may appear in GroupContext objects. * Recommended: Y * Reference: RFC XXXX 6. Normative References [I-D.ietf-mls-extensions] Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf- mls-extensions-04, 24 April 2024, . [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, . Mahy Expires 9 January 2025 [Page 6] Internet-Draft MLS SemiPrivateMessage July 2024 [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, . Acknowledgments TODO acknowledge. Author's Address Rohan Mahy Rohan Mahy Consulting Services Email: rohan.ietf@gmail.com Mahy Expires 9 January 2025 [Page 7]