Transport Layer Security R. Housley Internet-Draft Vigil Security Intended status: Standards Track 5 February 2026 Expires: 9 August 2026 Using the MLS Handshake in TLS 1.3 draft-housley-tls-using-mls-handshake-00 Abstract 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 1. 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 MLS Housley 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; uint64 epoch; opaque tree_hash; opaque confirmed_transcript_hash; Extension extensions; } 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; opaque encrypted_group_info; } 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 2026 6.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 N Housley Expires 9 August 2026 [Page 9] Internet-Draft Using the MLS Handshake in TLS 1.3 February 2026 6.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 N 7. 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. References Housley Expires 9 August 2026 [Page 11] Internet-Draft Using the MLS Handshake in TLS 1.3 February 2026 9.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, . [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, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, February 2026, . 9.2. Informative References [IANA-MLS-EL] IANA, "TMLS Exporter Labels", n.d., . [IANA-TLS-EXT] IANA, "TLS ExtensionType Values", n.d., . [IANA-TLS-HS] IANA, "TLS HandshakeType Values", n.d., . 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 2026 Author's Address Russ Housley Vigil Security, LLC Email: housley@vigilsec.com Housley Expires 9 August 2026 [Page 13]