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<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
   (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<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;

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<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 (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,
              <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>.

   [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>.

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]