Semi-Private Messages in the Messaging Layer Security (MLS) Protocol
draft-mahy-mls-semiprivatemessage-02

Messaging Layer Security                                         R. Mahy
Internet-Draft                            Rohan Mahy Consulting Services
Intended status: Informational                             1 August 2024
Expires: 2 February 2025

  Semi-Private Messages in the Messaging Layer Security (MLS) Protocol
                  draft-mahy-mls-semiprivatemessage-02

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-semiprivatemessage/draft-mahy-mls-
   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 Messaging Layer
   Security 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 2 February 2025                [Page 1]
Internet-Draft           MLS SemiPrivateMessage              August 2024

   This Internet-Draft will expire on 2 February 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 . . . . . . . . . . . . . . . . . . . . .   6
     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 2 February 2025                [Page 2]
Internet-Draft           MLS SemiPrivateMessage              August 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
   (keys_and_nonces) necessary to decrypt the SemiPrivateMessage
   struct's 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 keys_and_nonces into encrypted_keys_and_nonces

Mahy                     Expires 2 February 2025                [Page 3]
Internet-Draft           MLS SemiPrivateMessage              August 2024

   struct {
     opaque sender_data_key<V>;
     opaque sender_data_nonce<V>;
     opaque key<V>;
     opaque nonce<V>;
   } PerMessageKeysAndNonces;

   PerMessageKeysAndNonces keys_and_nonces;

   encrypted_keys_and_nonces = EncryptWithLabel(
     external_receiver_public_key,
     "SemiPrivateMessageReceiver",
     SemiPrivateMessage.ciphertext,   /* context */
     keys_and_nonces)

   keys_and_nonces = DecryptWithLabel(
     external_receiver_private_key,
     "SemiPrivateMessageReceiver",
     SemiPrivateMessage.ciphertext,  /* context */
     encrypted_keys_and_nonces.kem_output,
     encrypted_keys_and_nonces.ciphertext)

   The KeyForExternalReceiver structure contains a hash of the
   ExternalReceiver as a reference and the encrypted_keys_and_nonces.

   /* Using the hash function of the group ciphersuite */
   ExternalReceiverRef = hash(ExternalReceiver)

   struct {
     ExternalReceiverRef external_receiver_ref;
     HPKECiphertext encrypted_keys_and_nonces;
   } KeyForExternalReceiver;

   The SemiPrivateMessage struct mirrors the PrivateMessage struct and
   adds the keys_for_external_receivers list.  The SemiPrivateContentAAD
   struct mirrors the PrivateContentAAD struct.  It likewise adds the
   keys_for_external_receivers list, and also adds a hash of the
   FramedContentTBS struct to insure that the content encrypted to an
   external receiver is that same as that provided to members.

   The SemiPrivateMessageContent struct is the same as
   PrivateMessageContent except for the addition of
   keys_for_external_receivers, and that application messages are not
   included.

Mahy                     Expires 2 February 2025                [Page 4]
Internet-Draft           MLS SemiPrivateMessage              August 2024

   Encryption of the ciphertext and encrypted_sender_data proceed in the
   same way for SemiPrivateMessage as for PrivateMessage.  Finally, as a
   safe wire format extension, the SemiPrivateMessage is wrapped in an
   ExtensionContent struct.

   struct {
       opaque group_id<V>;
       uint64 epoch;
       ContentType content_type;
       opaque authenticated_data<V>;
       KeyForExternalReceiver keys_for_external_receivers<V>;
       opaque encrypted_sender_data<V>;
       opaque ciphertext<V>;
   } SemiPrivateMessage;

   struct {
       select (PrivateMessage.content_type) {
           case proposal:
             Proposal proposal;
           case commit:
             Commit commit;
       };
       KeyForExternalReceiver keys_for_external_receivers<V>;
       FramedContentAuthData auth;
       opaque padding[length_of_padding];
   } SemiPrivateMessageContent;

   struct {
       opaque group_id<V>;
       uint64 epoch;
       ContentType content_type;
       opaque authenticated_data<V>;
       KeyForExternalReceiver keys_for_external_receivers<V>;
       opaque framed_content_tbs_hash<V>;
   } 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.

Mahy                     Expires 2 February 2025                [Page 5]
Internet-Draft           MLS SemiPrivateMessage              August 2024

5.  IANA Considerations

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              extensions-04>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Mahy                     Expires 2 February 2025                [Page 6]
Internet-Draft           MLS SemiPrivateMessage              August 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, <https://www.rfc-editor.org/rfc/rfc9420>.

Acknowledgments

   TODO acknowledge.

Author's Address

   Rohan Mahy
   Rohan Mahy Consulting Services
   Email: rohan.ietf@gmail.com

Mahy                     Expires 2 February 2025                [Page 7]