]> Vigil Security, LLC

housley@vigilsec.com

Security Transport Layer Security 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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

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 when, and only when, they appear in all capitals, as shown here.

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

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: ; 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 for details.
• The confirmed_transcript_hash field contains a running hash over the MLS messages that led to this state. See for details.
• The extensions field contains the details of any MLS protocol extensions that apply to the group. See 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: ; opaque encrypted_group_info; } Welcome; ]]> See for details regarding creations and processing of the Welcome message.

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 , 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 ; it is repeated here for convenience. ; } 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: 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 . The "tls_using_mls_handshake" extension has the following syntax: 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.

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. In the TLS protocol, the "mls_handshake" message encapsulates one of the MLS Handshake messages specified in 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: The format for each message is defined in . 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 .

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 . The TLS shared secret is derived as: Note: Length is the size of the TLS shared secret to be input into the TLS key schedule.

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

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

Security Considerations The security considerations in and apply.

IANA Considerations IANA is requested to update the "TLS ExtensionType Values" registry 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 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 to include "TLS shared secret", a Recommended value of "N", and a Reference to this document (once it is published as an RFC).

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Independent Phoenix R&D Phoenix R&D TODO Abstract Informative References IANA n.d. IANA n.d. IANA n.d.

Acknowledgments Thanks to Sean Turner, Raphael Robert, and Konrad Kohbrok for providing constructive comments.