A Cryptographic Analysis of the TLS 1.3 Handshake Protocol

We analyze the handshake protocol of the Transport Layer Security (TLS) protocol, version 1.3. We address both the full TLS 1.3 handshake (the one round-trip time mode, with signatures for authentication and (elliptic curve) Diffie–Hellman ephemeral ((EC)DHE) key exchange), and the abbreviated resumption/“PSK” mode which uses a pre-shared key for authentication (with optional (EC)DHE key exchange and zero round-trip time key establishment). Our analysis in the reductionist security framework uses a multi-stage key exchange security model, where each of the many session keys derived in a single TLS 1.3 handshake is tagged with various properties (such as unauthenticated versus unilaterally authenticated versus mutually authenticated, whether it is intended to provide forward security, how it is used in the protocol, and whether the key is protected against replay attacks). We show that these TLS 1.3 handshake protocol modes establish session keys with their desired security properties under standard cryptographic assumptions.


Introduction
The Transport Layer Security (TLS) protocol is one of the most widely deployed cryptographic protocols in practice, protecting numerous web and e-mail accesses every day. The TLS handshake protocol allows a client and a server to authenticate each other and to establish a key, and the subsequent record layer protocol provides confidentiality and integrity for communication of application data. Originally developed as the Secure Sockets Layer (SSL) protocol version 3 in 1996, TLS version 1.0 was standardized by the Internet Engineering Task Force (IETF) in 1998 [37], with subsequent revisions to version 1.1 (2006) [48] and version 1.2 (2008) [49]. Despite its large-scale deployment, or perhaps because of it, we have witnessed frequent successful attacks against TLS. Starting around 2009, there were many practical attacks on the then-current version 1.2 of TLS that received significant attention, exploiting weaknesses in underlying cryptographic primitives (such as weaknesses in RC4 [4]), errors in the design of the TLS protocol (e.g., BEAST [51], the Lucky 13 attack [7], the triple handshake attack [13], the POODLE attack [84], the Logjam attack [2]), or flaws in implementations (e.g., the Heartbleed attack [35], state machine attacks (SMACK [10])).

Development and Standardization of TLS 1.3
With concerns rising about the security of TLS version 1.2 due to the many attacks, but also motivated by desire to deprecate old algorithms, enhance privacy, and reduce connection establishment latency, in 2014 the IETF's TLS working group initiated a multi-year process to develop and standardize a new version of TLS, eventually called version 1.3. From 2014 through 2018, a total 29 drafts of TLS 1.3 were published, with active feedback from industry and academia, including extensive security analyses by various teams from academia (see [89] for a chronicle of the development and analysis of TLS 1.3). The document standardizing TLS 1.3, RFC 8446 [90], was published in August 2018 and has already seen widespread adoption.
From a cryptographic perspective, major design changes in TLS 1.3 compared to version 1.2 include: (1) encrypting some handshake messages with an intermediate session key, to provide confidentiality of handshake data such as the client certificate; (2) signing the entire handshake transcript for authentication; (3) including hashes of handshake messages in a variety of key calculations; (4) using different keys to encrypt handshake messages and application data; (5) deprecating a variety of cryptographic algorithms (including RSA key transport, finite-field Diffie-Hellman key exchange, SHA-1, RC4, CBC mode, MAC-then-encode-then-encrypt); (6) using modern authenticated encryption with associated data (AEAD) schemes for protecting application data; and (7) providing handshakes with fewer message flows to reduce latency.
There are two primary modes of the TLS 1.3 handshake protocol. One is the full, one round-trip time (1-RTT) handshake, which uses public-key certificates for server and (optionally) client authentication, and (elliptic curve) Diffie-Hellman ephemeral ((EC)DHE) key exchange, inspired by Krawczyk's 'SIGn-and-MAc' (SIGMA) design [72]. Several session keys are established for a variety of purposes in this mode: to encrypt part of the handshake, to enable export of keying material to other applications, for session resumption, and of course to encrypt application data. This mode gets its name from the fact that application data can be sent from the client to the server with the handshake's completion after a full round trip, meaning there is one round-trip time (1-RTT) until the first application message can be sent (not counting non-TLS networking operations such as DNS lookups or the TCP 3-way handshake).
The other primary mode of the TLS 1.3 handshake protocol is the resumption or preshared key (PSK) mode, in which authentication is based on a symmetric pre-shared key, with optional (EC)DHE key exchange for forward secrecy; this generalizes the abbreviated session resumption handshake from earlier versions of TLS. The PSK mode can optionally be augmented with a zero round-trip time (0-RTT) key establishment, allowing the client to send-along with its first TLS flow-application data encrypted under a key derived from the PSK.

Security Analyses of TLS TLS 1.2 and Prior Versions
A long line of work has analyzed various versions of the SSL/TLS protocol using both formal methods and reductionist security proofs. In the reductionist security paradigm, early work [56,63,86] on the handshake protocol dealt with modified or truncated versions of the protocol, necessary because TLS 1.2 and earlier did not have strict key separation: the session key was also used to encrypt messages within the handshake protocol, barring security proofs in strong indistinguishabilitybased authenticated key exchange models in the Bellare-Rogaway [25] style. There were also formalizations of the security of the authenticated encryption in the record layer [71,87]. A major milestone in reductionist analyses of TLS was the development of the authenticated and confidential channel establishment (ACCE) security model which allowed for the combined analysis of a full TLS 1.2 handshake and secure channel in a single model [64], sidestepping the aforementioned key separation issue; this work was followed by a range of other works analyzing the security of various aspects of TLS 1.2 [50,58,70,76,81]. Other approaches to proving the security of TLS 1.2 within the reductionist security paradigm include a range of modular and compositional approaches [21] as well as approaches that combine formal analysis and reductionist security [18,19].

TLS 1.3 Drafts
The handshake protocol in initial drafts of TLS 1.3 was based in part on the OPTLS protocol [77]. There were a variety of investigations on the security of various drafts throughout the TLS 1.3 standardization process. Using the reductionist security paradigm, there have been analyses of the handshake protocol [15,38,39,53,55,69,75,77,82] and the record layer [24,27,60,80,88]. There has been a range of work involving formal methods and tools, such as model checkers and symbolic analysis [29,31], and approaches combining verified implementations with formal analysis and reductionist security [9,11,20,40].  [44] led to updated analyses of PSK handshakes [1,44]. Arfaoui et al. [3] investigated the privacy features of the TLS 1.3 handshake. Revised computational security proofs of the full 1-RTT handshake by Diemert and Jager [45] and Davis and Günther [43] translated techniques of Cohn-Gordon et al. [28] to establish tighter reductions. There have also been academic proposals for improvements to or modifications of TLS 1.3, considering forward security for the 0-RTT handshake [6], running TLS 1.3 over a different network protocol [32], or defining a KEM-based alternative handshake enabling the deployment of post-quantum schemes [93].

Our Contributions
We give a reductionist security analysis of three modes of the TLS 1.3 handshake: the full 1-RTT handshake, the PSK handshake (with optional 0-RTT mode), and the PSK-(EC)DHE handshake (with optional 0-RTT mode); based on a cryptographic abstraction of the protocols we provide in Sect. 3. In order to carry out our analysis, we formalize a multi-stage key exchange security model which can capture a variety of characteristics associated to each stage key. Our analysis shows that the design of the TLS 1.3 handshake follows sound cryptographic principles.
Security Model Our security model, given in Sect. 4, follows the Bellare-Rogaway (BR) model [25] for authenticated key exchange security based on session key indistinguishability, as formalized by Brzuska et al. [22,26], and our model builds specifically on the multi-stage model of Fischlin and Günther [52,61]. The latter deals with key exchange protocols that derive a series of session keys in the course of multiple protocol stages. Our extension of their multi-stage key exchange model allows us to capture the following characteristics associated to the session key established at each stage, which we call the stage key: • Authentication: whether a stage key is unauthenticated, unilaterally authenticated, or mutually authenticated. We further extend the multi-stage model to capture upgradable authentication: a stage's key may be considered, say, unauthenticated at the time it is accepted, but the authentication level of this key may be "raised" to unilaterally authenticated or, potentially in a second step, mutually authenticated after some later operations, such as verification of a signature in a later message. • Forward secrecy: whether a stage key is meant to provide forward secrecy, namely that it remains secure after compromise of a long-term secret involved in its derivation. • Key usage: whether a stage key is meant to be used internally within the protocol (for example, to encrypt later handshake messages), or externally (for example, composed with a symmetric encryption scheme to protect application messages or used in some other external symmetric-key protocol). • Replayability: whether it is guaranteed that a stage key is not established in result of a replay attack; early stages of the 0-RTT modes do not have this guarantee.
Our security model comes in two flavors that capture security established through two types of credentials: public keys or symmetric pre-shared keys. Following the BR model, our model of compromise includes long-term key compromise (Corrupt) and stage key compromise (Reveal). While other models [33,79] further capture the compromise of session state or ephemeral randomness, TLS is not designed to be secure against such exposure of ephemeral values and we hence do not include these compromise capabilities in our model. In addition to capturing indistinguishability of stage keys, the model also ensures soundness of session identifiers using the Match-security notion of [22,26].
Protocol Analysis We apply our multi-stage key exchange security model in Sects. 5 and 6 to analyze the three modes of the TLS 1.3 handshake: full 1-RTT, PSK, and PSK-(EC)DHE, with the latter two having optional 0-RTT keys. There are four main classes of stage keys covered in the analysis: early data encryption and export keys (ETS, EEMS, only present in the PSK with 0-RTT modes); handshake traffic secrets (tk chs , tk shs ); application traffic secrets (CATS, SATS); and exported keys (RMS for session resumption, EMS for other exported keys). This results in six stage keys in the full 1-RTT mode and eight stage keys in the PSK modes.
As noted above, our security model allows us to precisely capture various characteristics of different stage keys. For example, consider the client handshake traffic secret tk chs , used to encrypt handshake messages from the client to the server. In the full 1-RTT handshake, this key is initially unauthenticated, then unilaterally authenticated through a server signature after stage 3 is reached, and may ultimately be mutually authenticated after stage 6 is reached if the client authenticates; it is forward secret; it is intended for internal use within the protocol; and it is guaranteed to be non-replayed. In contrast, in the PSK handshake, this key is mutually authenticated as soon as it is established, but does not have forward secrecy. Finally, in the PSK-EC(DHE) handshake, this key is unauthenticated initially, then is upgraded to unilateral and eventually mutual authentication after stages 5 and 8, when MACs within the Finished messages are verified; and it is forward secret.
The reductions showing the security of the protocol modes in the model follow a game hopping technique, and mainly rely on standard signature resp. MAC scheme unforgeability (for authentication in the full 1-RTT resp. PSK handshake), hash function collision resistance, PRF security (and in some cases dual PRF security), and an interactive Diffie-Hellman assumption (a variant of the PRF-Oracle-Diffie-Hellman assumption [17,64] called dual-snPRF-ODH).
Observations on the Design and Security of TLS 1. 3 In Sect. 7, we include a discussion about various characteristics of TLS 1.3 based on results of our security analysis, including how a variety of TLS 1.3 design decisions positively impact the security analysis (key separation and key independence, including the session hash in signatures and key derivation), some subtleties on the role of handshake encryption and key confirmation via Finished messages, as well as the susceptibility of 0-RTT keys to replays.
Relation to Our Earlier Work This paper is successor work to [38,39] and [53], as well as [47,61]. In [38], we first extended the multi-stage key exchange model of [52] as needed, then applied it to analyze two early drafts of TLS 1.3: draft-05, which has the same basic signed-Diffie-Hellman structure but a simplified key schedule compared to the final version, and an alternative proposal called draft-dh incorporating ideas from the OPTLS design [77], in which servers could have a semi-static DH key share. In [39], we updated our analysis to draft-10 and added an analysis of the, by then revised, preshared-key handshake mode. In [53], a subset of us analyzed the 0-RTT pre-shared key and PSK-(EC)DHE mode in draft-14, as well as the later deprecated Diffie-Hellmanbased 0-RTT mode using semi-static DH key shares in draft-12, which introduced the notion of replayable stages into the multi-stage key exchange security model. In a PhD thesis [47], one of us updated the work from [39] to address the full, PSK, and PSK-(EC)DHE handshakes in draft-16; in another PhD thesis [61], another of us unified the MSKE model and the aforementioned results on the full and PSK handshakes of draft-10 and the 0-RTT handshakes of draft-12 and draft- 14. This paper updates this prior work to the final version of TLS 1.3 as published in RFC 8446 [90] (recall that there were 29 drafts leading up to the final standard). It addresses, in a unified security model, the full, PSK, and PSK-(EC)DHE handshakes, the latter two with optional 0-RTT keys. The security model in this paper includes enhancements not present in earlier works, particularly for capturing upgradable authentication. The model and analysis for the PSK mode have been updated to reflect the observations of Drucker and Gueron's "Selfie" attack [44] by associating intended roles with a pre-shared key. Section 7.1 provides more details on technical differences between this paper and our earlier work.
Limitations The TLS 1.3 protocol allows users to support and negotiate different cryptographic algorithms including the used signature schemes, Diffie-Hellman groups, and authenticated encryption schemes. Many implementations will simultaneously support TLS 1.3, TLS 1.2, and even earlier versions. We do not aim to capture the security of this negotiation process nor security when a cryptographic key (e.g., a signing key) is re-used across different algorithm combinations or with earlier versions of TLS [66]. For the PSK modes of TLS 1.3, we do not treat how parties negotiate which pre-shared key to use. Our analysis assumes that all parties use only TLS 1.3 with a single combination of cryptographic algorithms and do not re-use keying material outside of that context (beyond consuming session keys established by the TLS 1.3 handshake).
In our proofs of key indistinguishability for all three TLS 1.3 handshake modes, some of our proof steps involve guessing parties and/or sessions, and thus are non-tight, similar to most proofs of authenticated key exchange protocols. Recently, Diemert and Jager [45] as well as Davis and Günther [43] have established new security proofs for the TLS 1.3 full 1-RTT handshake with tight reductions to the strong Diffie-Hellman assumption, translating techniques of Cohn-Gordon et al. [28].
Our focus is entirely on the TLS 1.3 handshake protocol, and thus does not address security of the record layer's authenticated encryption. TLS 1.3 also includes a variety of additional functionalities outside the core handshake that we treat as out of scope. Examples include session tickets, post-handshake authentication [75], the alert protocol, and changes for Datagram TLS (DTLS) 1.3 [92], as well as other extensions to TLS 1.3 currently in the Internet-Draft state.
Security in practice obviously relies on many more factors, such as good implementations and good operational security, which are important but outside the scope of this analysis.

Preliminaries
We begin with introducing the basic notation we use in this paper and recapping some core building blocks and cryptographic assumptions employed in our security analysis.

Notation
With N we denote the natural numbers. We write a bit as b ∈ {0, 1} and a (bit) string as s ∈ {0, 1} * , with |s| indicating its (binary) length; {0, 1} n is the set of bit strings of length n. We write x ← y for the assignment of value y to the variable x and x ←$ X for uniformly sampling x from a (finite) set X .
For an algorithm A we write x ← A(y), resp. x ←$ A(y), for the algorithm deterministically, resp. probabilistically, outputting x on input y. We indicate by A O an algorithm A running with oracle access to some other algorithm O.

Collision-Resistant Hash Functions
As often the case in practice, the cryptographic hash functions used in TLS 1.3 are unkeyed. When considering a hash function's collision resistance, we hence demand that a security reduction provides effective means for constructing a concrete algorithm generating a collision (cf. Rogaway [91]).

Definition 2.1. (Hash function and collision resistance)
We can now measure the collision resistance (COLL) with respect to an adversary A via the advantage In the common asymptotic notion, we would demand that one cannot construct an efficient adversary A where this advantage is non-negligible with respect to the security parameter λ.
HKDF follows the extract-then-expand paradigm for key derivation [68,73], instantiated with HMAC. We adopt the standard notation for the two HKDF functions: HKDF.Extract(XTS, SKM) on input an (non-secret and potentially fixed) extractor salt XTS and some (not necessarily uniform) source key material SKM outputs a pseudorandom key PRK. HKDF.Expand(PRK, CTXinfo, L) on input a pseudorandom key PRK (from the Extract step) and some (potentially empty) context information CTXinfo outputs pseudorandom key material KM of length L bits. (For simplicity, we omit the third parameter L in Expand when L = λ, which is the case throughout TLS 1.3 except when deriving traffic keys (cf. Table 2).) Both functions are instantiated with HMAC, where directly HKDF.Extract(XTS, SKM) := HMAC(XTS, SKM) and HKDF.Expand iteratively invokes HMAC to generate pseudorandom output of the required length (see [73]).

Dual PRF Security and the PRF-ODH Assumption
Most key derivation steps in TLS 1.3 rely on regular pseudorandom function (PRF) security for the HKDF and HMAC functions. In our analysis of the PSK handshakes, we also treat HMAC as a collision-resistant unkeyed hash function over the pair of inputs, as in Definition 2.1. For some of its applications, we, however, need to deploy stronger assumptions which we recap here.
The first assumption is concerned with the use of HMAC as a dual PRF (cf. [14]).
with key space K and label space L such that K = L. We define the dual PRF security of f as the PRF security of f swap (k, l) := f (l, k) and the according advantage function as The second assumption, the so-called pseudorandom-function oracle-Diffie-Hellman PRF-ODH assumption, has been introduced by Jager et al. [64] in their analysis of the TLS 1.2 key exchange. It is a variant of the oracle-Diffie-Hellman assumption introduced by Abdalla et al. [5] in the context of the DHIES encryption scheme. Basically, the PRF-ODH assumption states that the value PRF(g uv , x ) for a Diffie-Hellman-type key g uv is indistinguishable from a random string, even when given g u and g v and when being able to see related values PRF(S u , x) and/or PRF(T v , x) for chosen values S, T , and x. The PRF-ODH assumption comes in various variants, which have been generalized and studied by Brendel et al. [17].
For our analysis of TLS 1.3, we will deploy only the snPRF-ODH assumption providing limited oracle access to only a single related value PRF(S u , x), as well as its dual variant, dual-snPRF-ODH. Both have been established by Brendel et al. [17] to hold for HMAC in the random oracle model under the strong Diffie-Hellman assumption. Definition 2.3. (snPRF-ODH and dual-snPRF-ODH assumptions) Let λ ∈ N, G be a cyclic group of prime order q with generator g and PRF : G × {0, 1} * → {0, 1} λ be a pseudorandom function.
We define the snPRF-ODH security game as follows.
1. The challenger samples b ←$ {0, 1}, u, v ←$ Z q , and provides G, g, g u , and g v to A, who responds with a challenge label x . 2. The challenger computes y 0 = PRF(g uv , x ) and samples y 1 ←$ {0, 1} λ uniformly at random, providing y b to A. 3. A may query a pair (S, x), on which the challenger first ensures that S / ∈ G or (S, x) = (g v , x ) and, if so, returns y ← PRF(S u , x). 4. Eventually, A stops and outputs a guess b ∈ {0, 1}.
We define the snPRF-ODH advantage function as We define the dual variant of the assumption, dual-snPRF-ODH, as the snPRF-ODH assumption for a function PRF : {0, 1} * × G → {0, 1} λ with swapped inputs, keyed with a group element in the second input and taking the label as first input.

The TLS 1.3 Handshake Protocol
In this section we describe the TLS 1.3 handshake protocol modes, specifically the full one round-trip time (1-RTT) handshake, depicted on the left-hand side of Fig. 1, and the combined zero round-trip time (0-RTT) and pre-shared key handshake, depicted on the right-hand side of in Fig. 1. Our focus in Fig. 1 and throughout the paper is on the cryptographic aspects of the TLS 1.3 handshake. As such, we omit many other components of the protocol, including most hello extensions, aspects of version and algorithm negotiation, post-handshake messages, the record layer protocol, and the alert protocol.
In TLS 1.3, the 1-RTT and PSK handshakes are divided into two distinct phases: a key exchange phase, where the client and the server exchange Hello messages to indicate support for different cryptographic options and use the selected parameters to generate key exchange material; and an authentication phase, where the client and the server exchange CertificateVerify and Finished messages, authenticating each other using long-term asymmetric (or symmetric) values. Figure 2 illustrates the key schedule of TLS 1.3, Table 1 lists abbreviations for messages and keys used throughout the paper, and Table 2 details some of the computations and inputs.

Key-Exchange Phase
The key exchange phase consists of the exchange of ClientHello (CH) and ServerHello (SH) messages, during which parameters are negotiated and the core key exchange is performed, using either Diffie-Hellman key exchange or based on a pre-shared symmetric key. ClientHello. The client begins by sending the ClientHello message, which contains r c (a randomly-sampled 256-bit nonce value), as well as version and algorithm negotiation information.
Attached to the ClientHello is the KeyShare (CKS) extension which contains public key shares for the key exchange. Other extensions are present for further algorithm and parameter negotiation. (Note that our analysis in Sects. 5 and 6 does not consider the negotiation of cryptographic values (such as pre-shared keys or (EC)DHE groups) or handshake modes, but instead our analysis considers each handshake mode and ciphersuite combination in isolation. This can be seen in Fig. 1, e.g., the CKS message contains only a single (EC)DHE key share.) If a pre-shared secret has been established between the client and the server (either in a previous handshake or via some out-of-band mechanism) the client may include  Table 1; the values of context and label inputs (H * , resp. Label * ) and details on the calculation of traffic keys (tk * ) can be found in Table 2. the PreSharedKey (CPSK) extension, which indicates handshake modes (such as PSK or PSK-(EC)DHE) that the client supports, and a list of pre-shared symmetric identities that map to these PSKs. (As for the KeyShare extension, we do not consider negotiation here and only capture the single PSK entry that client and server agree upon.) If CPSK is included, the client computes a binder key value BK for each pre-shared key PSK in the list, from that a key fk B , and a value binder ← HMAC(fk B , H (CH † )) that binds the current CH message (truncated to exclude the binder value itself) to each PSK, also included in the CPSK message and checked by the server. This is captured on the right-hand side of Fig. 1.
Finally, if the client wishes to use the pre-shared secret to send zero-round-trip time (0-RTT) data, the client can indicate this by sending a EarlyDataIndication extension. This will indicate to the server that the client will use the first pre-shared secret indicated in the CPSK list to derive an early traffic secret (ETS), and early exporter master secret (EEMS), and begin sending encrypted data to the server without first requiring the client to receive ServerHello response. ServerHello. The next message in the key-exchange phase is the ServerHello (SH) message. As in CH, the server will randomly sample a 256-bit nonce value r s . The server picks among the various algorithms and parameters offered by the client and responds with its selections. If CPSK was sent, the server decides whether to accept a PSK-based handshake. If so, then the pre-shared key identifier pskid associated with the selected PSK is sent in the PreSharedKey (SPSK) extension. If the server has chosen PSK-(EC)DHE mode (or has rejected the use of PSKs), the server will generate its own (EC)DHE key share Y ← g y , sending Y in the KeyShare (SKS) extension attached to SH.
At this point, the server has enough information to compute the client handshake traffic secret (CHTS) and server handshake traffic secret (SHTS) values, and uses these to derive client and server handshake traffic keys (tk chs and tk shs , respectively). The first part of Fig. 2 shows the key schedule for deriving these keys. Note that we consider tk chs and tk shs being derived at the same point in time (namely when the handshake secret HS becomes available), although tk chs is in principle only needed a bit later.
The server now begins to encrypt all handshake messages under tk shs , and any extensions that are not required to establish the server handshake traffic key are sent (and encrypted) in the EncryptedExtensions (EE) messages.

Authentication Phase
The authentication phase now begins. All handshake messages in this phase are encrypted under tk shs or tk chs . In the full 1-RTT handshake, authentication is based on public key certificates; see the left-hand side of Fig. 1. In pre-shared key handshakes (both PSK and PSK-(EC)DHE), the server and client will authenticate each other by relying on a message authentication code applied to the transcript; see the right-hand side of Fig. 1.

Authentication in Full 1-RTT Handshake
The server can request public-key-based client authentication by sending a CertificateRequest (CR) message. The server will authenticate to the client by using the server's long-term public keys. Here, the server  Table 2. begins by sending its certificate (carrying its public key) in the ServerCertificate (SCRT) message. The server then computes ServerCertificateVerify authentication value by signing the session hash (which is a continuously updating hash of all messages up to this point in the protocol), then sends it to the client as the ServerCertificateVerify message.

Server Key Confirmation and Key Derivation
In all handshake modes, the final message that the server sends to the client is the ServerFinished (SF) message. The server first derives a server finished key fk S from SHTS and then computes a MAC tag SF over the session hash. This value is also encrypted under tk shs , sending the output ciphertext to the client. At this point, the server is able to compute the client application traffic secret (CATS), the server application traffic secret (SATS), and the exporter master secret (EMS). Figure 2 shows the key schedule for deriving these keys and all other keys in the authentication phase. Now that the server has computed the server application traffic key tk sapp , it can begin sending encrypted application data to the client without waiting for the final flight of messages from the client, thus achieving a 0.5-RTT handshake.

Client Verification, Authentication, Key Confirmation, and Key Derivation
The client, upon receiving these messages, checks that the signature SCV (if in full 1-RTT mode) and the MAC SF verify correctly. If the server has requested client authentication, the client will begin by sending its digital certificate (carrying its public-key) in the ClientCertificate (CCRT) message, after which the client will compute its own certificate verify value CCV by signing the session hash, then send it to the server as the CCV message. The client finally derives the client finished key fk C from CHTS and uses fk C to compute a MAC tag CF over the session hash.

Server Verification
The server will verify the final MAC (SF) and optional signature (SCV) messages of the client.
Handshake Completion At this point both parties can compute the resumption master secret (RMS) value that can be used as a pre-shared key for session resumption in the future. Both parties can now derive the client application traffic key (tk capp ) and use the record layer for encrypted communication of application data with the resulting keys.

NewSessionTicket
The NewSessionTicket message is a post-handshake message in TLS 1.3 which refers to values from the handshake protocol. The NewSessionTicket message can be sent by a server to the client (encrypted under a server application traffic key tk sapp ) to allow the client to compute values associated with resumption handshakes, including the PSK used in resumption as well as an identifier to indicate to the server which preshared key is being used. The NewSessionTicket message contains two fields that are interesting for this purpose: • ticket_nonce, which is used by the client as the salt value to derive the preshared key to be used in future handshake for resumption: PSK ← HKDF. Expand(RMS, "resumption", ticket_nonce). • ticket, which is an opaque label used to publicly refer to the associated preshared key in future PreSharedKey messages. In our notation used in Fig. 1, the pre-shared key identifier pskid = ticket.
In our analysis, we do not capture this NewSessionTicket message, nor the derivation of PSK from RMS, and instead assume that the mapping between PSK and pskid is established in some out-of-band way. In particular, we do not capture transmission of NewSessionTicket under a server application traffic key tk sapp , as it would impact how we consider the usage of SATS. In our analysis, we currently consider SATS an "external key", used in an arbitrary symmetric-key protocol. To capture the transmission of NewSessionTicket, we would need to capture the use of SATS in deriving tk sapp and then establishing PSK. We choose to simplify the analysis by omitting this mechanism and leave this as future work.

Multi-Stage Key Exchange Security Model
In order to capture the security of all variants of the TLS 1.3 handshake within a single comprehensive security model, we adopt the multi-stage key exchange model in the version by Günther [61] which combines the original model by Fischlin and Günther [52] with follow-up extensions [38,39,53]. We refer to Günther [61] for an extensive discussion of the model, but recap its core concepts and definitions as well as adaptations for our analysis in the following.
The model follows the classical paradigm for key exchange models of Bellare and Rogaway [25] in the formalism of Brzuska et al. [22,26]. This paradigm captures a strong adversary that controls the network and is able to both passively eavesdrop and Table 2. Secret, context, and label inputs to the HKDF.Expand resp. authentication functions as well as traffic key calculation in the TLS 1.3 handshake (Fig. 1) and key schedule (Fig. 2).

Secret
Context input Label input Traffic key calculation tk eapp /tk chs /tk shs /tk capp /tk sapp = (key, iv) = DeriveTK(ETS/CHTS/SHTS/CATS/SATS) where DeriveTK(Secret) = (HKDF.Expand(Secret, "key", H (""), L k ), HKDF.Expand(Secret, "iv", H (""), L iv )) with L k /L iv indicating the key/iv length of the negotiated AEAD scheme The actual label input to HKDF.Expand is the concatenation of the hash length (in bytes), the string "tls13 ", Label, and the given context value. HKDF.Expand is then called on the corresponding secret, this augmented label, and the desired output length. ClientCertVfy * is only included in case of client authentication. ClientHello † indicates a truncated version of ClientHello which excludes the binder value itself. Signatures in SCV and CCV are computed over the concatenation of a constant (0x20 repeated 64 times), the label as context information, a separating 0 byte, and the context value to actively modify the communication across multiple sessions of the key exchange protocol (spawning them via a NewSession oracle and directing communication via a Send oracle). The adversary is further allowed to expose the long-term secrets of interacting honest parties (via a Corrupt oracle) as well as the session keys in some protocol runs (through a Reveal oracle). Basic security then demands that such adversary cannot distinguish the real established session key in some uncompromised ("fresh") session from a random one (through a Test oracle).
The multi-stage key exchange model now extends the basic key exchange setting by capturing protocols that derive a series of session keys in multiple stages. Each stage is associated with particular security properties, steering admissibility of certain adversarial actions for that stage and under which conditions the key of this stage is considered fresh. These security properties model the following aspects: Authentication. Our model distinguishes between unauthenticated stages, unilaterally authenticated stages where only the responder (the server in TLS 1.3) authenticates, and mutually authenticated stages where both peers authenticate. We treat the authentication of each stage individually and consider concurrent executions of different authentication modes of the same protocol. The identities of communication partners may be learned only during the execution of the protocol (e.g., through exchanged certificates), which we implement through post-specified peers following Canetti and Krawczyk [34]. Our model demands a strong notion of security for sessions with unauthenticated peers, namely that such sessions achieve key secrecy when receiving their messages from an honest session (identified via a contributive identifier), independent of whether that honest peer session later becomes partnered. Moreover, the authentication level of some stage may be raised with acceptance of a later stage, e.g., from unauthenticated to unilaterally or even mutually authenticated. This may happen for instance if a party later signs previously transmitted data, as in case of TLS 1.3. We capture this by allowing a protocol to specify the authentication level for each acceptance stage, as well as at which later stage(s) that level increases. Note that we capture authentication implicitly through key secrecy (i.e., keys are only known to the intended peer session) but do not prove explicit authentication (i.e., the existence of a partnered session). The SIGMA design [72], on which the main TLS 1.3 handshake is based, ensures explicit authentication. de Saint Guilhem et al. [42] give a generic argument that explicit authentication follows from implicit key secrecy (which is shown for TLS 1.3 in this article) and key confirmation [55].
Forward secrecy.We capture the usual notion of forward secrecy, which ensures that accepted session keys remain secure after a long-term secret compromise. In a multistage key exchange protocol, forward secrecy may however be reached only from a certain stage on (e.g., due to mixing-in forward-secret key material). The model hence treats stage-j forward secrecy, indicating that keys from stage j on are forward secret.
Key usage.Some stage keys might be used internally in the key exchange protocol, e.g., in the case of TLS 1.3 the handshake key is used to encrypt part of the key exchange communication. We distinguish the usage of keys as internal when used within the key exchange, and external when exclusively used outside of the key exchange (e.g., to encrypt application data). In the former case, our model ensures that tested realor-random keys are accordingly used in subsequent key exchange steps, and pauses the protocol execution to enable testing of those keys. We note that the declaration of whether a key is internal or external is a parameter to the model, and becomes a part of the protocol description and its security guarantees.
Public or pre-shared keys. Our multi-stage model comes in two flavors that capture both the regular, public-key case (abbreviated as pMSKE) of long-term keys being public/secret key pairs (as in the TLS 1.3 full handshake) as well as the pre-shared-secret case (abbreviated sMSKE) case where pre-shared symmetric keys act as long-term secrets (as in the TLS 1.3 resumption handshake).
Replayability. For 0-RTT key establishment, key exchange protocols (including TLS 1.3) regularly give up strong replay protection guarantees, in the sense that client (initiator) messages can be replayed to several server (responder) sessions. We capture this in our model by distinguishing between replayable (0-RTT) and regular non-replayable stages, taking potential replays into account for the former while still requiring key secrecy. Determining the replay type of a stage is again a parameter to the model and must be specified as part of the protocol description resp. the security claim.
We note that former variants of multi-stage key exchange models including [61] further differentiated whether the compromise of some stage's key affects the security of other stages' keys under the notion of key (in)dependence. Here, we always demand such compromise never affects other stages' keys as the desirable goal, i.e., we postulate key independence and reduce the model's complexity by incorporating this property straight into the model. As we will see, TLS 1.3 always achieves this property due to clean key separation in the key scheduling and already did so in earlier draft versions [38,39,53].

Secret Compromise Paradigm
We follow the paradigm of the Bellare-Rogaway model [25], focusing on the leakage of long-term secret inputs and session key outputs of the key exchange, but not on internal values within the execution of a session. This contrasts to some extent with the model by Canetti and Krawczyk [33] resp. LaMacchia et al. [79] which include a "session state reveal" resp. "ephemeral secret reveal" query that allows accessing internal variables of the session execution.
In the context of TLS 1.3, this means we consider the leakage of: • Long-term keys (such as the signing keys of the server or client, but also their preshared keys), since long-term values have the potential to be compromised, and this is necessary to model forward secrecy; it is captured in our model by the Corrupt query. • Session keys (such as the various traffic encryption keys or the derived resumption or exporter secrets), since these are outputs of the key exchange and are used beyond this protocol for encryption, later resumption, or exporting of keying material; this is modeled by the Reveal query.
We do not permit the leakage of: • Ephemeral secrets / randomness (such as the randomness in a signature algorithm or ephemeral Diffie-Hellman exponents); this is disallowed since TLS  [52], the most notable changes in our model are the addition which models upgradeable authentication and accommodating both public and pre-shared symmetric keys for authentication. We also do not track whether keys are independent or not, as all keys established in TLS 1.3 satisfy key independence (unlike in the analysis of QUIC in [52]). Key usage (internal versus external) and replayability were introduced to MSKE by [53].

Syntax
In our model, we explicitly separate some protocol-specific properties (as, e.g., various authentication flavors) from session-specific properties (as, e.g., the state of a running session). We represent protocol-specific properties as a vector (M, AUTH, FS, USE, REPLAY) that captures the following: • M ∈ N: the number of stages (i.e., the number of keys derived). (We fix a maximum stage M only for ease of notation. Note that M can be arbitrarily large in order to cover protocols where the number of stages is not bounded a-priori. Also note that stages and session key derivations may be "back to back," without further protocol interactions between parties.) . . , M, ∞}}: a set of vectors of pairs, each vector encoding a supported scheme for authentication and authentication upgrades, for each stage. For example, the i-th entry (u i , m i ) in a vector says that the session key in stage i initially has the default unauthenticated level, i.e., provides no authentication for either communication partner, then at stage u i becomes unilaterally authenticated and thus authenticates only the responder (server), and becomes mutually authenticated to authenticate both communication partners at stage m j . Note that we allow for example u i = i (or even u i = m i = i) such that the session key is immediately unilaterally (resp. mutually) authenticated when derived. Entries in each pair must be non-decreasing, and u i = ∞ or m i = ∞ denotes that unilateral, resp. mutual, authentication is never reached for stage i. Here, an internal key is used within the key exchange protocol (but possibly also externally), whereas an external key must not be used within the protocol, making the latter potentially amenable to generic composition (cf. Sect. 7.3). As shorthand notation, we, e.g., write USE = (internal : {1, 4}, external : {2, 3, 5}) to indicate that usage of keys in stage 1 and 4 is internal, and external for the other stages. • REPLAY ∈ {replayable, nonreplayable} M : the replayability indicator for each stage, where REPLAY i indicates whether the i-th stage is replayable in the sense that an adversary can easily force identical communication and thus identical session identifiers and keys in this stage (e.g., by re-sending the same data in 0-RTT stages). Note that the adversary, however, should still not be able to distinguish such a replayed key from a random one. We remark that, from a security viewpoint, the usage of replayable stages should ideally be limited, although such stages usually come with an efficiency benefit. We use the same shorthand notation as for USE; e.g., REPLAY = (nonreplayable : {1, 2, 3}) indicates that all three stages are non-replayable.
We denote by U the set of identities (or users) used to model the participants in the system, each identified by some U ∈ U. Sessions of a protocol are uniquely identified (on the administrative level of the model) using a label label ∈ LABELS = U × U × N, where label = (U, V, n) indicates the n-th local session of identity U (the session owner) with V as the intended communication partner.
In the public-key variant of the model (pMSKE), each identity U is associated with a certified long-term public key pk U and secret key sk U . In the pre-shared secret setting (sMSKE), a session instead holds an identifier pssid ∈ {0, 1} * for the pre-shared secret pss ∈ P (from some pre-shared secret space P) used. The challenger maintains maps pss U,V : {0, 1} * → P mapping an identifier to the corresponding secret shared by parties U and V , where U uses that secret (only) in the initiator role and V (only) in the responder role, and for any user U , a pre-shared secret identifier pssid uniquely identifies the peer identity V it is shared with. (Requiring a fixed role in which a pre-shared key can be used by either peer avoids the Selfie attack [1,44].) For each session, a tuple with the following information is maintained as an entry in the session list List S , where values in square brackets [ ] indicate the default initial value. Some variables have values for each stage i ∈ {1, . . . , M}.
• label ∈ LABELS: the unique (administrative) session label • id ∈ U: the identity of the session owner • pid ∈ U ∪{ * }: the identity of the intended communication partner, where the distinct wildcard symbol ' * ' stands for "currently unknown identity" but can be later set to a specific identity in U once by the protocol • role ∈ {initiator, responder}: the session owner's role in this session • auth ∈ AUTH: the intended authentication type vector from the set of supported authentication properties AUTH, where auth i indicates the authentication level pair for stage i, and auth i, j its j-th entry • pssid ∈ {0, 1} * ∪ {⊥}: In the pre-shared secret (sMSKE) variant the identifier for the pre-shared secret (i.e., pss id,pid if role = initiator, else pss pid,id ) to be used in the session; can be initialized with ⊥ if pid = * is unknown and then must be set (once) when pid is set set to accepted i in the moment a session accepts the i-th key, to rejected i when the session rejects that key (a session may continue after rejecting in a stage (this models, e.g., servers rejecting 0-RTT data from a client, but continuing with the remaining handshake)), and to running i when a session continues after accepting the i-th key By convention, adding a not fully specified tuple (label, id, pid, role, auth) resp. (label, id, pid, role, auth, pssid) to List S sets all other entries to their default value. As shorthands, for some tuple with (unique) label label in List S we furthermore write label.X for that tuple's element X and label.(X, Y, Z ) for the vector (X, Y, Z ) of that tuple's elements X , Y , and Z . We define two distinct sessions label and label to be partnered in stage i if both sessions hold the same session identifier in that stage, i.e., label.sid i = label .sid i = ⊥, and require for correctness that two sessions having a non-tampered joint execution are partnered in all stages upon acceptance.
Our security model treats corruption of long-term secrets (secret keys for pMSKE, pre-shared secrets for sMSKE). While the effects of such compromises on sessions may differ in each setting, we broadly consider the derived keys of some session to be revealed if, in the public-key setting (pMSKE), the owner or peer secret key is compromised, or in the pre-shared secret setting (sMSKE), if the pre-shared secret used for that session is compromised. Forward secrecy comes into play when determining if keys derived prior to the long-term secret corruption are affected, too. In more precise notation, we say a session label is corrupted if • for pMSKE, the session's owner label.id or intended communication partner label.pid is corrupted (i.e., {label.id, label.pid} ∩ corrupted = ∅), resp. • for sMSKE, the used pre-shared secret is corrupted (i.e., (label.id, label.pid, label. pssid) ∈ corrupted, the set of corrupted users) if label.role = initiator, resp. (label.pid, label.id, label.pssid) ∈ corrupted if label.role = responder.
Upgradable Authentication We capture that the authentication level of some stage may increase, possibly twice, with acceptance of a later stage through a per-stage vector in the authentication level matrix. When capturing security, our model however needs to carefully consider the interaction of authentication and corruptions (somewhat similar to what one might be used to for forward secrecy). More precisely, the authentication guarantee of some stage i after its acceptance can only step up (in some later stage j > i) if the involved parties are not corrupted by the time stage j accepts. Otherwise, the adversary may have impersonated the party up to the unauthenticated stage i and now post-authenticates as the party after corruption in stage j. This would effectively mean that the adversary has been in full control of the session and may thus know the session key of stage i. We capture the upgrade by defining the rectified authentication level rect_auth i of some stage i in a session with intended authentication vector auth, consisting of pairs (auth i,1 , auth i,2 ) describing the stage in which the i-th session key gets unilaterally and mutually authenticated, with corruption indicator corrupted, and with current execution stage stage as follows: This encodes that authentication level of stage i is upgraded (to unilateral or mutual) when reaching stage auth i,1 , resp. auth i,2 , only if no corruption affected this session prior to these stages (auth i,1 , resp. auth i,2 ).

Adversary Model
We consider a probabilistic polynomial-time (PPT) adversary A which controls the communication between all parties, enabling interception, injection, and dropping of messages. Our adversary model further reflects the advanced security aspects in multi-stage key exchange as outlined above. We conveniently capture admissibility of adversarial interactions and conditions where the adversary trivially loses (such as both revealing and testing the session key in partnered sessions) via a flag lost (initialized to false). The adversary interacts with the protocol via the following queries.
• NewSecret(U, V, pssid): This query is only available in the pre-shared secret (sMSKE) variant. Generates a fresh secret with identifier pssid shared between parties U and V , to be used by U in the initiator role and by V in the responder role. If pss U,V (pssid) is already set, return ⊥ to ensure uniqueness of pssid identifiers between two parties in these roles. Otherwise, sample pss ←$ P uniformly at random from the protocol's pre-shared secret space P and define pss U,V (pssid) := pss.
• NewSession(U, V, role, auth[, pssid]): Creates a new session with a (unique) new label label for owner identity id = U with role role, having pid = V as intended partner (potentially unspecified, indicated by V = * ) and aiming at authentication type auth.
In the pre-shared secret (sMSKE) variant, the additional parameter pssid identifies the pre-shared secret to be used, namely pss U,V (pssid) if role = initiator, resp. pss V,U (pssid) if role = responder. The identifier might be unspecified at this point (indicated by pssid = ⊥) and may then be set later by the protocol once.
Add (label, U, V, role, auth), resp. (label, U, V, role, auth, pssid), to List S . If label is corrupted, set label.corrupted ← 0. This encodes the information that the session is corrupt right from the beginning. Return label.
• Send(label, m): Sends a message m to the session with label label.
If there is no tuple with label label in List S , return ⊥. Otherwise, run the protocol on behalf of U on message m and return the response and the updated state of execution label.st exec . As a special case, if label.role = initiator and m = init, the protocol is initiated (without any input message). If, during the protocol execution, the state of execution changes to accepted i , the protocol execution is immediately suspended and accepted i is returned as result to the adversary. The adversary can later trigger the resumption of the protocol execution by issuing a special Send(label, continue) query. For such a query, the protocol continues as specified, with the party creating the next protocol message and handing it over to the adversary together with the resulting state of execution st exec . We note that this is necessary to allow the adversary to test an internal key, before it may be used immediately in the response and thus cannot be tested anymore to prevent trivial distinguishing attacks. It furthermore allows the adversary to corrupt long-term keys in a fine-grained manner after any acceptance of a key. If the state of execution changes to label.st exec = accepted i for some i and there is a partnered session label = label in List S (i.e., label. This ensures that, if the partnered session has been tested before, subsequent Test queries for the session are answered accordingly and, in case it is used internally, this session's key key i is set consistently. (Note that for internal keys this implicitly assumes the following property of the later-defined Match security: whenever two partnered sessions both accept a key in some stage, these keys will be equal.) If the state of execution changes to label.st exec = accepted i for some i and the session label is corrupted, then set label.st key,i ← revealed.
• Reveal(label, i): Reveals the session key label.key i of stage i in the session with label label.
If there is no session with label label in List S or label.stage < i, then return ⊥. Otherwise, set label.st key,i to revealed and provide the adversary with label.key i .
• Corrupt(U ) or Corrupt(U, V, pssid): The first query is only used in the publickey (pMSKE) variant, the second query only in the pre-shared secret (sMSKE) variant. Provide the adversary with the corresponding long-term secret, i.e., sk U (pMSKE), resp. pss U,V (pssid) (sMSKE). Add to the set of corrupted entities corrupted the user U (for pMSKE), resp. (for sMSKE) the global preshared secret identifier (U, V, pssid).
In the non-forward-secret case, for each such session label and for all i ∈ {1, . . . , M}, set label.st key,i to revealed. I.e., all (previous and future) session keys are considered to be disclosed.
In the case of stagej forward secrecy, st key,i of each such session label is instead set to revealed only if i < j or if i > stage. This means that session keys before the j-th stage (where forward secrecy kicks in) as well as keys that have not yet been established are potentially disclosed.
• Test(label, i): Tests the session key of stage i in the session with label label. In the security game this oracle is given a uniformly random test bit b test as state which is fixed throughout the game.
and there is a partnered session label in List S (i.e., label.sid i = label .sid i ) with label .st exec = accepted i , set the 'lost' flag to lost ← true. This ensures that keys can only be tested once and, in case of internal keys, if they have just been accepted but not used yet, ensuring also that any partnered session that may have already established this key has not used it. If label.rect_auth i = unauth, or if label.rect_auth i = unilateral and label.role = responder, but there is no session label (for label = label ) in List S with label.cid i = label .cid i , then set lost ← true. This ensures that having an honest contributive partner is a prerequisite for testing unauthenticated stages, resp. the responder sessions in a unilaterally authenticated stage. (Note that List S entries are only created for honest sessions, i.e., sessions generated by NewSession queries.) The check is based on the uncorrupted authentication level rect_auth i in order to take corruptions between authentication upgrades into account.
Otherwise, set label.tested i to true. If the test bit b test is 0, sample a key K ←$ D at random from the session key distribution D. If b test = 1, let K ← label.key i be the real session key. If USE i = internal (i.e., the tested i-th key is indicated as being used internally), set label.key i ← K ; in other words, when b test = 0, we replace an internally used session key by the random and independent test key K which is also used for consistent future usage within the key exchange protocol. In contrast, externally used session keys are not replaced by random ones, the adversary only receives the real (in case b test = 1) or random (in case b test = 0) key. This distinction between internal and external keys for Test queries emphasizes that external keys are not supposed to be used within the key exchange (and hence there is no need to register the tested random key in the protocol's session key field), while internal keys will be used (and hence the tested random key must be deployed in the remaining protocol steps for consistency).
Moreover, if there exists a partnered session label which has also just accepted the i-th key (i.e., label.sid i = label .sid i and label.st exec = label .st exec = accepted i ), then also set label .tested i ← true and (only if USE i = internal) label .key i ← label.key i to ensure consistency (of later tests and (internal) key usage) in the special case that both label and label are in state accepted i and, hence, either of them can be tested first. Return K .

Security of Multi-Stage Key Exchange Protocols
As in the formalization of the Bellare-Rogaway key exchange model by Brzuska et al. [22,26], we model security according to two games, one for key indistinguishability, and one for session matching. The former is the classical notion of random-looking keys, refined under the term Multi-Stage security according to the advanced security aspects for multi-stage key exchange: (stagej) forward secrecy, different authentication modes, and replayability. The Match property complements this notion by guaranteeing that the specified session identifiers sid effectively match the partnered sessions, and is likewise adapted to the multi-stage setting.

Match Security
The notion of Match security ensures soundness of the session identifiers sid, i.e., that they properly identify partnered sessions in the sense that 1. sessions with the same session identifier for some stage hold the same key at that stage, 2. sessions with the same session identifier for some stage have opposite roles, except for potential multiple responders in replayable stages, 3. sessions with the same session identifier for some stage agree on that stage's authentication level, 4. sessions with the same session identifier for some stage share the same contributive identifier at that stage, 5. sessions are partnered with the intended (authenticated) participant and, for mutual authentication based on pre-shared secrets, share the same key identifier, 6. session identifiers do not match across different stages, and 7. at most two sessions have the same session identifier at any non-replayable stage.
The Match security game G Match KE,A thus is defined as follows.

Multi-Stage Security
The second and core notion, Multi-Stage security, captures Bellare-Rogaway-like key secrecy in the multi-stage setting as follows. We say that A wins the game, denoted by G Note that the winning condition is independent of forward secrecy and authentication properties of KE, as those are directly integrated in the affected (Reveal and Corrupt) queries and the finalization step of the game; for example, Corrupt is defined differently for non-forward-secrecy versus stagej forward secrecy.
We say KE is Multi-Stage-secure with properties (M, AUTH, FS, USE, REPLAY) if KE is Match-secure and for all PPT adversaries A the following advantage function is negligible in the security parameter:

Security Analysis of the TLS 1.3 Full 1-RTT Handshake
We now come to analyzing the TLS 1.3 full 1-RTT handshake in the public-key multistage key exchange (pMSKE) model.

Protocol Properties
The full handshake targets the following protocol-specific properties (M, AUTH, FS, USE, REPLAY): • M = 6: The full 1-RTT handshake consists of six stages deriving, in order: the client and server handshake traffic keys tk chs and tk shs , the client and server application traffic secrets CATS and SATS, the exporter master secret EMS, and the resumption master secret RMS. As shown in Fig. 1, we consider all stages' keys being derived on either side as soon as the relevant main secret (ES, HS, MS) becomes available, despite client/server keys derived in parallel might become active with some delay based on the flow direction. Here, starred ( * ) components are present only in mutual authentication mode. Note that we define session identifiers over the unencrypted handshake messages. For the contributive identifiers in stages 1 and 2, client (resp. server) upon sending (resp. receiving) the ClientHello and ClientKeyShare messages set cid 1 = ("CHTS", CH, CKS), cid 2 = ("SHTS", CH, CKS) and later, upon receiving (resp. sending) the ServerHello and ServerKeyShare messages, extend it to cid 1 = ("CHTS", CH, CKS, SH, SKS), cid 2 = ("SHTS", CH, CKS, SH, SKS). All other contributive identifiers are set to cid i = sid i (for stages i ∈ {3, 4, 5, 6}) when the respective session identifier is set.

Match Security
We are now ready to give our formal security results for the TLS 1.3 full 1-RTT handshake, beginning with Match security.
where n s is the maximum number of sessions, q is the group order, and |nonce| = 256 is the bit length of the nonces.
Recall that Match security is a soundness property of the session identifiers. From our definition of session identifiers above, it follows immediately that partnered sessions agree on the derived key, opposite roles, authentication properties, contributive identifiers, and the respective stages. As in the proof of Match security for TLS1.3-full-1RTT, The security bound arises as the birthday bound for two honest sessions choosing the same nonce and group element; this not happening ensures at most two partners share the same session identifier.
We need to show the seven properties of Match security (cf. Definition 4.1).
1. Sessions with the same session identifier for some stage hold the same key at that stage.
The session identifiers in each stage include the Diffie-Hellman shares g x and g y (through the CKS and SKS messages, fixing the only key input DHE = g xy to all derived stage keys (recall that PSK = 0 in the TLS 1.3 full 1-RTT handshake). Furthermore, for each stage, the session identifier includes all handshake messages that enter the key derivation: for stages 1 and 2 messages up to SKS, for stages 3-5 messages up to SF, and for stage 6 all messages (up to CF). In each stage, the session identifier hence determines all inputs to the key derivation, and agreement on it thus ensures agreement on the stage key.

Sessions with the same session identifier for some stage have opposite roles, except for potential multiple responders in replayable stages.
Assuming at most two sessions share the same session identifier (which we show below), two initiator (client) or responder (server) sessions never hold the same session identifier as they never accept wrong-role incoming messages, and the initial Hello messages are typed with the sender's role. There are no replayable stages in the TLS 1.3 full 1-RTT handshake. 3. Sessions with the same session identifier for some stage agree on that stage's authentication level. By definition, the authentication for stages 1-2 and 3-5 are fixed to unauth and unilateral (from stage 3 on), respectively, hence agreed upon by all sessions. For the last stage, the presence of CR, CCRT, and CCV in sid 6 unambiguously determines if, from stage 6 on, keys are mutually authenticated (and unilaterally otherwise). 4. Sessions with the same session identifier for some stage share the same contributive identifier. This holds due to, for each stage i, the contributive identifier cid i being final and equal to sid i once the session identifier is set.

Sessions are partnered with the intended (authenticated) participant.
This case only applies to unilaterally or mutually authenticated stages, which is achieved, possibly retroactively, when reaching stages 3, resp. stage 6 (only if the client authenticates). In the TLS 1.3 full 1-RTT handshake, peer identities are learned through the Certificate messages. As we are only concerned with honest client and server sessions for Match security, which will only send certificates attesting their own identity, agreement on SCRT ensures agreeing on the server (responder) identity, and vice versa for CCRT and the client (initiator) identity. Such agreement is ensured through including SCRT in the session identifier for stage 3 for unilateral authentication, and SCRT and CCRT for mutual authentication in sid 6 : once two sessions reach these stages and agree on sid 3 , resp. sid 6 , they (retroactively) also agree on the intended (responder, resp. initiator) peer. 6. Session identifiers are distinct for different stages. This holds trivially as each stage's session identifier has a unique label. 7. At most two sessions have the same session identifier at any non-replayable stage.
Recall that all session identifiers held by some session include that session's random nonce and Diffie-Hellman share. Therefore, for a threefold collision among session identifiers of honest parties, some session would need to pick the same group element and nonce as one other session (which then may be partnered through a regular protocol run to some third session). The probability for such collision to happen can be bounded from above by the birthday bound n 2 s ·1/q ·2 −|nonce| , where n s is the maximum number of sessions, q is the group order, and |nonce| = 256 the nonces' bit length.

Multi-Stage Security
We now come to the core multi-stage security result for the TLS 1.3 full 1-RTT handshake. For the TLS 1.3 full 1-RTT handshake, Multi-Stage security essentially follows from two lines of reasoning. First, the (unforgeable) signatures covering (a collision-resistant hash of) the full Hello messages ensure that session stages with an authenticated peer share exchanged Diffie-Hellman values originating from an honest partner session. Then, all keys are derived in a way ensuring that (a) from a Diffie-Hellman secret unknown to the adversary sessions derive keys indistinguishable from random (under PRF-ODH and PRF assumptions on the HKDF.Extract and HKDF.Expand steps) which (b) are independent, allowing revealing and testing of session keys across different stages.
Proof. In the following, we proceed via a sequence of games. Starting from the Multi-Stage game, we bound the advantage difference of adversary A between any two games by complexity-theoretic assumptions until we reach a game where the adversary A cannot win, i.e., its advantage is at most 0. Game 0. This is the original Multi-Stage game, i.e., Game 1. In a first step, we restrict the adversary A in the Multi-Stage game to make only a single Test query. That is we can formally turn any multi-query adversary A into an adversary A 1 which makes only a single Test query. This reduces its advantage, based on a careful hybrid argument, by a factor at most 1/6n s for the six stages in each of the n s sessions. Note that in the hybrid argument A 1 randomly guesses one of the sessions in advance and only performs the single Test query for this session. The other Test queries of a multi-query attacker are gradually substituted by carefully crafted Reveal queries, where the single-query attacker A 1 needs to know the correct partnering of sessions via session identifiers sid for a correct simulation, e.g., to avoid losses due to bad Reveal-Test combinations on session partners due to the new Reveal queries. The session identifiers sid 1 and sid 2 only contain public information such that partnering is easy to check for them. But then handshake encryption is turned on such that sid 3 , . . . , sid 6 are based on encrypted data. Fortunately, if the single Test query concerns a (client or server) handshake traffic secret then partnering is easy to decide based on sid 1 resp. sid 2 . If the Test query refers to a later key we can reveal the handshake traffic keys of earlier stages, use them to decrypt the subsequent communication, and hence determine sid 3 , . . . , sid 6 as well. We provide the full details of this hybrid argument in Appendix A.
Incorporating the transformation of A into A 1 into the game, i.e., by having the challenger guess the right session and making the adaptations, we get From now on, we can refer to the session label tested at stage i, and we can assume that we know this session number (according to the order of initiated sessions) at the outset of the experiment. Game 2. In this game, the challenger aborts if any two honest sessions compute the same hash value for different inputs in any evaluation of the hash function H. We can break the collision resistance of H in case of this event by letting a reduction B 1 output the two distinct input values to H. Thus: From here on, our security analysis separately considers the two (disjoint) cases that A. the tested session label has no honest contributive partner in the first stage (i.e., there exists no label = label with label.cid 1 = label .cid 1 ), and B. the tested session label has an honest contributive partner in the first stage (i.e., there exists label with label.cid 1 = label .cid 1 ).
This allows us to consider the adversary's advantage separately for these two cases A (denoted "test w/o partner") and B ("test w/ partner"):

Case A. Test without Partner
We first consider the case that the tested session label has no stage-1 contributive partner, which implies it does not have a contributive partner in any stage. By definition, an adversary cannot win if the Test query issued to such session is in a stage that, at the time of the test query, has an unauthenticated peer. Here, authentication refers to the rectified level, because the Test oracle checks against this refined property. Hence, for a tested client session, Test (for any stage) cannot be issued before stage 3 is reached and later only if corruption of the client or the partnered server has not taken place before stage 3. Else the adversary loses the game. For a server session, Test can only be issued when stage 6 is reached and client authentication is performed. Here, again, the client cannot be corrupted earlier, else the rectified authentication level would be unauthenticated. Game A.0. Equals G 2 with adversary restricted to test a session without honest contributive partner in the first stage. Adv Game A.1. In this game, we let the challenger guess the peer identity U ∈ U of the tested session label (observe that one must be set in order for Test to be admissible, as discussed above), and abort if that guess was incorrect (i.e., label.pid = U ). This can reduce A's advantage by a factor at most the number of users n u : Game A.2. We now let the challenger abort the game if the tested session label receives, within the CertificateVerify message from its peer label.pid = U , a valid signature on some (hash value of a) message that has not been computed by any honest session of user U . Note that this message must include the transcript data ClientHello . . . ClientCert resp. ClientHello . . . ServerCert (cf. Table 2). Observe that, as discussed above, when the Test query is issued to label, such a message must have been received, in the case of a client, prior to accepting stage 3 and with no previous corruption of the server; or, in the case of a server, prior to stage 6 when the server is talking to an authenticating client which is not corrupted yet. We can bound the probability of Game G A.2 aborting for this reason by the advantage of an adversary B 2 against the EUF-CMA security of the signature scheme SIG. In the reduction B 2 receives a public key pk U of a signature scheme, computes the long-term keys of all parties U ∈ U \ {U } except U and simulates G A.1 for A 1 . Whenever in that simulation B 2 has to compute a signature under sk U , it does so via its signing oracle. When label receives a valid signature σ on the (hash value of the) message m, adversary B 2 outputs (H(m), σ ) as its forgery. Note that at this point the partnered session cannot be corrupted such that the signature forger does not need to reveal the secret signing key before outputting the forgery.
It remains to argue that the pair (H(m), σ ) constitutes a successful forgery. To see this note that the tested session label computes the hash value H(m) of the message m to verify correctness, but such that no other honest session has computed a signature for this message. According to Game G 2 , this also means that no other honest session has derived the same hash value H(m ) = H(m) for some other message m . We conclude that the hash value H(m) has not been signed by user U before.
It follows for Case A that the adversary cannot make a legitimate Test query at all, unless it forges signatures. Either the sessions do not have a contributive partner, or the sessions in later stages have rejected because of invalid signatures. If the adversary cannot test any session without a contributive partner, it clearly has no advantage in predicting the secret challenge bit b: Case B. Test with Partner Game B.0. This is G 2 where the adversary is restricted to issuing a Test query to a session with an honest contributive partner in the first stage. Adv Game B.1. In this game, we guess a session label = label (from at most n s sessions in the game) and abort the game if label.cid 1 = label .cid 1 , i.e., that label is not the honest contributive partner in stage 1 of the tested session. (Recall that we assume such partner exists in this proof case.) This reduces the adversary's advantage by a factor of at most 1/n s .
Game B.2. In this game, we replace the handshake secret HS derived in the tested session and its contributive partner session with a uniformly random and independent string HS ←$ {0, 1} λ . We employ the dual-snPRF-ODH assumption (Definition 2.3) in order to be able to simulate the computation of HS in a partnered client session for a modified ServerKeyShare message. More precisely, we can turn any adversary capable of distinguishing this change into an adversary B 3 against the dual-snPRF-ODH security of the HKDF.Extract function (taking dES as first and DHE as second input). For this B 3 asks for a PRF challenge on dES computed in the test session and its honest contributive partner. It uses the obtained Diffie-Hellman shares g x , g y within ClientKeyShare and ServerKeyShare of the tested and contributive sessions, and the PRF challenge value as HS in the tested session. If necessary, B 3 uses its PRF-ODH queries to derive HS in the partnered session on differing g y = g y . Providing a sound simulation of either G B.1 (if the bit sampled by the dual-snPRF-ODH challenger was 0 and thus HS = HKDF.Extract(dES, g xy )), or G B.2 (if the bit sampled by the dual-snPRF-ODH challenger was 1 and thus HS ←$ {0, 1} λ ), this bounds the advantage difference of A as: Game B.3. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value HS replaced in G B.2 . This affects the derivation of the client handshake traffic secret CHTS, the server handshake traffic secret SHTS and the derived handshake secret dHS in the target session and its matching partner, and the derived handshake secret dHS in all sessions using the same handshake secret HS. Note that for CHTS and SHTS, these values are distinct from any other session using the same handshake secret value HS, as the evaluation also takes as input the hash value H 2 = H(CH SH), (where CH and SH contain the client and server random values r c , r s respectively) and by Game G 2 we exclude hash collisions. We replace the derivation of CHTS, SHTS and dHS in such sessions with random values CHTS, SHTS, dHS ←$ {0, 1} λ . To ensure consistency, we replace derivations of dHS with the replaced dHS sampled by the first session to evaluate HKDF.Expand using HS. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by the previous game, HS is a uniformly random value, and the replacement is sound. Thus: We note that in this game we have now replaced all stages' keys in the tested session with uniformly random values which, in the protocol execution, are independent of values in any non-partnered session to the tested session. Thus: Combining the given single bounds yields the security statement below: Adv

Security Analysis of the TLS 1.3 PSK/PSK-(EC)DHE (with Optional 0-RTT) Handshakes
We now turn to analyzing the TLS 1.3 pre-shared key handshakes, with and without Diffie-Hellman key exchange (PSK-(EC)DHE, resp. PSK) and with optional 0-RTT keys, in the pre-shared-secret multi-stage key exchange (sMSKE) model. The 0-RTT keys ETS/EEMS are always mutually authenticated, the handshake traffic keys tk chs /tk shs are initially unauthenticated, all non-0-RTT keys reach unilateral authentication with stage 5 and mutual authentication with stage 8. (It is not straightforward to see why some PSK-(EC)DHE keys are not considered to be immediately mutually authenticated, in contrast to keys from the PSK-only handshake. Consider the handshake traffic keys in the PSK-(EC)DHE handshake: in the model, the adversary A could send its own g x share to a server session; the server will derive the handshake traffic keys from PSK and DHE. Those keys should now be considered forward secret (due to the ephemeral DH shares); however, when A corrupts PSK, it can compute the handshake traffic keys. Hence, these keys cannot be treated as forward secret and mutually authenticated at the same time.

Protocol Properties
• Forward secrecy of the PSK handshake depends on whether an ephemeral Diffie-Hellman key exchange is performed: -for PSK-only, FS = ∞: The PSK-only handshake does not provide any forward secrecy.

Session and Contributive Identifiers
As for the full 1-RTT handshake (cf. Sect. 5), we define the session identifiers over the unencrypted handshake messages; each stage's identifier includes a label and all handshake messages up to when that stage accepts:

TLS 1.3 PSK-only (0-RTT optional)
We can begin to give our security results for the TLS 1.3 PSK-only 0-RTT handshake. We start with Match security. where n s is the maximum number of sessions, n p is the maximum number of pre-shared secrets, |P| is the size of the pre-shared secret space, and |nonce| = 256 is the bit length of the nonces.
Recall that Match security is a soundness property of the session identifiers. From our definition of session identifiers above, it follows immediately that partnered sessions agree on the derived key, opposite roles, authentication properties, contributive identifiers, and the respective stages. As in the proof of Match security for TLS1.3-full-1RTT, the security bound arises as the birthday bound for two honest sessions choosing the same nonce; this not happening ensures at most two partners share the same session identifier.
Proof. We need to show the seven properties of Match security (cf. Definition 4.1).

Sessions with the same session identifier for some stage hold the same key at that stage.
The session identifiers in each stage include the pre-shared identifier pssid = pskid (through the CPSK and SPSK messages, fixing the only key input PSK (as both parties agree upon a mapping pss U,V (pssid) = pss = PSK to all derived stage keys (recall that DHE = 0 in the TLS 1.3 PSK-only 0-RTT handshake). Furthermore, for each stage, the session identifier includes all handshake messages that enter the key derivation: for stages 1 and 2 messages up to CPSK for stages 3 and 4 messages up to SPSK, for stages 5, 6, 7 messages up to SF, and for stage 8 all messages (up to CF). In each stage, the session identifier hence determines all inputs to the key derivation, and agreement on it thus ensures agreement on the stage key.

Sessions with the same session identifier for some stage have opposite roles, except for potential multiple responders in replayable stages.
Assuming at most two sessions share the same session identifier (which we show below), two initiator (client) or responder (server) sessions never hold the same session identifier as they never accept wrong-role incoming messages, and the initial Hello messages are typed with the sender's role. This is excluding stages 1 and 2, which are replayable stages in the TLS 1.3 PSK-only 0-RTT handshake. 3. Sessions with the same session identifier for some stage agree on that stage's authentication level. All stages in the TLS 1.3 PSK-only 0-RTT handshake are mutually authenticated, so this is trivially true. 4. Sessions with the same session identifier for some stage share the same contributive identifier. This holds due to, for each stage i, the contributive identifier cid i being final and equal to sid i once the session identifier is set.

Sessions are partnered with the intended (authenticated) participant and share the same key identifier.
All session identifiers include the pssid and binder values sent as part of the ClientHello. The pssid thus is trivially agreed upon. The binder value is derived from that PSK through a sequence of HKDF/HMAC computations. If we treat HMAC as an unkeyed collision-resistant hash function over both inputs, the key and the message space, agreement on binder implies agreement on PSK. This step is necessary, as A can set multiple PSK values to share the same pssid, and thus a pssid does not necessarily uniquely determine a pre-shared secret PSK from each peer's perspective. Instead, we use binder to uniquely determine agreement upon PSK between peers. As all PSK values are chosen uniformly at random within the NewSecret query, they collide only with negligible probability, bounded by the birthday bound n 2 p /|P|, where P is the pre-shared secret space and n p the maximum number of pre-shared secrets. Therefore, agreement on binder and PSK finally implies that pssid, as interpreted by the partnered client and server session, originates from the same NewSecret call. This, from the perspective of both client and server, uniquely identifies the respective peer's identity and hence ensures agreement on the intended peers. 6. Session identifiers are distinct for different stages. This holds trivially as each stage's session identifier has a unique label. 7. At most two sessions have the same session identifier at any non-replayable stage.
Recall that stages 1 and 2 are replayable, so we only need to consider stages i ∈ {3, 4, 5, 6, 7, 8}. Observe that all session identifiers from these stages include a client and server random nonce (r c and r s respectively), through the ClientHello and ServerHello messages. Therefore, for a threefold collision among session identifiers of honest parties, some session would need to pick the same nonce as one other session (which then may be partnered through a regular protocol run to some third session). The probability for such collision to happen can be bounded from above by the birthday bound n 2 s · 2 −|nonce| , where n s is the maximum number of sessions, and |nonce| = 256 the nonces' bit length.

where n s is the maximum number of sessions, n u is the maximum number of users, and n p is the maximum number of pre-shared secrets.
For the TLS 1.3 PSK 0-RTT handshake, Multi-Stage security follows from the security of the pre-shared key: all keys are derived from a pre-shared secret PSK unknown to the adversary (since the PSK mode is not forward secret, PSK may not be corrupted in the tested session) As such, derived keys are indistinguishable from random (under PRF assumptions on the HKDF.Extract and HKDF.Expand steps) which are independent, allowing revealing and testing of session keys across different stages.
Proof. As before, we proceed via a sequence of games, bounding the differences between games via a series of assumptions until we demonstrate that A's advantage in winning the final game is 0. Game 0. This is the original Multi-Stage game, i.e.,

Game 1.
We restrict A to a single Test query, reducing its advantage by a factor of at most 1/8n s . Formally, we construct an adversary from A making only a single Test query via a hybrid argument, analogously to the proof of Theorem 5.2 on page 27, detailed in Appendix A.
From now on, we can refer to the session label tested at stage i, and assume that we know this session in advance. Game 2. In this game, the challenger aborts if any two honest sessions compute the same hash value for different inputs in any evaluation of the hash function H. If this event occurs, this can be used to break the collision resistance of H by letting a reduction B 1 (with approximately the same running time as A) output the two distinct input values to H. Thus:

Game 3.
In this game, the challenger guesses the pre-shared secret PSK used in the tested session, and aborts the game if that guess was incorrect. This reduces A's advantage by a factor of at most 1/n p for n p being the maximum number of registered pre-shared secrets, thus: Game 4. In this game, we replace the outputs of the pseudorandom function HKDF. Extract in all evaluations using the tested session's guessed pre-shared secret PSK as a key by random values. This affects the derivation of the early secret ES in any session using the same shared PSK. We replace the derivation of ES in such sessions with a random value ES ←$ {0, 1} λ . We can bound the difference this step introduces in the advantage of A by the dual PRF security of HKDF.Extract. Note that any successful adversary cannot issue a Corrupt query to reveal the PSK used in the tested session, and thus the pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus: Game 5. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value ES replaced in G 4 . This affects the derivation of the derived early secret dES, the binder key BK, the early traffic secret ETS, and the early exporter master secret EEMS in any session using the same early secret value ES due to the stage being replayable. We replace the derivation of dES, BK, ETS and EEMS in such sessions with random values dES, BK, ETS, EEMS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by Game G 4 , ES is an unknown and uniformly random value, and this replacement is sound. Thus: At this point, we have replaced the stage 1 and stage 2 keys ( ETS and EEMS, respectively). We note that if A issues a Reveal(label, i) query to a session label such that the tested session label.sid i = label .sid i , then A would lose the game. Since these stages are replayable, there may be multiple such sessions such that label.sid i = label .sid i , however if any of these stages is revealed, A loses the game. Game 6. In this game, we replace the pseudorandom function HKDF.Extract in all evaluations using the value dES replaced in G 5 . This affects the derivation of the handshake secret HS in any session using the same derived early secret value dES, as the derivation of HS includes no additional entropy. We replace the derivation of HS in such sessions with a random value HS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Extract. Note that by the previous game, dES is a uniformly random value, and the simulation is sound. Thus:

Game 7.
In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value HS replaced in G 6 . This affects the derivation of the client handshake traffic secret CHTS, the server handshake traffic secret SHTS in the target session and (if it exists) its matching partner, and the derived handshake secret dHS in all sessions using the same handshake secret HS. Note that for CHTS and SHTS, these values are distinct from any other session using the same handshake secret value HS, as the evaluation also takes as input the hash value H 2 = H(CH CPSK SH SPSK), where CH and SH contain the client and server random values r c , r s respectively, and by Game G 2 we exclude hash collisions. However, dHS may be derived in multiple sessions, as it includes no additional entropy in its computation. We replace the derivation of CHTS, SHTS and dHS in such sessions with random values CHTS, SHTS, dHS ←$ {0, 1} λ . To ensure consistency, we replace derivations of dHS with the replaced dHS sampled by the first session to evaluate HKDF.Expand using HS. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by the previous game, HS is a uniformly random value, and the replacement is sound. Thus: Game 8. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the values CHTS, SHTS replaced in G 7 . This affects the derivation of the client handshake traffic key tk chs , and the server handshake traffic key tk shs in the target session and its matching partner. We replace the derivation of tk chs and tk shs with random values tk chs ←$ {0, 1} L and tk shs ←$ {0, 1} L , where L indicates the sum of key length and iv length for the negotiated AEAD scheme. We can bound the difference that this step introduces in the advantage of A by the security of two evaluations of the pseudorandom functions HKDF.Expand. Note that by the previous game CHTS and SHTS are uniformly random values, and these replacements are sound. Thus: Game 9. In this game, we replace the pseudorandom function HKDF.Extract in all evaluations of the value dHS replaced in G 8 . This affects the derivation of the master secret MS in any session using the same derived handshake secret dHS. We replace the derivation of MS in such sessions with the random value MS ←$ {0, 1} λ . MS may be derived in multiple sessions, as it includes no additional entropy in its computation. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Extract. Note that by Game G 7 , dHS is a uniformly random value and this replacement is sound. Thus: We can bound the difference that this step introduces in the advantage of A by the secret of the pseudorandom function HKDF.Expand. Note that by the previous game MS is a uniformly random and independent value, and these replacements are sound. Thus: In Game G 10 we have now replaced all stages' keys in the tested session with uniformly random values independent from the protocol execution, and thus: Combining the given single bounds yields the overall security statement.

TLS 1.3 PSK-(EC)DHE (0-RTT optional)
We can now turn to the security results for the TLS 1.3 PSK-(EC)DHE 0-RTT handshake, starting again with Match security.
where n s is the maximum number of sessions, q is the group order, n p is the maximum number of pre-shared secrets, |P| is the size of the pre-shared secret space, and |nonce| = 256 is the bit length of the nonces.
As before, the soundness properties of Match security follow immediately from our definition of session identifiers, with the security bound arising as the birthday bound for two honest sessions choosing the same nonce and group element. The proof hence closely follows the one for Theorem 6.1.
Proof. We need to show the seven properties of Match security (cf. Definition 4.1).

Sessions with the same session identifier for some stage hold the same key at that stage.
The session identifiers in each stage include both the pre-shared identifier pskid and the Diffie-Hellman shares g x and g y (through the CPSK and SPSK, and CKS, SKS messages respectively), fixing both the pre-shared key input PSK and the Diffie-Hellman key input DHE = g xy for all derived stage keys. Furthermore, for each stage, the session identifier includes all handshake messages that enter the key derivation: for stages 1 and 2 messages up to CPSK, for stages 3 and 4 messages up to SPSK, for stages 5, 6, 7 messages up to SF, and for stage 8 all messages (up to CF). In each stage, the session identifier hence determines all inputs to the key derivation, and agreement on it thus ensures agreement on the stage key.

Sessions with the same session identifier for some stage have opposite roles, except for potential multiple responders in replayable stages.
Assuming at most two sessions share the same session identifier (which we show below), two initiator (client) or responder (server) sessions never hold the same session identifier as they never accept wrong-role incoming messages, and the initial Hello messages are typed with the sender's role. This is excluding stages 1 and 2, which are replayable stages in the TLS 1.3 PSK-(EC)DHE 0-RTT handshake.

Sessions with the same session identifier for some stage agree on that stage's authentication level.
By definition, the vector determining (upgradable) authentication is fixed to ((1, 1), (2,2), (5,8), (5,8), (5,8), (6,8), (7,8), (8,8)), to which hence trivially all sessions agree. 4. Sessions with the same session identifier for some stage share the same contributive identifier. This holds due to, for each stage i, the contributive identifier cid i being final and equal to sid i once the session identifier is set. 5. Sessions are partnered with the intended (authenticated) participant and share the same key identifier. All session identifiers include the pssid and binder values sent as part of the ClientHello. The pssid thus is trivially agreed upon and uniquely determining a pre-shared secret PSK from each peer's perspective. The binder value is derived from that PSK through a sequence of HKDF/HMAC computations. If we treat HMAC as an unkeyed collision-resistant hash function over both inputs, the key and the message space, agreement on binder implies agreement on PSK. This step is necessary, as A can set multiple PSK values to share the same pssid, and thus a pssid does not necessarily uniquely determine a pre-shared secret PSK from each peer's perspective. Instead, we use binder to uniquely determine agreement upon PSK between peers. As all PSK values are chosen uniformly at random within the NewSecret query, they collide only with negligible probability, bounded by the birthday bound n 2 p /|P|, where P is the pre-shared secret space and n p the maximum number of pre-shared secrets. Therefore, agreement on binder and PSK finally implies that pssid, as interpreted by the partnered client and server session, originates from the same NewSecret call. This, from the perspective of both client and server, uniquely identifies the respective peer's identity and hence ensures agreement on the intended peers.

Session identifiers are distinct for different stages.
This holds trivially as each stage's session identifier has a unique label. 7. At most two sessions have the same session identifier at any non-replayable stage.
Recall that stages 1 and 2 are replayable, so we consider only stages i ∈ {3, 4, 5, 6, 7, 8}. Recall that all session identifiers from these stages held by some session include a client and server random nonce and Diffie-Hellman share, as all session identifiers contain both the ClientHello and ServerHello messages. Therefore, for a threefold collision among session identifiers of honest parties, some session would need to pick the same nonce and group element as one other session (which then may be partnered through a regular protocol run to some third session). The probability for such collision to happen can be bounded from above by the birthday bound n 2 s · 1/q · 2 −|nonce| , where n s is the maximum number of sessions, q is the group order, and |nonce| = 256 the nonces' bit length.

where n s is the maximum number of sessions, n p the maximum number of pre-shared secrets established between any two parties, and n u is the maximum number of users.
For the TLS 1.3 PSK-(EC)DHE 0-RTT handshake, Multi-Stage security essentially follows from two lines of reasoning. First, the (unforgeable) MAC tags covering (a collision-resistant hash of) the full Hello messages ensure that session stages with an authenticated peer share hold exchanged Diffie-Hellman shares originating from an honest partner session. Then, all keys are derived in a way ensuring that (a) for forwardsecret stages, the keys are derived from a Diffie-Hellman secret unknown to the adversary are indistinguishable from random (under PRF-ODH and dual-PRF-sec/PRF-sec assumptions on the HKDF.Extract and HKDF.Expand steps), and for non-forwardsecret stages the keys are derived from a pre-shared secret unknown to the adversary, and are also indistinguishable from random (under PRF assumptions on the HKDF.Expand and HKDF.Extract steps) which (b) are independent, allowing revealing and testing of session keys across different stages.
Proof. Again, we proceed via a sequence of games starting from the Multi-Stage game and bounding the advantage (differences) of adversary A. Game 0. This is the original Multi-Stage game, i.e., Game 1. We again restrict A to a single Test query, reducing its advantage by a factor of at most 1/8n s via a hybrid argument analogous to the one in the proof of Theorem 5.2 on page 27, detailed in Appendix A.
From now on, we can refer to the session label tested at stage i, and assume to know the session in advance. Game 2. In this game, the challenger aborts if any two honest sessions compute the same hash value for different inputs in any evaluation of the hash function H. We can break the collision resistance of H in case of this event by letting a reduction B 1 output the two distinct input values to H. Thus: From this point, our analysis separately considers the following three (disjoint) cases: A. that the tested session label has no honest contributive partner in the third stage (i.e., there exists no label = label with label.cid 3 = label .cid 3 ), and, B. the tested session label has an honest contributive partner in the third stage (i.e., there exists label with label.cid 3 = label .cid 3  This allows us to consider the adversary's advantage separately for cases A (denoted "test w/o partner"), B (denoted "NFS test w/ partner") and C ("FS test w/ partner"):

Case A. Test without Partner
As before, we first consider the case that the tested session label has no stage 3 contributive partner. For tested initiator sessions, this means that there exists no honest session that has output the received SH, SKS, and SPSK messages. For tested responder session, this means that there exists no honest initiator session that has output the received CH, CKS, or CPSK messages. Since these messages are included in all subsequent stage session identifiers, this implies the tested session does not have a contributive partner in any stage. By definition, an adversary cannot win if the Test query issued to such a session is in a stage that, at the time of the test query, has an unauthenticated peer (where authentication refers to the rectified notion). For a tested responder session without an honest contributive partner in stage 3, a Test query can only be issued to the session when it reaches stage 8. For a tested initiator session without an honest contributive partner in stage 3, a Test query can only be issued to the session when it reaches stage 5. Game A.0. This is identical to Game G 2 with adversary restricted to testing a session without an honest contributive partner in the third stage. Game A.1. In this game, the challenger guesses the pre-shared secret PSK used in the tested session, and aborts the game if that guess was incorrect. This reduces A's advantage by a factor of at most 1/n p (for n p the maximum number of pre-shared secrets), thus: Game A.2. In this game, the challenger aborts immediately if the initiator (resp. responder) session with label label accepts in the fifth (resp. eighth) stage without an honest contributive partner in stage 3. Let abort G A.2 ,A acc denote the event this occurs in G A.2 . Thus: Note that Case A restricts A to issuing a Test query to a session without an honest contributive partner in stage 3. Because of the authentication type of TLS1.3-PSK-(EC)DHE-0RTT, this Test query can only be issued to the initiator (resp. responder) session after it reaches stage 5 (resp. 8). Since G A.2 is aborted when the session reaches those stages, a successful adversary cannot issue such a query, and thus: We now turn to bounding the probability that abort G A.2 ,A acc occurs. Game A.3. In this game, the challenger guesses a session (from at most n s sessions in the game) and aborts if the guessed session is not the first initiator (resp. responder) session which accepts in the fifth (resp. eighth) stage without an honest contributive partner in stage 3. If the challenger guesses correctly (which happens with probability at least 1/n s ), then this game aborts at exactly the same time as the previous game, and thus: We restrict A from making a Corrupt(U, V, k) query such that label.id = U , label.pid = V , label.pssid = k, and show that this does not impact A's advantage in winning this case. By the definition of the case, there does not exist a session label such that label .cid 3 = label.cid 3 where A's Test query is issued to label. Since PSK-(EC)DHE mode is unilaterally authenticated in stage 5 and mutually authenticated in stage 8, if the adversary issues a Corrupt(U, V, k) query before the tested session label (without an honest contributive partner in stage 3) reaches accept in its partner's authenticating stage, when A issues a Test(label, i) query (where i ∈ {1, . . . , 8}) the lost flag is set and A will lose the game. By the previous games, we abort when the initiator session label (resp. responder session) reaches stage 5 (resp. stage 8) without an honest contributive partner, and thus A will never issue a Corrupt(U, V, k) query. In the following games, this will allow us to replace the pre-shared secret pss in the tested session (and all sessions with the same pss value) without being inconsistent or detectable with regard to the Corrupt query. In what follows, let pss U,V,k be the guessed pre-shared secret. Game A.4. In this game, we replace the outputs of the pseudorandom function HKDF.Extract in all evaluations using the tested session's guessed pre-shared secret pss U,V,k as a key by random values. This affects the derivation of the early secret ES in any session using the same shared PSK. We replace the derivation of ES in such sessions with a random value ES ←$ {0, 1} λ . We can bound the difference this step introduces in the advantage of A by the (dual) security of the pseudorandom function HKDF.Extract. Note that any successful adversary cannot issue a Corrupt query to reveal pss U,V,k used in the tested session, and thus the pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus: Game A.6. In this game, we replace the pseudorandom function HKDF.Extract in all evaluations using the value dES replaced in G A. 5 . This affects the derivation of the handshake secret HS in any session using the same derived early secret value dES, due to the stage being replayable. We replace the derivation of HS in such sessions with a random value HS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Extract. Note that by the previous game, dES is a uniformly random value, and the simulation is sound. Thus: Game A.7. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value HS replaced in G A. 6 . This affects the derivation of the client handshake traffic secret CHTS, the server handshake traffic secret SHTS in the target session and its matching partner, and the derived handshake secret dHS in all sessions using the same handshake secret HS. Note that for CHTS and SHTS, these values are distinct from any other session using the same handshake secret value HS, as the evaluation also takes as input the hash value H 2 = H(CH SH), (where CH and SH contain the client and server random values r c , r s respectively) and by Game G 2 we exclude hash collisions. We replace the derivation of CHTS, SHTS and dHS in such sessions with random values CHTS, SHTS, dHS ←$ {0, 1} λ . To ensure consistency, we replace derivations of dHS with the replaced dHS sampled by the first session to evaluate HKDF.Expand using HS. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by the previous game, HS is a uniformly random value, and the replacement is sound. Thus: Game A.8. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the client handshake traffic secret CHTS replaced in G A. 7 . This affects the derivation of the client handshake traffic key tk chs , and the client finished key fk C in the target session. We replace the derivation of tk chs and fk C with random values tk chs ←$ {0, 1} L , fk C ←$ {0, 1} λ , where L indicates the sum of key length and iv length for the negotiated AEAD scheme. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by the previous game CHTS is a uniformly random value, and these replacements are sound. Thus: Game A.9. In this game, we show how any adversary that manages to trigger abort G A.9 ,A acc (where the tested session has a responder role) can be used to build an adversary B 7 that breaks the existential unforgeability of the HMAC scheme. We let B 7 simulate G A.8 for A as specified, but when the guessed session requires a MAC computation using fk C , B 7 instead invokes a MAC oracle to generate that value. Since fk C is a uniformly random and independent value, this simulation is sound. When A triggers abort G A.9 ,A acc (for responder test sessions), the accepting session must have received a ClientFinished message that is a valid MAC tag over the hash value H 4 = H(CH . . . SF). Since all other sessions hold different session identifiers (as there exists no honest contributive partner in the third stage of the accepting session), no honest party will have requested a MAC tag over that session hash. In addition, by Game G 2 there exist no hash collisions, so the MAC input is distinct to all other MAC inputs for any honest party. Thus, this message was never queried to the MAC oracle and is a forgery. This allows us to bound the probability of A triggering abort G A.9 ,A acc due to a stage-8 accepting responder session without a stage-3 contributive partner by: Note that for the rest of this case, we bound the probability of an adversary triggering abort G A. 9 ,A acc when the tested session has an initiator role. Game A. 10. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the server handshake traffic secret SHTS replaced in G A. 9 . This affects the derivation of the server handshake traffic key tk shs , and the server finished key fk S in the target session. We replace the derivation of tk shs and fk S with random values tk shs , fk S ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by a previous game SHTS is a uniformly random value, and these replacements are sound. Thus: Game A.11. In this game, we show how any adversary that manages to trigger abort G A.11 ,A acc (where the test session is an initiator session) can be used to build an adversary B 9 that breaks the existential unforgeability of the HMAC scheme. We let B 9 simulate G A.10 for A as specified, but when the guessed session or its partner session requires a MAC computation using fk S , B 9 instead invokes a MAC oracle to generate that value. Since fk S is a uniformly random and independent value, this simulation is sound. When A triggers abort G A.11 ,A acc (for initiator test sessions), the accepting session must have received a ServerFinished message that is a valid MAC tag over the hash value H 7 = H(CH . . . SPSK). Since all other sessions hold different session identifiers (as there exists no honest contributive partner in the third stage of the accepting session), no honest party will have requested a MAC tag over that session hash. In addition, by Game G 2 there exist no hash collisions, so the MAC input is distinct to all other MAC inputs for any honest party. Thus, this message was never queried to the MAC oracle and is a forgery. This allows us to bound the probability of A triggering abort G A. 11

Case B. NFS Test with Partner
We now turn to the case where the tested session has an honest contributive partner in the third stage, and A issues a Test(label, i) query such that i ∈ {1, 2}. Game B.0. This is identical to Game G 2 with the adversary testing a session with an honest contributive partner in the third stage. Game B.1. In this game, we guess the pre-shared secret PSK used in the tested session and abort on a wrong guess. This reduces A's advantage by a factor of at most 1/n p , thus: Game B.2. In this game, we let the challenger guess a session (from at most n s in the game) and abort if the session guessed is not the honest contributive partner in stage 3 of the tested session. This reduces A's advantage by a factor of at most 1/n s , and thus: Game B.3. In this game, we replace the outputs of the pseudorandom function HKDF.Extract in all evaluations using the tested session's guessed pre-shared secret pss U,V,k as a key by random values. This affects the derivation of the early secret ES in any session using the same shared PSK. We replace the derivation of ES in such sessions with a random value ES ←$ {0, 1} λ . We can bound the difference this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Extract. Note that any successful adversary cannot issue a Corrupt query to reveal pss U,V,k used in the tested session (as A will issue a query Test(label, i) such that i ∈ {1, 2} by the definition of this case, and A will cause the lost flag to be set if Corrupt(U, V, k) is issued), and thus the pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus:
Game B.4. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value ES replaced in G B.3 . This affects the derivation of the derived early secret dES, the binder key BK, the early traffic secret ETS, and the early exporter master secret EEMS in any session using the same early secret value ES due to the stage being replayable. We replace the derivation of dES, BK, ETS and EEMS in such sessions with random values dES, BK, ETS, EEMS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by Game G B.3 , ES is an unknown and uniformly random value, and this replacement is sound. Thus: We note that at this point, we have replaced the stage 1 and stage 2 keys ( ETS and EEMS, respectively). We note that if A issues a Reveal(label, i) query to a session label such that the tested session label.sid i = label .sid i , then A would lose the game. Since these stages are replayable, then there may be multiple such sessions such that label.sid i = label .sid i . Since ETS and EEMS are now uniformly random values independent of the protocol execution, we have: Combining the given single bounds yields the security statement below:

Case C. FS Test with Partner
We now turn to the third case, "FS Test with Partner", where the tested session has an honest contributive partner in the third stage, and A issues a Test(label, i) query such that i ∈ {3, . . . , 8}. Game C.0. This is identical to Game G 2 with the adversary testing a session with an honest contributive partner in the third stage. Game C.1. In this game, we let the challenger guess a session (from at most n s in the game) and abort if the session guessed is not the honest contributive partner in stage 3 of the tested session. This reduces A's advantage by a factor of at most 1/n s and thus: In this game, we replace the handshake secret HS derived in the tested session and its contributive partner session with a uniformly random and independent string HS ←$ {0, 1} λ . We employ the dual-snPRF-ODH assumption in order to be able to simulate the computation of HS in a partnered client session for a modified ServerKeyShare message. More precisely, we can turn any adversary capable of distinguishing this change into an adversary B 12 against the dual-snPRF-ODH security of the HKDF.Extract function (taking dES as first and DHE as second input). For this, B 12 asks for a PRF challenge on dES. It uses the obtained Diffie-Hellman shares g x , g y within ClientKeyShare and ServerKeyShare of the tested session and its contributive partner session, and the PRF challenge value as HS in the test session. If necessary, B 12 uses its PRF-ODH queries to derive HS in the partnered session on differing g y = g y . Providing a sound simulation of either G C.1 (if the bit sampled by the dual-snPRF-ODH challenger was 0 and thus HS = PRF(dES, g xy )) or G C.2 (if the bit sampled by the dual-snPRF-ODH challenger was 1 and thus HS ←$ {0, 1} λ ), this bounds the advantage difference of A as:
Game C.3. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the value HS replaced in G C.2 . This affects the derivation of the client handshake traffic secret CHTS, the server handshake traffic secret SHTS in the target session and its matching partner, and the derived handshake secret dHS in all sessions using the same handshake secret HS. Note that for CHTS and SHTS, these values are distinct from any other session using the same handshake secret value HS, as the evaluation also takes as input the hash value H 2 = H(CH SH), (where CH and SH contain the client and server random values r c , r s respectively) and by Game G 2 we exclude hash collisions. We replace the derivation of CHTS, SHTS and dHS in such sessions with random values CHTS, SHTS, dHS ←$ {0, 1} λ . To ensure consistency, we replace derivations of dHS with the replaced dHS sampled by the first session to evaluate HKDF.Expand using HS. We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Expand. Note that by the previous game, HS is a uniformly random value, and the replacement is sound. Thus: At this point, CHTS and SHTS are independent of any values computed in any session non-partnered (in stage 1 or 2) with the tested session: distinct session identifiers and no hash collisions (as of Game G 2 ) ensure that the PRF label inputs for deriving CHTS and SHTS are unique. Game C.4. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations using the values CHTS, SHTS replaced in G C. 3 . This affects the derivation of the client handshake traffic key tk chs , and the server handshake traffic key tk shs in the target session and its matching partner. In the derivation, we replace tk chs and tk shs with random values tk chs ←$ {0, 1} L and tk shs ←$ {0, 1} L , where L indicates the sum of key length and iv length for the negotiated AEAD scheme. We can bound the difference that this step introduces in the advantage of A by the security of two evaluations of the pseudorandom functions HKDF.Expand. Note that by the previous game CHTS and SHTS are uniformly random values, and these replacements are sound. Thus:
Game C.5. In this game, we replace the pseudorandom function HKDF.Extract in all evaluations of the value dHS replaced in Game G C. 4 . This affects the derivation of the master secret MS in any session using the same derived handshake secret dHS. We replace the derivation of MS in such sessions with the random value MS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the security of the pseudorandom function HKDF.Extract. Note that by Game G C.3 , dHS is a uniformly random value and this replacement is sound. Thus: Game C.6. In this game, we replace the pseudorandom function HKDF.Expand in all evaluations of the value MS replaced in G C.5 in the targeted session and its matching session. This affects the derivation of the client application traffic secret CATS, the server application traffic secret SATS the exporter master secret EMS and the resumption master secret RMS. For CATS, SATS and EMS, these evaluations are distinct from any other session, as the evaluation of HKDF.Expand also takes as input H 4 = H(CH SH SF) (where CH and SH contain the client and server random values r c and r s respectively), and by Game G 2 we exclude hash collisions. For RMS, this evaluation is distinct from any other session, as the evaluation of HKDF.Expand also takes as input H 5 = H(CH SH SF CF). We replace the derivation of CATS, SATS, EMS, and RMS with random values CATS, SATS, EMS, RMS ←$ {0, 1} λ . We can bound the difference that this step introduces in the advantage of A by the secret of the pseudorandom function HKDF.Expand. Note that by the previous game MS is a uniformly random and independent value, and these replacements are sound. Thus: We note that in this game we have now replaced all stages' keys (with the restriction that the tested stage is from stages [3][4][5][6][7][8] in the tested session with uniformly random values independent of the protocol execution and thus Adv G C. 6 TLS1.3-PSK-(EC)DHE-0RT,A = 0.
Combining the given single bounds yields the security statement below:

Discussion and Conclusions
Our analysis provides several insights into the design and properties of the TLS 1.3 handshake and indicates potential avenues for future research.

Technical Differences from Our Earlier Work
As noted in the introduction, this paper is a successor to earlier versions of our work [38,39,47,53,61]. Here we briefly comment on the technical differences of the analyses of draft-05 in [38], draft-10 and draft-dh in [39], and draft-14 in [53], compared to the final version of TLS 1.3 analyzed in this paper. We focus on three main aspects: the stages identified for the multi-stage analysis, the session identifiers of those stages, and the assumptions used in the security proofs. For the stages and session identifiers, the changes across our series of works are directly related to how the protocol flows and key schedule evolved.
Stages-Main Handshake draft-05-(EC)DHE had 3 stages: handshake traffic key, application traffic key, and the resumption master secret RMS. draft-dh and draft-10-(EC)DHE added the exporter master secret EMS. In this paper we have 6 stages capturing the final RFC's main handshake: handshake traffic keys tk chs and tk shs ; application traffic secrets CATS and SATS; and EMS and RMS. The main reason this paper has 2 stages for the handshake traffic keys and 2 stages for the application traffic secrets is a change to the key schedule: the earlier drafts had 4 secrets (client write key, client write IV, server write key, server write IV) derived from each of two secrets (handshake traffic key and application traffic key), whereas TLS 1.3 has 2 secrets (write key, write IV) derived from each of four secrets (tk chs , tk shs , CATS, SATS).
Stages-PSK Handshake draft-05-SR had 2 stages: handshake traffic key and application traffic key. draft-10-PSK added EMS. draft-14-PSK-0RTT added an early handshake secret and an early application data secret. In this paper we have 8 stages capturing the final RFC's PSK handshake: early traffic secret ETS; early exporter master secret EEMS; handshake traffic keys tk chs and tk shs ; application traffic secrets CATS and SATS; and EMS and RMS. Again the main reason for the additional stages in this paper is the aforementioned change to the key schedule.

Session Identifiers
In the main handshake, session identifiers for the handshake traffic keys are the same across [38,39] and this paper. For the application keys, session identifiers changed based on changes in the message flow which caused changes to the transcript included in the session hash used for key derivation. In particular, draft-05-(EC)DHE and draft-10-(EC)DHE included ClientCertificate in the application key session identifiers but not ServerFinished, whereas TLS 1.3 analyzed in this paper does not include CCRT but does include SF. Similarly, session identifiers for the PSK handshakes changed across the papers due to changes in message ordering and what messages were available to be included in the session hash.
Cryptographic Assumptions-Main Handshake The cryptographic assumptions used in the proofs for draft-05-(EC)DHE, draft-dh, draft-10-(EC)DHE, and this paper remain the same. (In early papers we used the notation PRF-ODH rather than the newer notation snPRF-ODH introduced by [17], but the actual assumption was the same.) Cryptographic Assumptions-PSK Handshake In draft-05, no (EC)DHE variant of the PSK handshake was present (then called "session resumption handshake"), so the proof of draft-05-SR relied solely on symmetric-key assumptions. draft-10-PSK relied on the same assumptions as draft-05-SR, whereas draft-10-PSK-(EC)DHE added an EUF-CMA assumption on HMAC as well as the PRF-ODH assumption. draft-14-PSK-0RTT and draft-14-PSK-(EC)DHE-0RTT added a randomness assumption on HMAC, which in the analysis of the final RFC's TLS1.3-PSK-0RTT and TLS1.3-PSK-(EC)DHE-0RTT in this paper is superseded by a dual-PRF-sec assumption on HKDF.Extract in the multi-stage security bounds. The latter more explicitly indicates those places where HKDF.Extract is keyed through the second argument, which were treated more implicitly in the theorem statements of earlier versions.
Match-security of TLS1.3-PSK-0RTT and TLS1.3-PSK-(EC)DHE-0RTT in this paper adds a collision resistance assumption on HMAC due to the introduction of the PSK binder.

Comments on the TLS 1.3 Design
Value of Key Separation Earlier versions of TLS used the same session key to encrypt the application data as well as the Finished messages at the end of the handshake. This made it impossible to show that the TLS session key satisfied standard Bellare-Rogawaystyle key indistinguishability security [25] as noted in [56,63,86], which motivated the combined handshake+record layer analysis in the authenticated and confidential channel establishment model of [64]. We confirm that the change in keys for encryption of handshake messages allows keys established during the TLS 1.3 handshake to achieve standard key indistinguishability security.
Key Independence All forms of the TLS 1.3 handshake achieve key independence for all stage keys: one can reveal one stage's session key without endangering the security of later-stage keys. This follows from the fact that every key exported or used for encryption is a leaf node in the directed graph representing the key schedule in Fig. 2. Beyond making it amenable to generic composition, key independence safeguards the usage of derived keys against inter-protocol effects of security breakdowns. (Some early drafts had less key independence: for example, in draft-05, each exported key was derived directly from the master secret MS. Since MS was also used to derive other keys, it could not be considered as an output stage key, so every exported key had to be included directly in the main analysis. Contrast this with the final approach in which an exporter master secret EMS is derived from MS, and then all exported keys are derived from EMS: we can treat EMS as an output stage key, and consider the derivation of exported keys as a symmetric protocol using EMS that is composed with the TLS 1.3 handshake protocol.) A "Dent" in the Key Schedule In terms of key derivation, we remark that there is a noteworthy "dent" in the TLS 1.3 key schedule (cf. Fig. 2): all second-level secrets derived from the main (early/handshake/master) secrets are used solely to derive traffic encryption keys (in case of traffic secrets) or further purposes (resumption and exporting), except for the handshake traffic secrets CHTS/SHTS which, beyond deriving the handshake traffic keys, are also used to compute the finished keys. This allowed us to define all but the handshake traffic secrets as output session keys in the multi-stage key exchange sense, while requiring to descend one level further to capture the handshake traffic keys.
A more uniform key schedule could have derived the finished keys in a separate branch from the handshake secret HS, enabling CHTS/SHTS to become first-order session keys on the same level as all others. This in turn would allow a more uniform interface for composition with arbitrary symmetric-key protocol and possibly better support the treatment of key updates (cf. [60]). While this is only a minor issue for the TLS 1.3 analysis, it turned out to complicate a modular analysis of the TLS 1.3 handshake integration into the QUIC protocol [94] as remarked by Delignat-Lavaud et al. [41].

Including the Session Hash in Signatures and Key Derivation
In the TLS 1.3 full handshake, authenticating parties (the server, and sometimes the client) sign (the hash of) all handshake messages up to when the signature is issued (the "session hash"). This is different from TLS 1.2 and earlier, where the server's signature is only over the client and server random nonces and the server's ephemeral public key.
As for key derivation, every stage key is derived using a PRF application that includes the hash of all messages exchange up to the point when the stage key is derived.
In our analysis, the session identifier for each stage is set to be the transcript of messages up to that point. Thus, assuming collision resistance of the hash function, different session identifiers result in different keys. (This was the goal of the session hash which was introduced in response to the triple handshake attack [13] on TLS 1.2 and earlier.) The server signing the transcript also facilitates our proofs of the authentication properties in the full handshake.
Furthermore, if output keys are meant to be used as a channel identifier or for channel binding (with the purpose of leveraging the session protection and authentication properties established by TLS in an application-layer protocol), including the session hash is appropriate. While the standardized tls-unique [8] and proposed tls-unique-prf [65] TLS channel binding methods do not use keys directly for binding, the low cost of including the session hash seems worth it in case an application developer decides to use keying material directly for binding.
In the PSK handshake without (EC)DHE, there is no ephemeral shared secret and the master secret is computed as a series of HKDF.Extract computations over a 0-string using the pre-shared key as the key. All sessions sharing the same pre-shared secret then compute the same master secret. However, since derivation of output keys still uses the session hash as context, output keys are unique assuming uniqueness of protocol messages (which is assured for example by unique nonces).
Encryption of Handshake Messages A major design goal of TLS 1.3 was to enhance privacy (against passive adversaries) by encrypting the second part of the handshake (which contains identity certificates) using the initial handshake traffic keys tk chs and tk shs . Our analysis shows that the handshake traffic keys do indeed have security against passive adversaries (and even active adversaries by the time the client handshake traffic key tk chs is used) and hence this feature of TLS 1.3 does increase the handshake's privacy. The secrecy of the remaining stage keys however do not rely on the handshake being encrypted and would remain secure even if the handshake was done in clear.

Finished Messages
The Finished messages sent by both client and server at the end of the TLS 1.3 handshake are MAC values computed by applying HMAC to the (hash of the) handshake transcript, keyed by dedicated client/server finished secrets fk C /fk S .
Interestingly, according to our proofs, the Finished messages do not contribute to the implicit authentication and secrecy of the output keys in the full handshake or the PSK-only handshake, in the sense that the key exchange would achieve the same security notion without these messages. This is mainly because, in the full handshake, the signatures already authenticate the transcripts, and, in the PSK-only handshake, all keys are derived from the PSK which provides implicit authentication. While Finished messages are not needed to provide implicit authentication in PSK-only handshakes, they would play a role in providing explicit authentication, but our model does not include an explicit authentication property. In the PSK-(EC)DHE handshake, the Finished messages do contribute authentication of the ephemeral Diffie-Hellman public keys under (a key derived from) the PSK. The Finished messages can still generally be interpreted as providing some form of (explicit) session key confirmation and authentication [42,55,61].
Compare these with the case of RSA key transport in the TLS 1.2 full handshake: the analyses of both Krawczyk et al. [70] and Bhargavan et al. [19] note potential weaknesses or require stronger security assumptions if Finished messages are omitted.

Upstream Hashing in Signatures, MACs, and Key Derivation
In signing (resp. MACing) the transcript for authentication as well as in deriving keys via HKDF, TLS 1.3 uses the hash of the current transcript as input; if, e.g., the signature algorithm is a hash-then-sign algorithm, it will then perform an additional hash. From a cryptographic point of view, it would be preferable to insert the full (unhashed) transcript and let the respective signature, MAC, or KDF algorithms opaquely take care of processing this message. For engineering purposes, however, it may be desirable to hash the transcript iteratively, only storing the intermediate values instead of the entire transcript. In our security proof, this upstream hashing introduces the collision-resistant assumption for the hash function (and hence a potential additional source of weaknesses, cf. [15]), which would otherwise be taken care of by the signature, MAC, resp. KDF scheme.

0-RTT Replays and Forward Secrecy
Through our analysis, we capture the effects of replays in the cryptographic security sense, most importantly confirming that the replayability of 0-RTT keys has no negative effects on the cryptographic security of subsequently derived keys. From a practical, application-layer perspective, the potential for 0-RTT replays, however, remains a critical design choice in TLS 1.3 and has been subject of controversial discussion (see, e.g., [83]). The TLS 1.3 standard [90,Sect. 8] acknowledges that "TLS does not provide inherent replay protections for 0-RTT data," and at the same time urges implementations to at least implement a certain basic level of anti-replay protection (like single-use session tickets, ClientHello recording, or freshness checks). The 0-RTT modes of Google's QUIC protocol and TLS 1.3 spawned a series of academic treatments of 0-RTT key exchange [52,62,78] and new designs of forward-secure encryption [30,59] to achieve forward-secret and non-replayable 0-RTT key exchange [46,57] and TLS session resumption [6].
Also, from a cryptographic perspective, the Diffie-Hellman-based 0-RTT mode variant offered a higher level of (forward) security as it did not require the client to keep secret state for resumption and hence only server compromises would affect the secrecy of 0-RTT communication [53,74]. This handshake variant was abandoned with draft-13 in favor of performance and structural simplification.

Open Research Questions
Composition Key exchange protocols would be of limited use if applied in isolation; generally, the derived keys are meant to be deployed in a follow-up (or overall) protocol. Encryption (and authentication) of application data via a (cryptographic) channel protocol is of course a common approach, with the TLS record protocol being a prime example, but other usage in the TLS setting includes exporting of key material or resumption handshakes (via the exporter resp. resumption master secret).
Key exchange protocols secure in the sense of Bellare-Rogaway [25] are indeed amenable to generic secure composition with arbitrary follow-up symmetric protocols as shown by Brzuska et al. [22,26]. Earlier versions of our work [38,61] included adaptations of these composition results to the multi-stage setting, demonstrating that stage keys could be safely used in symmetric key protocols. Those results still apply to our current model, when restricted to stage keys that are marked for external use, are nonreplayable, and when treating the authentication characteristic as fixed at acceptance time, not upgradable. However, it is not obvious how to translate the notions of upgradable authentication or replayability generically to a symmetric key protocol. Given that our focus is on the TLS 1.3 handshake protocol as an authenticated key exchange protocol, we leave a composition result translating replayability and upgradable authentication to future work.
As part of a composed treatment of the overall TLS 1.3 protocol (i.e., handshake and record layer), a conceptual alternative to our treatment of the handshake could be to consider all keys-including handshake traffic keys-to be external (from the handshake's perspective), and rely on the record protocol for handshake encryption. This viewpoint is taken especially in analyses based on verified implementations [40] and would, in the computational setting, require an appropriate amalgamation of channel models capturing the bidirectional, multi-key, multiplexed, and streaming nature of the TLS 1.3 record protocol [23,54,60,85,88]. Post-Quantum Key Exchange While our theorems are mostly generic in terms of cryptographic assumptions, they do directly rely on a Diffie-Hellman assumption in a group. Post-quantum key exchange, however, is usually formulated generically as a key encapsulation mechanism (KEM). If TLS 1.3 is to be extended to support post-quantum or hybrid (i.e., traditional plus post-quantum) key exchange [36], our results on the full 1-RTT and PSK-(EC)DHE modes will need to be revisited in the context of specific post-quantum KEMs or generic properties of KEMs. As we rely on the PRF-ODH assumption [17], an interactive assumption which provides some notion of "active security", it may be the case that translating our proofs to the KEM setting requires use of an IND-CCA KEM. Brendel et al. [16] discuss challenges arising when moving Diffie-Hellman-style key exchanges to the post-quantum setting and Schwabe et al. [93] present a KEM-based alternative to the TLS 1.3 handshake with modified message flow.

Conclusions
In this work, we have updated our prior analyses of the cryptographic security of several draft TLS 1.3 handshakes to the final, standardized version of TLS 1.3 in RFC 8446 [90]. We analyzed the full 1-RTT handshake mode as well as the PSK-based resumption handshake modes, with optional 0-RTT keys, in the reductionist framework of an enhanced multi-stage key exchange security model that captures the various security properties of the several keys derived in TLS 1.3. Our analysis confirmed that the TLS 1.3 handshake follows sound cryptographic design principles and establishes session keys with their desired security properties under standard cryptographic assumptions.
The IETF TLS working group developed TLS 1.3 through a novel, proactively transparent standardization process (cf. [89]) that actively solicited industry and academia alike. In our opinion, this has led to an unprecedented success in having wide-ranging security analyses for a major Internet security protocol prior to its standardization and deployment. While security models or formal method tools can never capture the entirety of real-world threats to such protocols, we believe that, through this process, the boundaries of formal understanding have been pushed to an extent that significantly strengthens confidence in the soundness of TLS 1.3's design. As such, the TLS 1.3 standardization process exemplifies a commendable paradigm which rightfully is being adopted for standardization processes of other major Internet security protocols, and which we encourage other standards bodies to adopt. article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

A Reducing Multiple to Single Test Queries
In this section we give more details on the hybrid argument to reduce adversaries A multi which make multiple Test queries in the Multi-Stage game for the TLS 1.3 handshakes to adversaries A single which restrict themselves to a single Test query. Note that any multi-query adversary cannot make more (reasonable) Test queries than the number n s of overall sessions times the maximum number M of stages. Any adversary making more queries needs to repeat queries for some keys, yielding the reply ⊥, and such queries can be easily sorted out. The main step is the hybrid argument where adversary A single simulates A multi 's attack, making only a single Test query. To do so, for a randomly chosen index n between 1 and the maximum number n s of Test queries, adversary A single returns the genuine keys in the first n − 1 queries of A multi , poses the Test query for the n-th query as its own query, and returns random keys from query n + 1 on. To get the genuine keys for the first queries, A single instead calls the Reveal oracle. The above works along the common argument in hybrid games if we can ensure that A single does not lose because of the additional Reveal queries it makes, i.e., if it reveals a key for the partner of the (only) Test session. One option to ensure this is to demand that A multi never tests a session and its partner. Luckily, the multi-stage security model in Sect. 4 supports this smoothly. Namely, testing a session in stage i for which the tested i flag has been already set to true will immediately return ⊥. This setting of the flag happens in one of the following cases: • When the session itself is tested for the first time in this stage, or • if the session accepts at this stage after a Send call and there is already a partner with tested i = true (triggered in the Send execution for which the session accepts), or • if it is partnered to a tested session and has just accepted at the same stage (triggered through the testing of the partner in the Test oracle execution).
Furthermore, a Test call to a session stage i for which the session has already passed, i.e., st exec = accepted i , also returns ⊥. In other words, any Test query of A multi to a partner of a previous Test query returns ⊥. We can therefore avoid such queries and let A single answer ⊥ for such queries directly. In this case the remaining Reveal queries, substituting the first Test queries in the hybrid argument, cannot cause A single to lose, because now they are for sure not partnered with the (only) Test query of A single . There are two caveats in the above reasoning. First, adversary A single needs to know if two session stages are partnered in order to correctly respond ⊥ for some Test queries. While this is trivial to deduce from the public communication data for sid 1 and sid 2 , the session identifiers sid 3 , . . . , sid 6 contain confidentially transmitted messages, protected through the handshake traffic keys derived in stages 1 and 2 in the TLS 1.3 handshake. But if we let A single know these two internal keys via carefully selected Reveal queries when testing for a stage i ≥ 3 then it can decrypt the communication and decide partnering with other sessions for this stage. Since these further Reveal queries are for earlier stages, they essentially cannot interfere with the stage of the Test session. It is convenient to store the information about tested sessions in an internal array simTested i [label] which is set to true if session label would have been marked as tested i in the game, if A multi would have actually made that query. We write this as an array in order to distinguish this internal list to A single from entries in sessions label. At any point in time, the array simTested in A single 's simulation will hold the same information as the entries tested if A multi had actually made all Test queries. The second issue arises from the fact that internal keys (i.e., keys in stages i with USE i = internal) are overwritten in partners to tested sessions. This can happen in the Send(label, m) command if a partner label of a tested session stage for label (with label .tested i = true) goes to accepted i . Then the security game sets label.key i ← label .key i . The other case can occur in the Test(label, i) query itself if a partnered session label to the tested session is already in state label .st exec = accepted i . Then the internal key of that session label is replaced by the answer for the tested session. But our adversary A single with a single Test query of course only sets one session stage to be tested, influencing at most one further session, whereas A multi 's multiple Test queries may overwrite several keys. Since there is no other mechanism to modify keys in the security model, we need to take care of the issue manually in the simulation of A multi through A single . Fortunately, the internal keys in TLS 1.3 handshake are only used for protecting the data in transport, wrapping and unwrapping the data immediately when sending or receiving. We thus let A single keep internal arrays actualKey i [label] and simKey i [label] for the internal keys (in the actual attack of A single , resp. in the simulation of A multi ) at stage i ∈ {1, 2} and let A single adapt authenticated encryptions with respect to such keys when relaying them between the simulation A multi and Send. Simulating Send queries. A Send(label, m) query is answered by possibly switching encryptions, if the session has been marked as a (virtually) tested session such that keys need to be adapted. Let i = label.stage denote the current stage, meaning that the session has already accepted at stage i: • If i ≤ 1 or m = init or m = continue then pass the command to the own Send oracle. Such messages are not encrypted, and we do not need to re-encrypt the communication data. • If i ≥ 2 and simTested i [label] = true, i.e., the data is encrypted under a key which has potentially changed due to the (virtual) test, then re-encrypt with the client resp. server handshake traffic key in the experiment of A single . Note that session identifiers (esp. for stages i ≥ 3) are not affected by this re-encryption as they are defined over the cleartexts: -If label.role = initiator, i.e., we expect the client to receive a message protected under the server's traffic handshake secret (the stage-2 key), then decrypt m with key simKey 2 [label] and re-encrypt the result with actualKey 2 [label] to m before passing (label, m ) to the own Send oracle. Here, and in the following, we assume that encryption always succeeds for messages different from ⊥, and that ⊥ is encrypted to something which again decrypts to ⊥.
-If label.role = responder, i.e., we expect the server to receive a message protected under the client's traffic handshake secret (the stage-1 key), then decrypt m with key simKey 1 [label] and re-encrypt the result with actualKey 1 [label] to m before passing (label, m ) to the own Send oracle.
• In any other case just forward (label, m) to the own Send oracle.
For the response m from the Send oracle do the following: • If i ≤ 1 then hand back the response unchanged.
• If i ≥ 2 and simTested i [label] = true, then adapt encryption to the keys expected by A multi : · If label.role = initiator then decrypt m with key actualKey 1 [label] and re-encrypt the result with simKey 1 [label] to m before returning m .
· If label.role = responder then decrypt m with key actualKey 2 [label] and re-encrypt the result with simKey 2 [label] to m before returning m .
• In any other case return m.
In addition, check if one needs to set the status of simTested. If the Send call changes the status to accepted i+1 -about which the adversary A single is informed-then do the following: • Except for the copying of the actual key, this now corresponds exactly to the update step in the Send query.
Simulating Test queries. The t-th Test query (label, i) is answered as follows: • If there is no session label, or the session label has not accepted in stage i yet-which is known to the adversary because it gets to learn label.st exec upon successful completion of the i-th stage-or simTested i [label] = true, then immediately return ⊥. • Otherwise proceed as follows: -If t < n then make a Reveal(label, i) call to get the key K and return it to A multi . Set . We note that the checking against a match to label is done analogously to the Send query.
We remark that we do not alter the simulated Reveal oracle but let queries through without modifications. There are cases now where the multi-query adversary A multi may thus obtain a different internal key than expected. But this can only happen for sessions which have been (virtually) tested, such that any Reveal query or such a partnered session where the key has been changed would make A multi lose. We thus ignore these cases and simply continue with the misaligned answer.
Analysis Note that the additional Reveal queries, which A single makes for internal keys in the simulation of Send and Test above, cannot interfere with its only Test query. Recall that A single may make Reveal(label, 1) and Reveal(label, 2) queries when simulating the Send and Test queries.
In the simulated Send query we need to check that the potential Reveal(label, 1) and Reveal(label, 2) queries for the internal keys in stages 1 and 2 do not conflict with the (only) Test query for session label tested which A single makes for stage i. Note that these queries would only be made if the session label has accepted at a stage ≥ 3. Assume that indeed i ∈ {1, 2} and that label tested is partnered with label in that stage i. For this distinguish the point in time when the Test call to label tested is made: • If the Test call for label tested is made later, after session label has continued after accepting in stage i ≤ 2 , then the adversary A multi loses. The reason is that in this case there is a partnered session label which has continued beyond stage i ∈ {1, 2} and has used the internal key already. Such a Test call sets lost ← true according to the model. • If the Test call for label tested has already been made for stage i ∈ {1, 2} before session label has continued after accepting in that stage, then the session (label, i) partnered to (label tested , i) for i ∈ {1, 2} must have been marked as tested, simTested i [label] = true, in a simulation of Test or Send (without using Reveal queries for this stage with cleartext session identifiers). In this case, however, our algorithm A single does not make a Reveal query for this stage but reads off the key from the array actualKey i [label].
Hence, in the first case we can only increase the success probability and in the second case we avoid a conflicting Reveal query straight away. Note that the same is true for the final check in the simulation of Test. It remains to argue the compatibility of the other potential Reveal queries in the simulated Test query. If the n-th query for session label tested and stage i (which A single forwards to its Test oracle) would be partnered with the t-th query (label, i), then the call of A multi to its (simulated) Test oracle for label tested later • would either make A multi lose if the session label tested was at the point of the query already past the state accepted i for the internal key (according to the description of the Test oracle), or • the session label tested is already in state accepted i when the test query here is made, in which case the (simulated) Test oracle would mark that session label tested as tested, simTested i [label tested ] = true, because it is partnered to the now (virtually) tested session label, or • the session label tested is not yet in state accepted i when the test query here is made, in which case later the (simulated) Send oracle would mark that session label tested as tested when it eventually accepts in stage i, simTested i [label tested ] = true, because it is then partnered to the (virtually) tested session label here.
We ignore the first case because it cannot contribute to A multi 's success probability. For the latter two cases it follows that the n-th query of A multi will actually not be forwarded to A single 's oracle Test, because for such marked sessions with simTested i [label tested ] = true the simulated Test oracle immediately returns ⊥. Hence, A single does not make any Test query in these cases at all, and in particular cannot lose because of a Reveal query for a session partnered to the one in the Test query. By the above it follows that A single only sets lost in its attack if A multi does so in the simulation. For the final step in the analysis of the hybrid argument observe that if n = 1 and b test = 0 (for the challenge bit in A single 's game) then our adversary A single only returns random keys to A multi (or error messages ⊥) in simulated Test queries. Furthermore, unless A multi loses the game, the simulation is perfectly sound in the sense that it has the same distribution as in an actual attack; in particular this argument is not violated by the re-encryption. Hence, in this case we have that A single predicts its value b test with the same probability as A multi when receiving only random keys in all (valid) Test queries. Analogously, if n = n Test and b test = 1 then A single always returns genuine keys (or errors) to A multi , again, in a sound simulation unless A multi loses. This therefore corresponds to the case that A multi only receives genuine keys in all (valid) Test queries. For the analysis, let b be the output of A single and b test be its challenge bit. Similarly, let b be the output of A multi in an actual attack for test bit b test . We denote by b = b test resp. b = b test the events that the bit is correct and the lost flag is not set. Then, and noting that the simulation conditioned on b test = 1 and n = n 0 is equivalent to the simulation for b test = 0 and n = n 0 + 1, the telescope sum simplifies to where we used in the last step that the simulation is perfectly sound (if A multi does not lose) and thus at least the probability in an actual attack. We remark that our adversary A single may trigger lost ← true less often than A multi , e.g., because of the omitted Test queries and potential conflicts with Reveal queries. Hence, we obtain