]> Kings College London

benjamin.dowling@kcl.ac.uk

Naval Postgraduate School

britta.hale@nps.edu

Phoenix R&D GmbH

konrad.kohbrok@datashrine.de

Phoenix R&D GmbH

ietf@raphaelrobert.com

Naval Postgraduate School

xisen.tian1@nps.edu

University of Sheffield

bhagya.wimalasiri@kcl.ac.uk

Web and Internet Transport QUIC QUIC MLS authenticated key exchange PCS This document describes how Messaging Layer Security (MLS) can be used in place of Transport Layer Security (TLS) to secure QUIC. 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 QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Recent advances in key exchange protocol design for communications under network delays, disruption, and supporting low latency has offered new alternative key establishment techniques in the form of continuous key agreement. One such continuous key agreement protocol has been standardized by the IETF, namely Messaging Layer Security (MLS) (RFC9420). The MLS key agreement handshake can be generalized for dynamic or degraded communications settings that do not support duplex links, have highly mobile devices, and/or require asynchronous communications. QUIC's use of TLS for key agreement was primarily designed for relatively short-lived client-server connections with synchronous key initialization over reliable network availablity. MLS offers an alternative to users for cases where network reliability, attentuation, or disruption are concerns through asychronous key updates which also provide post-compromise security, enabling long-lived sessions with controllable key refresh periodicity. The MLS key agreement handshake can be slotted into QUIC in a fairly straightforward manner, preserving other needed QUIC functionality. The combination of QUIC and MLS thus addresses a need for a robust security protocol in certain evolving communication environments.

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

Notation We use terms from MLS , TLS , and QUIC . Below, we have restated relevant terms and define new ones: Application Message: The private application data payload transported and encrypted by QUIC. Authentication Service (AS): An abstract architectural component of MLS that provides mechanisms for verifying the authenticity of group members, typically by issuing credentials (e.g., certificates) that bind identities to cryptographic keys Delivery Service (DS): An abstract architectural component of MLS for reliably delivering MLS messages (e.g., handshake or application messages) between group members while ensuring proper ordering. Control Message: An MLS Proposal or Commit message to change the cryptographic state, as opposed to application data. Key Derivation Function (KDF): A Hashed Message Authentication Code (HMAC)-based expand-and-extract key derivation function (HKDF) as described in RFC5869. Key Encapsulation Mechanism (KEM): A key transport protocol that allows two parties to obtain a shared secret based on the receiver's public key.

Scope While MLS is designed for group settings, we limit discussions in this document to the two-party communications case. This choice is deliberate to avoid significant changes to QUIC and MLS.

Requirements for Integration

QUIC-HS Requirements As an integrated secure transport protocol QUIC can be broken into two major components: a handshake layer (HS) responsible for key agreement and management and a record layer (RL) which provides secure (via HS keys) and reliable transport. Specifically, the HS layer requires the following from TLS as specified in RFC9001:

1. The handshake protocol must function as an authenticated key exchange (AKE) that produces distinct and unrelated keys for every connection where the server is always authenticated and the client is optionally authenticated.
2. Transport parameter authentication for both endpoints with additional confidentiality protection for the server transport parameters.
3. Provide means for authenticated negotiation of an application protocol.

With respect to (1) MLS provides authenticated key agreement to achieve the same outcome of AKE without exchanging key material. Using existing PKI certificates, communicating partners can generate MLS Key Packages to begin MLS sessions that produce indistinguishably random keys. Mutual authentication is enabled through asymmetric verification of credentials within MLS Key Packages. External commits which are used for "open" MLS groups can be used to allow an unauthenticated client to be added (i.e. optional client authentication). With respect to transport parameter negotiations in (2), MLS satisfies this with publication of a signed GroupInfo object inside Welcome messages that contains all the necessary information to join a group and a public key to encrypt a secret to the existing group members. For (3) Authenticated negotiation of application protocols can be achieved using the MLS Content Advertisement Extension in which would be included in the GroupInfo object.

MLS Requirements The prerequisits for MLS are the Delivery Service (DS) and Authentication Service (AS) functionalities as specified in RFC9750. A DS ensures MLS messages are delivered to all participants and enforces ordering of commits. For example, the DS can be a centralized server or a reliable transport protocol like TCP. An AS provides the issuance and verification of user credentials. For example, the AS can be any existing web Public Key Infrastructure (PKI) (e.g. certificate authority based scheme). For most cases using QUIC, the DS functionality is satisfied by QUIC RL through guarantees for reliable ordered delivery of messages just as it provides TLS. The AS functionality is provided through existing PKI certificates already used by TLS. In non-traditional settings (e.g. dynamic topologies, delay/disruption prone environments) where the DS functionality cannot be met by QUIC RL alone, other mechanisms to ensure (ordered) delivery MUST be employed. Likewise, the AS functionality must also exist. Details and recommendations for alternative strategies relating to either functionalities are outside the scope of this document.

Protocol Overview At a high level, MLS provides the traffic keys used to encrypt and authenticate QUIC's secure channel. In turn, QUIC's transport logic which handles ordering and reliable delivery of packets helps to maintain the MLS state. Note, additional mechanisms may be used to maintain MLS state in the event that QUIC transport is insufficient.

QUIC-MLS layer interactions

MLS Functionality As a stateful protocol, MLS leverages a cryptographic structure called a ratchet tree to establish and maintain a shared cryptographic group state. The tree's root is the group's shared secret and each MLS group member is represented by a unique leaf node containing their HPKE encryption public key and signature public key from the AS. Intermediate nodes contain the HPKE encryption public key pairs calculated by members of the subgroup they cover. This property enables efficiency in updates to the ratchet tree. MLS group operations (e.g. add, remove, update) trigger modifications from each leaf along the path of intermediate nodes from the leaf to the root, thereby ratchetting the group state forward into a new epoch. Group operations are solicited through the DS via MLS Proposal messages and are processed (aka committed) by MLS Commit messages. Therefore, a QUIC-MLS session with respect to the HS functionality, is the creation and modification of the MLS ratchet state (the shared state). Each epoch of an MLS session has a distinct asymmetric ratchet tree as previously described that seeds the MLS Key Schedule used to derive shared secrets used for key generation (e.g. via a Key Derivation Function). Values from the asymmetric ratchet tree and key schedule are used to derive a symmetric ratchet tree called the Secret Tree which is used to generate keys used for encrypting and authenticating application messages. QUIC-MLS provides keys from this symmetric ratchet tree to the QUIC record layer.

QUIC-MLS Execution An initiator may unilaterally start a QUIC-MLS session with a partner. They then update the keys throughout their communications by sending MLS updates with each message until either parties terminates the session by issuinng a (self) removal proposal and commit. An important distinction from QUIC-TLS is that key updates here are ratcheted in accordance with the MLS Key Schedule (see Section 8 of ) as to provide forward secrecy and post-compromise security rather than using QUIC's native key update mechanism (see Section 6.1 of ) which only provides forward secrecy. Furthermore, by attaching a configurable series of previous MLS Commit messages to each sending stream, we ensure that the protocol is both robust enough to handle truly asynchronous settings under eventually consistent DS but also flexible enough to adapt to synchronous settings with strongly constistent DS assumptions.

Initialization An initiating client can create MLS Key Packages based off of preloaded credentials obtained from the AS (i.e. via digital certificates) or through direct communications. In the absence of an AS, initators may use preinstalled long term signature keys from itself and the intended partner(s) to create the Key Packages necessary to start a session. The initiator uses the Key Packages to create an MLS Add proposal, which once committed to, starts the MLS session with the corresponding partner. In order for the other member to join and initialize their own cryptographic state, they will need to recieve their personalized MLS Welcome message. The initiator can wait to receive a MLS Commit from the partner or unilaterally commit their own Add proposal and thereby asynchronously intiate a session. If they unilaterally commmit their own Add proposal, then 0-RTT data may be sent along with these first batch of packets using the encryption key derived from the MLS group secret in accordance with the MLS Key Schedule (see Section 8 RFC9420). After the recipient verifies the initiator's Key Package and uses the Welcome message to construct the shared MLS state, the shared key is established and can be used by the record layer to commence secure communications via 1-RTT packets.

Updates When a member chooses to update the group key, they send an Update proposal and the other member commits to that proposal to ratchet the group state into the next epoch. Alternatively, one party may serve as the session admin with commit authority or may unilaterally update (via an empty commit): in either case, when an eventually consistent DS is used, they MUST attach the antecedent series of commits leading the the current epoch in order for the other member(s) to reconcile state agreement. In the two party case the series of commits reduces to simply the last commit. To tighten the FS/PCS compromise windows, senders MAY attach an update proposal with every data message sent.

Termination Session termination occurs when any party sends a (self) removal proposal and commit it. This MAY be sent multiplexed with the last data message or as an independent stream with no data message. For self removals in a two-party group, the proposer may terminate the session without waiting for commitment depending on application needs. The remove proposal shall be sent as the payload of a Crypto frame inside of a Handshake packet.

Resumption Similar to TLS where 0RTT keys are used to resume a session and quickly send encrypted application messages, MLS can make use of resumption pre-shared key (PSK) from historical epochs to send 0RTT encrypted data. With TLS, data sent encrypted using 0RTT key alone is not forward secret and suffers from replay attacks. With MLS, a member uses a Reinit proposal which describes the historical group state they belonged to to rejoin the group with their resumption PSK. Once the Reinit proposal is committed it cannot be duplicated (i.e. conflicting commit) making QUIC-MLS immune from the types of replay attacks that 0RRT TLS keys are vulnerable to. The Reinit proposal for QUIC-MLS is sent in in the Crypto frame of a Initial Packet, behaving similar to an External Join. With an encryption key derived from the new epoch secret (e.g. via HKDF Expand) of the new state, the 0-RTT data can be sent along with the Reinit proposal and commits.

Example Execution The following two-party QUIC-MLS execution illustrates initialization, updates, termination, and reinitialization of a session with per-message updates for the strictest security and commit transcripts for the an eventually consistent DS. What is shown can be relaxed to accommodate longer update windows and/or streamlined by reducing or eliminating commit transcripts for highly available and reliable networks which support a strongly consistent DS. Specifically, the protocol can be adapted to the synchronous and strongly consistent DS setting by removing the positive acknowledgement of latest commit HS packet (e.g. removing A's second Commit(Upd(B_0) message and B's HS{Commit(Upd(A_2)} message). The bracketed (e.g. optional) per-message ratchetting updates which follow each 1RTT data message shown may also be removed to allow more longer security windows (see Security Considerations).

Client A creates a two-party QUIC-MLS session with Client B, and then (optionally) updates the group state until termination (via self-removal). Each MLS message sent is accompanied by a configurable series of commits to proposals. Brackets ('[]') indicate implicit/optional communications steps. Handshake (HS), Init, and 0RTT packets wrap MLS messages indicated by braces ('{}'). Values following underscores ('_') indicate the associated epoch number. AB) | | | Commit(Add) | | | | | | Init{Welc(B)} | | | 0RTT{Enc(DataA_0))} | | |------------------------------>| | | [Verify(KeyPackageA)] | | | Process(Welcome) | | | ~ Key Established ~ | | | | | | 1RTT{Enc(DataB_0)}] | | | [HS{Upd(B_0)}] | | |<------------------------------| | | | | | [HS{Commit(Upd(B_0))}] | | | 1RTT{Enc(DataA_1))} | | | [HS{Upd(A_2)}] | | |------------------------------>| | | | | | [HS{Commit(Upd(B_0)), | | | Commit(Upd(A_2)}] | | | 1RTT{Enc(DataA_2))} | | | [HS{Upd(A_3)}] | | |------------------------------>| | | | | | [HS{Commit(Upd(A_2)), | | | Commit(Upd(A_3))}] | | | 1RTT{Enc(DataB_3)} | | | [HS{Upd'(B_4)}] | | |<------------------------------| | | | | | ... | | | | | | HS{Rmv(A_n)} | | |------------------------------>| | | | | | HS{Commit(Rmv(A_n))} | | |<------------------------------| | | | | | ... | | | | | | HS{Reinit(A_n)} | | | HS{Commit(Reinit)} | | | HS{Commit, Welcome} | | | 0RTT{Enc(DataA_n+2)} | | |------------------------------>| | | | | ]]>

TODO: Double check the reinit process -- is it better to just restart a new session? Seems like a new MLS session would have fewer steps in the two party case.

Packet Protection As with QUIC with TLS, QUIC-MLS protects packets with keys derived from the MLS state, using an AEAD algorithm selected common to the communicating partners from their KeyPackage objects. Some key changes to how QUIC with TLS does packet protection (see Section 5 of ) are as follows:

• Initial Packets, which should be used to send MLS Welcome messages that are already encrypted with the joiner's public key retain their AEAD encryption using the secret derived from initial salt and connection ID as specified in Section 5.2 of . Initial packets, which previously did not provide confidentiality or authentication to the payload, now carries a payload that DOES have confidentiality and authentication guarantees from MLS. NOTE: It may be redundant to keep the AEAD protection but removing it has downstream effects on Retry Packet usage/abuse. TODO: Decide if we want to even keep the Retry mechanism since we can form a MLS session unilaterally. ``
• Handshake Packets are proctected by keys derived from the MLS epoch secret.
• 0-RTT Packet Protection is provided by the traffic key computed from with the MLS Welcome message sent concurrently.

Key Derivation For QUIC-MLS, traffic keys are derived the same as they are for QUIC with TLS except that the MLS Epoch Secret is used in place of the TLS Master Secret. Furthermore, the Early Secret, an artifact of the TLS key schedule, is never derived as it is unused (see Section 7.1 of ). All other keys used to encrypt or sign public and private MLS group control messages are derived according to the MLS Key Schedule (see Section 8 of ) using the appropriate lables. For example the following shows how traffic secrets used to encrypt 1RTT packets are derived from the MLS Epoch Secret:

QUIC traffic key derivation from MLS Epoch Secret HKDF-Extract = MLS Epoch Secret | +-----> Derive-Secret(., "A ap 0") | = client_application_traffic_secret_0 | +-----> Derive-Secret(., "B ap 0") | = server_application_traffic_secret_0 ]]>

TODO: Technically MLS doesn't expose access to the epoch secret, if we want to abide by safe extensions then we ought to use exporter secret here right?

Key Deletion In general, keys should be deleted immediately after they are consumed. The key deletion schedule of MLS aligns with QUIC's policies for discarding keys in that members may keep unconsumed values for handling out-of-order message delivery. Therefore, keys should be deleted in accordance first with the QUIC policies for discarding keys and then the MLS Key Deletion Schedule (Section 9.2 of ) for MLS specific values.

Message Framing The main interface from QUIC used by MLS are the CRYPTO and NEW_TOKEN frames. As payloads of Initial, Handshake, and 0RTT packets, the CRYPTO frame will carry a majority of MLS Handshake messages that facilitate group control. Initial packets only carry the MLS Welcome and External Join messages to add new users to a group. Previous group members who wish to rejoin a group (using their MLS Resumption Preshared Keys) may use the NEW_TOKEN frame inside of Initial or Retry packets to resume membership in the session with their PreSharedKey proposal as tokens. Handshake packets carry CRYPTO frames that have as payloads all other MLS proposals and commits in accordance with RFC9420.

QUIC-MLS packet and frame structures for carrying MLS messages (e.g. proposals, commits, welcome, etc.) } NEW_TOKEN_FRAME{ Type (i) = 0x07, Token Length (i), Token = MLS_PreSharedKey_Proposal } ]]>

Security Considerations

Attacks on Authentication While message integrity is provided by the symmetric key used in AEAD, insider attacks on non-repudiation (e.g., source forgery) on application messages may still be possible because QUIC headers and payloads aren't signed. While the content (including sender information) is protected by AEAD which uses the symmetric group key, a malicious insider may still be able decrypt, modify, and re-encrypt the content using the same symmetric group key that they can compute. Thus, application messages sent by one member may be reordered or modified by another. However, in terms of group control, non-repudiation is unaffected because handshake messages are protected as signed MLS private messages.

Ratchet Window The frequency of updates to the MLS group state can be adjusted as desired based on either time or number of messages. Following the maximum 604800 seconds (7 day) limit of the ticket_lifetime from TLS that forces a new DH handshake to establish fresh secrets, QUIC-MLS epochs must similarly not exceed 7 days in duration without an update.

Use of 0RTT QUIC-MLS use of 0-RTT differs from QUIC-TLS in that a fresh key generated by the MLS state is used instead of using a pre-shared key generated from a previous TLS session between the communicating parties. QUIC-TLS uses 0-RTT and 1-RTT to explicitly differentiate the security levels but in QUIC-MLS their security levels are the same since they both are based on fresh randomness (akin to how 1-RTTs are protected by ephemeral Diffie Hellman keys). Unlike the caveats to using 0-RTTs for QUIC-TLS to thwart against certain types of replay attacks, QUIC-MLS has none.

IANA Considerations TODO

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. 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. 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. Informative References Phoenix R&D The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API.

Acknowledgments TODO acknowledge.