Transport Layer Security                                      R. HousleyInternet-Draft                                            Vigil SecurityIntended status: Standards Track                         5 February 2026Expires: 9 August 2026                   Using the MLS Handshake in TLS 1.3                draft-housley-tls-using-mls-handshake-00Abstract   This document specifies an extension to the Transport Layer Security   (TLS) Protocol Version 1.3 that allows TLS clients and servers to use   the Message Layer Security (MLS) Protocol handshake to establish the   shared secret instead to the traditional shared secret establishment   mechanism.  The MLS protocol provides straightforward mechanism to   update the shared secret that can be initiated by either the client   or the server during the TLS session, and each epoch provides forward   security and post-compromise security.About This Document   This note is to be removed before publishing as an RFC.   The latest revision of this draft can be found at TBD.  Status   information for this document may be found at   https://datatracker.ietf.org/doc/draft-housley-tls-using-mls-   handshake/.   Discussion of this document takes place on the Transport Layer   Security mailing list (mailto:tls@ietf.org), which is archived at   https://mailarchive.ietf.org/arch/browse/tls/.  Subscribe at   https://www.ietf.org/mailman/listinfo/tls/.   Source for this draft and an issue tracker can be found at   https://github.com/russhousley/draft-housley-tls-using-mls-handshake.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/.Housley                   Expires 9 August 2026                 [Page 1]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   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 9 August 2026.Copyright Notice   Copyright (c) 2026 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   3.  Motivation and Design Rationale . . . . . . . . . . . . . . .   3   4.  Extension Overview  . . . . . . . . . . . . . . . . . . . . .   4   5.  The "tls_using_mls_handshake" Extension . . . . . . . . . . .   6   6.  MLS Handshake Messages  . . . . . . . . . . . . . . . . . . .   7     6.1.  Establishing the Initial TLS Shared Secret with MLS . . .   8     6.2.  Updating the TLS Shared Secret with MLS . . . . . . . . .   9     6.3.  Resumption  . . . . . . . . . . . . . . . . . . . . . . .  10   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  131.  Introduction   This document specifies an extension to the Transport Layer Security   (TLS) Protocol Version 1.3 [RFC9846] that allows TLS clients and   servers to use the Message Layer Security (MLS) Protocol [RFC9420]   handshake to establish the shared secret.  The resulting shared   secret is used in the TLS key schedule to derive all of the   cryptographic keying material for the TLS 1.3 protocol.  The MLSHousley                   Expires 9 August 2026                 [Page 2]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   protocol provides a straightforward mechanism to update the shared   secret, and either the client or the server can initiate the update   during the TLS session.  The period of time during which one shared   secret is used is called an epoch.  An epoch provides forward   security and post-compromise security.2.  Terminology   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.3.  Motivation and Design Rationale   There are operational motivations and security motivations for using   the MLS handshake to manage TLS shared secrets.   An operational motivation is the straightforward mechanism for shared   secret update that can be initiated by either the client or the   server.  The initial shared secret is based on the client KeyPackage   and the server Welcome, which are carried in the TLS 1.3 ClientHello   and the ServerHello, respectively.  The KeyPackage and Welcome are   specified in [RFC9420].  At any time during the TLS session, the   client or server can update the keying material in their LeafNode of   the MLS ratchet tree, which results in the computation of a fresh   epoch, including a fresh TLS shared secret.  By discarding all stale   secret values, each epoch provides forward security and post-   compromise security.   To apply the MLS protocol in TLS 1.3, the client provide a   KeyPackage.  In MLS, the KeyPackages are distributed by the Delivery   Service (DS), but in the TLS environment, the the client KeyPackage   is sent directly to the server in an extension in the ClientHello   message.  Once the TLS session is established, the client or server   can provide an update to the keying material in their LeafNode in a   mls_handshake message as specified in Section 6.  Each KeyPackage is   intended to be used only once.  Reuse of KeyPackages can lead to   replay attacks.   A security motivation is the ability to obtain both forward secrecy   and post-compromise security, especially for long-lived TLS sessions.   Forward secrecy means that TLS records sent at a certain point in   time are secure in the face of later compromise of a the peer.  Post-   compromise security means that TLS records are secure even if the   communicating peer was compromised at some point in the past.Housley                   Expires 9 August 2026                 [Page 3]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   Forward secrecy between epochs is provided by deleting private keys   from past versions of the MLS ratchet tree, as this prevents old   session secrets from being re-derived.  Forward secrecy within an   epoch is possible with the MLS protocol, but that feature is not   currently supported in TLS.   Post-compromise security (PCS) is provided between epochs by the   client or server regularly updating their leaf key in the MLS ratchet   tree.  Updating their leaf key prevents shared secrets from   continuing to be encrypted to public keys whose private keys had   previously been compromised.   Note that a client or server sending an update of the keying material   for their LeafNode does not achieve PCS until the peer processes the   MLS Commit.  That is, the PCS guarantees come into effect when the   peer processes the relevant Commit, not when the sender creates it.   This specification makes use of the two-party profile for MLS that is   defined in [I-D.kohbrok-mls-two-party-profile].4.  Extension Overview   This section provides a brief overview of the   "tls_using_mls_handshake" extension.   The client includes the "tls_using_mls_handshake" extension in the   ClientHello message.  The "tls_using_mls_handshake" extension MUST   contain the client KeyPackage.   If the client includes both the "tls_using_mls_handshake" extension   and the "early_data" extension, then the server MUST terminate the   connection with an "illegal_parameter" alert.   If the server is willing to use MLS to establish the shared secret,   then the server includes the "tls_using_mls_handshake" extension in   the ServerHello message.  The "tls_using_mls_handshake" extension   MUST contain the Welcome message created by the server using the   client KeyPackage.   When the "tls_using_mls_handshake" extension is successfully   negotiated, the TLS 1.3 key schedule processing depends on the shared   secret produced by the MLS ratchet tree and MLS key schedule.   The server MUST validate the client KeyPackage.  KeyPackage   validation depends on the GroupContext object, which captures MLS   state:Housley                   Expires 9 August 2026                 [Page 4]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026      struct {          ProtocolVersion version = mls10;          CipherSuite cipher_suite;          opaque group_id<V>;          uint64 epoch;          opaque tree_hash<V>;          opaque confirmed_transcript_hash<V>;          Extension extensions<V>;      } GroupContext;   The fields in the MLS state have the following semantics for the TLS   session:   *  The cipher_suite is the cipher suite from the client KeyPackage,      and the same cipher_suite MUST be used in the Welcome generated by      the server.   *  The group_id field is an application-defined identifier; it MUST      contain "tls13".   *  The epoch field represents the current version, starting with a      value of 0x0000000000000000.   *  The tree_hash field contains a commitment to the contents of the      group's ratchet tree and the credentials for the members of the      group, which are always only the TLS client and the TLS server.      See Section 7.8 of [RFC9420] for details.   *  The confirmed_transcript_hash field contains a running hash over      the MLS messages that led to this state.  See Section 8.2 of      [RFC9420] for details.   *  The extensions field contains the details of any MLS protocol      extensions that apply to the group.  See Section 12.1.7 of      [RFC9420] for details.   The server generates Welcome message, which MUST include an extension   of type ratchet_tree to ensure that the client and the server have   the same MLS ratchet tree.  In MLS the ratchet tree is often provided   by the Delivery Service, which is not an option in TLS.  The Welcome   message provides the client with the state of the group after it is   created by the server:      struct {        CipherSuite cipher_suite;        EncryptedGroupSecrets secrets<V>;        opaque encrypted_group_info<V>;      } Welcome;Housley                   Expires 9 August 2026                 [Page 5]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   See Section 12.4.3.1 of [RFC9420] for details regarding creations and   processing of the Welcome message.5.  The "tls_using_mls_handshake" Extension   This section specifies the "tls_using_mls_handshake" extension, which   MAY appear in the ClientHello message and ServerHello message.  It   MUST NOT appear in any other messages.  The "tls_using_mls_handshake"   extension MUST NOT appear in the ServerHello message unless the   "tls_using_mls_handshake" extension appeared in the preceding   ClientHello message.  If an implementation recognizes the   "tls_using_mls_handshake" extension and receives it in any other   message, then the implementation MUST abort the handshake with an   "illegal_parameter" alert.   The general extension mechanisms enable clients and servers to   negotiate the use of specific extensions.  Clients request extended   functionality from servers with the extensions field in the   ClientHello message.  If the server responds with a HelloRetryRequest   message, then the client sends another ClientHello message as   described in Section 4.1.2 of [RFC9846], including the same   "tls_using_mls_handshake" extension as the original ClientHello   message, or aborts the handshake.   Many server extensions are carried in the EncryptedExtensions   message; however, the "tls_using_mls_handshake" extension is carried   in the ServerHello message.  The "tls_using_mls_handshake" extension   is only present in the ServerHello message if the server recognizes   the "tls_using_mls_handshake" extension and the server is willing to   use MLS key management and authentication in lieu of the traditional   TLS 1.3 key management and authentication.   The Extension structure is defined in [RFC9846]; it is repeated here   for convenience.      struct {        ExtensionType extension_type;        opaque extension_data<0..2^16-1>;      } Extension;   The "extension_type" identifies the particular extension type, and   the "extension_data" contains information specific to the particular   extension type.   This document specifies the "tls_using_mls_handshake" extension,   adding one new type to ExtensionType:Housley                   Expires 9 August 2026                 [Page 6]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026      enum {       tls_using_mls_handshake(TBD0),       (65535)      } ExtensionType;   The "tls_using_mls_handshake" extension is relevant when the client   and server are willing to use the MLS protocol for key management and   authentication.  The "tls_using_mls_handshake" extension provides the   client KeyPackage and the server KeyPackage needed to build the MLS   ratchet tress for the client and server.  The KeyPackage structure is   defined in Section 10 of [RFC9420].  The "tls_using_mls_handshake"   extension has the following syntax:      struct {        select (Handshake.msg_type) {            case client_hello: KeyPackage;            case server_hello: Welcome;        };      } TLSUsingMLSHandshake;   The TLS client creates its own KeyPackage for inclusion in the   ClientHello.  The KeyPackage includes a cipher suite and any MLS   extensions that the client desires.   If the TLS server supports MLS handshake, then the TLS server   inspects KeyPackage from the ClientHello to determine whether the   cipher suite is supported and acceptable, whether all of the client   provided MLS extensions are supported and acceptable, and whether the   client credential is valid.  If all of these checks are successful,   then the TLS server creates the MLS group and sends the Welcome   message in the ServerHello.6.  MLS Handshake Messages   If the "tls_using_mls_handshake" extension is successfully   negotiated, then the client and the server can update the keying   material in their LeafNode by encapsulating inside a TLS handshake   message with a "mls_handshake" type.  Only the MLS Commit message is   needed to achieve this capability, but any MLS handshake message   could be carried in this TLS handshake message to ensure future   compatibility.      enum {        mls_handshake(TBD1),        (255)      } HandshakeType;Housley                   Expires 9 August 2026                 [Page 7]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   In the TLS protocol, the "mls_handshake" message encapsulates one of   the MLS Handshake messages specified in   [I-D.kohbrok-mls-two-party-profile] for key update or resumption.   When updating the keying material in the MLS LeafNode, the Commit   message MUST include the update by value.  The TwoPartyMLSMessage   types are:      struct {        ProtocolVersion version = mls10;        uint16 tpmlsmt;        select (TwoPartyMLSMessage.tpmlsmt) {            case mls_connection_update:                Commit commit;            case mls_epoch_key_update:                uint64 epoch;            case mls_resumption_request:                Commit commit;            case mls_resumption_response:                Commit commit;        };      } TwoPartyMLSMessage;   The format for each message is defined in [RFC9420].   Since the TLS environment does not include a Delivery Service, the   MLS Commit message MUST contain the proposal to be applied by value   as specified in Section 12.4 of [RFC9420].6.1.  Establishing the Initial TLS Shared Secret with MLS   The TLS server creates the MLS group, add it adds the client with the   KeyPackage provided in the ClientHello, which results in a group of   two members.  The server send the Welcome message to the client in   the ServerHello.  The Welcome can include any MLS extensions that are   supported by the client KeyPackage.   Upon successful completion of the MLS handshake, the exporter_secret   produced by the MLS key schedule is used to derive the TLS shared   secret, this value is referred to as the "Handshake Secret" in   [RFC9846].  The TLS shared secret is derived as:      MLS-Exporter(Label, Context, Length) =          ExpandWithLabel(DeriveSecret(exporter_secret,              "TLS shared secret"), "exported",              Hash(Context), Length)   Note: Length is the size of the TLS shared secret to be input into   the TLS key schedule.Housley                   Expires 9 August 2026                 [Page 8]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 20266.2.  Updating the TLS Shared Secret with MLS   After the initial MLS handshake is successfully completed or a   session is resumed, the client or the server can update the session   key using a Commit message, which results in a new TLS shared secret.   Once the new MLS key schedule is computed, a fresh "Handshake Secret"   is exported to compute a new TLS key schedule.   To enforce the forward secrecy and post-compromise security, the   client and the server periodically update the keys that represent   them to the MLS group by sending a Commit message that includes an   Update by value for their own LeafNode.  See Section 12.1.2 of   [RFC9420] for details.   Once the Commit message is sent, some traffic using the previous   keying material might still be in flight.  Once traffic using the new   keying material is received, then the stale keying material can   safely be discarded.   The following illustrates the update of the TLS shared secret.   Client                            Server   (Initiator)                       (Responder)     /------------------------------------------\    |            Initial Handshake               |     \------------------------------------------/   [Application Data]N    -------->                          <-------- [Application Data]N     /------------------------------------------\    |             Some time later ...            |     \------------------------------------------/   mls_connection_update  -------->                                    # no epoch change yet                          <-------- [Application Data]N                                    # confirms epoch change                          <-------- mls_epoch_key_update=N+1                          <-------- [Application Data]N+1   [Application Data]N+1  -------->                          <-------- [Application Data]N+1   Legend:       []N Indicates messages protected with keys derived from epoch NHousley                   Expires 9 August 2026                 [Page 9]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 20266.3.  Resumption   After the initial MLS handshake is successfully completed, a session   can resume as long as the client and server have retained the MLS   group state.  The normal TLS 1.3 resumption process is described in   Section 2.2 of [RFC9846].   To cryptographically separate the resumed session from the original   session and ensure forward secrecy and post-compromise security, the   client and the server each update their nodes in the MLS ratchet tree   with a Commit message.   If the client had sent a Update before the TLS session was   disconnected, and the client was waiting for a EpochKeyUpdate, then   the client MUST use that pending Update message as the basis for the   Commit message.   If the server had sent a Update before the TLS session was   disconnected, and the server was waiting for a EpochKeyUpdate, then   the server MUST use that pending Update message as the basis for the   Commit message.   The following illustrates the update of the TLS shared secret after   resumption.Housley                   Expires 9 August 2026                [Page 10]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026   Client                            Server   (Initiator)                       (Responder)     /------------------------------------------\    |             Initial Handshake              |     \------------------------------------------/   [Application Data]N    -------->                          <-------- [Application Data]N     /------------------------------------------\    |  Disconnect and resume some time later ... |     \------------------------------------------/   mls_resumption_request -------->                          <-------- mls_resumption_response                                    # confirms epoch changes                          <-------- [Application Data]N+2   [Application Data]N+2  -------->                          <-------- [Application Data]N+2   Legend:       []N Indicates messages protected with keys derived from epoch N7.  Security Considerations   The security considerations in [RFC9846] and [RFC9420] apply.8.  IANA Considerations   IANA is requested to update the "TLS ExtensionType Values" registry   [IANA-TLS-EXT] to include "tls_using_mls_handshake" with a value of   TBD0 and the list of messages "CH, SH" in which the   "tls_using_mls_handshake" extension is allowed to appear.   IANA is requested to update the "TLS HandshakeType Values" registry   [IANA-TLS-HS] to include "mls_handshake" with a value of TBD1, a   DTLS-OK value of "Y", and a Reference to this document (once it is   published as an RFC).   IANA is requested to update the "MLS Exporter Labels" registry   [IANA-MLS-EL] to include "TLS shared secret", a Recommended value of   "N", and a Reference to this document (once it is published as an   RFC).9.  ReferencesHousley                   Expires 9 August 2026                [Page 11]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 20269.1.  Normative References   [I-D.kohbrok-mls-two-party-profile]              Kohbrok, K. and R. Robert, "A two-party profile for MLS",              Work in Progress, Internet-Draft, draft-kohbrok-mls-two-              party-profile-00, 3 February 2026,              <https://datatracker.ietf.org/doc/html/draft-kohbrok-mls-              two-party-profile-00>.   [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>.   [RFC9846]  Rescorla, E., "The Transport Layer Security (TLS) Protocol              Version 1.3", RFC 9846, February 2026,              <https://www.rfc-editor.org/rfc/rfc9846>.9.2.  Informative References   [IANA-MLS-EL]              IANA, "TMLS Exporter Labels", n.d.,              <https://www.iana.org/assignments/mls/mls.xhtml#mls-              exporter-labels>.   [IANA-TLS-EXT]              IANA, "TLS ExtensionType Values", n.d.,              <https://www.iana.org/assignments/tls-extensiontype-              values/tls-extensiontype-values.xhtml>.   [IANA-TLS-HS]              IANA, "TLS HandshakeType Values", n.d.,              <https://www.iana.org/assignments/tls-parameters/tls-              parameters.xhtml#tls-parameters-7>.Acknowledgments   Thanks to Sean Turner, Raphael Robert, and Konrad Kohbrok for   providing constructive comments.Housley                   Expires 9 August 2026                [Page 12]Internet-Draft     Using the MLS Handshake in TLS 1.3      February 2026Author's Address   Russ Housley   Vigil Security, LLC   Email: housley@vigilsec.comHousley                   Expires 9 August 2026                [Page 13]