| Internet-Draft | MLS-TLS | February 2026 |
| Kohbrok & Robert | Expires 23 August 2026 | [Page] |
This document details how the Messaging Layer Security (MLS) protocol can be combined with the Transport Layer Security (TLS) record layer to yield the MLS-TLS secure channel protocol. In this composed protocol, MLS acts as a continuous key agreement protocol that allows initiator and responder to protect both past and future messages in case of key material compromise. As such, MLS-TLS is suitable for long-lived connections. MLS-TLS also inherits the modularity of MLS and can be configured with post-quantum secure ciphersuites.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://kkohbrok.github.io/draft-kohbrok-mls-tls/draft-kohbrok-mls-tls.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kohbrok-mls-tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/kkohbrok/draft-kohbrok-mls-tls.¶
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."¶
This Internet-Draft will expire on 23 August 2026.¶
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.¶
This document builds on the two-party profile for MLS [I-D.draft-kohbrok-mls-two-party-profile] and combines it with the record layer of TLS 1.3 [RFC8446] to yield a secure channel protocol. The composition of both protocols is seamless due to the modular design of TLS 1.3 and MLS's capability to act as a continuous key agreement protocol. After the initial handshake, initiator and responder can tunnel MLS commits through the secure channel to update their key material. Key material updates allow both parties to achieve forward-secrecy and post-compromise security.¶
MLS is a secure messaging protocol that can also act as a continuous key agreement protocol. In particular, all parties in an MLS group can not only exchange encrypted messages, but also export shared key material for use outside of MLS.¶
Within an MLS group, each member has distinct public key material that it can update by sending a commit that updates its own key material and the key material exported from the group. Such an update allows a client to achieve forward secrecy (FS) and post-compromise security (PCS). FS and PCS can be intuitively understood as follows.¶
FS is the property that prevents an adversary from being able to decrypt messages sent in the past even if it obtains current key material. Group members achieve FS by deleting previously exported key material after an update.¶
PCS is the property that prevents an adversary from decrypting future messages even if it obtains current key material. Clients can achieve this property by generating new key material and encrypting it to other group members. PCS is achieved when other group members update the public keys of the updating client.¶
The MLS-TLS protocol is a two-party protocol that establishes a secure channel between an initiator and a responder. The protocol makes use of MLS's capability to export key material and uses said key material to initialize the record protection layer of the TLS protocol as defined in Section 5 of [RFC8446]. As such MLS essentially replaces the TLS 1.3 handshake.¶
The specific protocol flow for how initiator and responder establish an MLS group and how the exported keys are subsequently updated is described in [I-D.draft-kohbrok-mls-two-party-profile], which defines a two-party profile for MLS. In particular, the two-party profile describes how updates are coordinated and when exported keys are ready to be used, in this case to initialize or update the TLS record layer.¶
The ability of both parties to achieve PCS by sending MLS commits in-band is increasingly valuable the higher the risk of compromise of either party. As such, the MLS-TLS protocol is specifically suited for scenarios where connections tend to be long-lived. For example, in cases where connection (re)establishment is costly.¶
MLS is a modular design. When using it as a continuous key agreement protocol, this yields two advantages: Post-quantum capable cryptographic abstractions and arbitrary credential types.¶
MLS's ciphersuites use Key Encapsulation Mechanisms (KEMs) and signature algorithms as abstractions. This allows the use of a variety of cryptographic algorithms including post-quantum secure ones for both confidentiality and authentication. See [I-D.draft-ietf-mls-pq-ciphersuites] for hybrid and pure post-quantum secure ciphersuites.¶
MLS does not require clients to use any specific credential type as long as they are provided with signature keys to sign MLS messages. MLS-TLS is thus largely agnostic to how the application binds a client's identity to its signature public key.¶
The MLS-TLS protocol consists of three phases.¶
Initial key agreement, where initiator and responder agree on key material using the MLS two party profile. At the end of this phase, both parties are members of an MLS group that is used in the other phases to generate key material.¶
Secure channel phase, where initiator and responder can encrypt data using the TLS 1.3 record layer protocol. The encryption keys are derived from the MLS group created during the initial key agreement phase. During the secure channel phase, initiator and responder can tunnel MLS commits through the secure channel to update their key material.¶
Resumption, where initiator or responder can resume a previously interrupted connection without having to repeat phase 1, including the ability to send data in the first flight of messages.¶
For more details on the initial key agreement, resumption, as well as how message updates work, see [I-D.draft-kohbrok-mls-two-party-profile].¶
Both after the initial key agreement phase and the resumption phase, initiator and responder derive key material from the MLS group created during the initial key agreement phase.¶
The client_application_traffic_secret and the
server_application_traffic_secret required by the record layer are derived as
follows.¶
server_application_traffic_secret =
MLS-Exporter("MLS-TLS s ap traffic", [], Length)
client_application_traffic_secret =
MLS-Exporter("MLS-TLS c ap traffic", [], Length)
¶
Where MLS-Exporter is defined in [RFC9420] and Length is the size of the secret required by the TLS record layer.¶
Application data is encoded as described in Section 5.1 of [RFC8446] and protected as described in Section 5.2 of [RFC8446]. The keys derived from the MLS group as described in Section Section 6 are used to calculate the traffic keys for record protection as described in Section 7.3 of [RFC8446].¶
The application traffic secrets MUST be deleted after deriving the traffic keys.¶
The MLS two party profile allows both parties to update the MLS group created in
the initial key agreement phase. In the context of MLS-TLS, these
ConnectionUpdate and EpochKeyUpdate messages (as defined in
[I-D.draft-kohbrok-mls-two-party-profile]) are sent in place of key update
messages defined in [RFC8446]. Concretely, they are serialized and sent as
the content of a TLSInnerPlaintext message with type set to handshake.¶
TODO: The two-party profile I-D should define a message similar to [RFC9420]'s MLSMessage, which contains either a ClientHello, ServerHello, ConnectionUpdate or EpochKeyUpdate. This is to allow recipients to know what to deserialize when they receive an in-band update message.¶
When a party is ready to start using the key material as specified in Section 4 of [I-D.draft-kohbrok-mls-two-party-profile], the client derives new application traffic secrets as specified in Section 6. These secrets are then used to further derive the traffic keys for record protection as described in Section 7.3 of [RFC8446].¶
Key material that is replaced in this way MUST be deleted.¶
TODO: Define a component that the initiator needs to include in its leaf node and that MUST be included in the context of the MLS group. This purpose of the component is to clearly mark the individual messages for use in the context of MLS-TLS.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶