Abstract
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 roundtrip 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 preshared key for authentication (with optional (EC)DHE key exchange and zero roundtrip time key establishment). Our analysis in the reductionist security framework uses a multistage 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.
1 Introduction
The Transport Layer Security (TLS) protocol is one of the most widely deployed cryptographic protocols in practice, protecting numerous web and email 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 largescale deployment, or perhaps because of it, we have witnessed frequent successful attacks against TLS. Starting around 2009, there were many practical attacks on the thencurrent 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])).
1.1 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 multiyear 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, finitefield Diffie–Hellman key exchange, SHA1, RC4, CBC mode, MACthenencodethenencrypt); (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 roundtrip time (1RTT) handshake, which uses publickey certificates for server and (optionally) client authentication, and (elliptic curve) Diffie–Hellman ephemeral ((EC)DHE) key exchange, inspired by Krawczyk’s ‘SIGnandMAc’ (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 roundtrip time (1RTT) until the first application message can be sent (not counting nonTLS networking operations such as DNS lookups or the TCP 3way 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 preshared 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 roundtrip time (0RTT) key establishment, allowing the client to send—along with its first TLS flow—application data encrypted under a key derived from the PSK.
1.2 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].
TLS 1.3 Standard Since TLS 1.3 was published as an RFC in August 2018, some works have addressed the final TLS 1.3 standard. The Selfie attack [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 1RTT handshake by Diemert and Jager [45] and Davis and Günther [43] translated techniques of CohnGordon 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 0RTT handshake [6], running TLS 1.3 over a different network protocol [32], or defining a KEMbased alternative handshake enabling the deployment of postquantum schemes [93].
1.3 Our Contributions
We give a reductionist security analysis of three modes of the TLS 1.3 handshake: the full 1RTT handshake, the PSK handshake (with optional 0RTT mode), and the PSK(EC)DHE handshake (with optional 0RTT mode); based on a cryptographic abstraction of the protocols we provide in Sect. 3. In order to carry out our analysis, we formalize a multistage 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 multistage 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 multistage 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 multistage 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 longterm 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 symmetrickey protocol).

Replayability: whether it is guaranteed that a stage key is not established in result of a replay attack; early stages of the 0RTT 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 preshared keys. Following the BR model, our model of compromise includes longterm key compromise (\(\textsf {Corrupt} \)) and stage key compromise (\(\textsf {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 \(\textsf {Match} \)security notion of [22, 26].
Protocol Analysis We apply our multistage key exchange security model in Sects. 5 and 6 to analyze the three modes of the TLS 1.3 handshake: full 1RTT, PSK, and PSK(EC)DHE, with the latter two having optional 0RTT keys. There are four main classes of stage keys covered in the analysis: early data encryption and export keys (\(\mathrm {ETS}, \mathrm {EEMS}\), only present in the PSK with 0RTT modes); handshake traffic secrets (\(\mathrm {tk}_{\text {chs}}, \mathrm {tk}_{\text {shs}}\)); application traffic secrets (\(\mathrm {CATS}, \mathrm {SATS}\)); and exported keys (\(\mathrm {RMS}\) for session resumption, \(\mathrm {EMS}\) for other exported keys). This results in six stage keys in the full 1RTT 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 \(\mathrm {tk}_{\text {chs}}\), used to encrypt handshake messages from the client to the server. In the full 1RTT 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 nonreplayed. 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 PSKEC(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 \(\texttt {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 1RTT 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 PRFOracleDiffie–Hellman assumption [17, 64] called dualsnPRFODH).
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 \(\texttt {Finished} \) messages, as well as the susceptibility of 0RTT 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 multistage key exchange model of [52] as needed, then applied it to analyze two early drafts of TLS 1.3: draft05, which has the same basic signedDiffie–Hellman structure but a simplified key schedule compared to the final version, and an alternative proposal called draftdh incorporating ideas from the OPTLS design [77], in which servers could have a semistatic DH key share. In [39], we updated our analysis to draft10 and added an analysis of the, by then revised, presharedkey handshake mode. In [53], a subset of us analyzed the 0RTT preshared key and PSK(EC)DHE mode in draft14, as well as the later deprecated Diffie–Hellmanbased 0RTT mode using semistatic DH key shares in draft12, which introduced the notion of replayable stages into the multistage 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 draft16; in another PhD thesis [61], another of us unified the MSKE model and the aforementioned results on the full and PSK handshakes of draft10 and the 0RTT handshakes of draft12 and draft14.
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 0RTT 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 preshared 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 reused 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 preshared key to use. Our analysis assumes that all parties use only TLS 1.3 with a single combination of cryptographic algorithms and do not reuse 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 nontight, 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 1RTT handshake with tight reductions to the strong Diffie–Hellman assumption, translating techniques of CohnGordon 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, posthandshake 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 InternetDraft 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.
2 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.
2.1 Notation
With \(\mathbb {N}\) we denote the natural numbers. We write a bit as \(b \in \{0,1\}\) and a (bit) string as \(s \in \{0,1\}^*\), with s indicating its (binary) length; \(\{0,1\}^n\) is the set of bit strings of length n. We write \(x \leftarrow y\) for the assignment of value y to the variable x and for uniformly sampling x from a (finite) set X.
For an algorithm \(\mathcal {A}\) we write \(x \leftarrow \mathcal {A}(y)\), resp. , for the algorithm deterministically, resp. probabilistically, outputting x on input y. We indicate by \(\mathcal {A}^{\mathcal {O}}\) an algorithm \(\mathcal {A}\) running with oracle access to some other algorithm \(\mathcal {O}\).
2.2 CollisionResistant 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) A hash function \(\textsf {H} :\{0,1\}^* \rightarrow \{0,1\}^\lambda \) maps arbitrarylength messages \(m \in \{0,1\}^*\) to a hash value \(\textsf {H} (m) \in \{0,1\}^\lambda \) of fixed length \(\lambda \in \mathbb {N}\).
We can now measure the collision resistance (\(\textsf {COLL} \)) with respect to an adversary \(\mathcal {A}\) via the advantage
In the common asymptotic notion, we would demand that one cannot construct an efficient adversary \(\mathcal {A}\) where this advantage is nonnegligible with respect to the security parameter \(\lambda \).
2.3 HMAC and HKDF
TLS 1.3 employs HKDF [68, 73] as its key derivation function, with HMAC [12, 67] at its core. We briefly recap their definition and usage.
HMAC [12, 67] is based on a cryptographic hash function \(\textsf {H} :\{0,1\}^* \rightarrow \{0,1\}^\lambda \) and keyed with some key \(K \in \{0,1\}^\lambda \) (larger key material is hashed through \(\textsf {H} \) to obtain a \(\lambda \)bit key). Computing the HMAC value on some message m is then defined as \(\textsf {HMAC} (K, m) := \textsf {H} ((K \oplus \textsf {opad} ) \,\Vert \, \textsf {H} ((K \oplus \textsf {ipad} ) \,\Vert \, m))\), where \(\textsf {opad} \) and \(\textsf {ipad} \) are two \(\lambda \)bit padding values consisting of repeated bytes 0x5c and 0x36, respectively.
HKDF follows the extractthenexpand paradigm for key derivation [68, 73], instantiated with HMAC. We adopt the standard notation for the two HKDF functions: \(\textsf {HKDF} .\textsf {Extract} (\textit{XTS},\textit{SKM})\) on input an (nonsecret and potentially fixed) extractor salt \(\textit{XTS}\) and some (not necessarily uniform) source key material \(\textit{SKM}\) outputs a pseudorandom key \(\textit{PRK}\). \(\textsf {HKDF} .\textsf {Expand} (\textit{PRK},\textit{CTXinfo},L)\) on input a pseudorandom key \(\textit{PRK}\) (from the \(\textsf {Extract} \) step) and some (potentially empty) context information \(\textit{CTXinfo}\) outputs pseudorandom key material \(\textit{KM}\) of length L bits. (For simplicity, we omit the third parameter L in \(\textsf {Expand} \) when \(L = \lambda \), which is the case throughout TLS 1.3 except when deriving traffic keys (cf. Table 2).) Both functions are instantiated with HMAC, where directly \(\textsf {HKDF} .\textsf {Extract} (\textit{XTS},\textit{SKM}) := \textsf {HMAC} (\textit{XTS},\textit{SKM})\) and \(\textsf {HKDF} .\textsf {Expand} \) iteratively invokes HMAC to generate pseudorandom output of the required length (see [73]).
2.4 Dual PRF Security and the PRFODH 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 collisionresistant 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]).
Definition 2.2
(Dual PRF security) Let \(f :\mathcal {K} \times \mathcal {L} \rightarrow \mathcal {O}\) be a pseudorandom function with key space \(\mathcal {K}\) and label space \(\mathcal {L}\) such that \(\mathcal {K} = \mathcal {L}\). We define the dual PRF security of f as the PRF security of \(f^{\textsf {swap} }(k, l) := f(l, k)\) and the according advantage function as
The second assumption, the socalled pseudorandomfunction oracleDiffie–Hellman PRFODH 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 oracleDiffie–Hellman assumption introduced by Abdalla et al. [5] in the context of the DHIES encryption scheme. Basically, the PRFODH assumption states that the value \(\textsf {PRF} (g^{uv},x^{\star })\) for a Diffie–Hellmantype 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 \(\textsf {PRF} (S^u,x)\) and/or \(\textsf {PRF} (T^v,x)\) for chosen values S, T, and x. The PRFODH 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 snPRFODH assumption providing limited oracle access to only a single related value \(\textsf {PRF} (S^u,x)\), as well as its dual variant, dualsnPRFODH. Both have been established by Brendel et al. [17] to hold for \(\textsf {HMAC} \) in the random oracle model under the strong Diffie–Hellman assumption.
Definition 2.3
(snPRFODH and dualsnPRFODH assumptions) Let \(\lambda \in \mathbb {N}\), \(\mathbb {G}\) be a cyclic group of prime order q with generator g and \(\textsf {PRF} :\mathbb {G}\times \{0,1\}^* \rightarrow \{0,1\}^\lambda \) be a pseudorandom function.
We define the snPRFODH security game as follows.

1.
The challenger samples , , and provides \(\mathbb {G}\), g, \(g^u\), and \(g^v\) to \(\mathcal {A}\), who responds with a challenge label \(x^{\star }\).

2.
The challenger computes \(y^{\star }_{0} = \textsf {PRF} (g^{uv},x^{\star })\) and samples uniformly at random, providing \(y^{\star }_{b}\) to \(\mathcal {A}\).

3.
\(\mathcal {A}\) may query a pair (S, x), on which the challenger first ensures that \(S \notin \mathbb {G}\) or \((S, x) = (g^v, x^{\star })\) and, if so, returns \(y \leftarrow \textsf {PRF} (S^u, x)\).

4.
Eventually, \(\mathcal {A}\) stops and outputs a guess \(b^\prime \in \{0,1\}\).
We define the snPRFODH advantage function as
We define the dual variant of the assumption, \(\mathsf {dual}\text { }\mathsf {snPRF}\text { }\mathsf {ODH}\), as the \(\mathsf {snPRF}\text { }\mathsf {ODH}\) assumption for a function \(\textsf {PRF} :\{0,1\}^* \times \mathbb {G}\rightarrow \{0,1\}^\lambda \) with swapped inputs, keyed with a group element in the second input and taking the label as first input.
3 The TLS 1.3 Handshake Protocol
In this section we describe the TLS 1.3 handshake protocol modes, specifically the full one roundtrip time (1RTT) handshake, depicted on the lefthand side of Fig. 1, and the combined zero roundtrip time (\(\text {0RTT} \)) and preshared key handshake, depicted on the righthand 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, posthandshake messages, the record layer protocol, and the alert protocol.
In TLS 1.3, the 1RTT 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 longterm 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.
3.1 KeyExchange Phase
The key exchange phase consists of the exchange of \(\texttt {ClientHello} \) (\(\texttt {CH} \)) and \(\texttt {ServerHello} \) (\(\texttt {SH} \)) messages, during which parameters are negotiated and the core key exchange is performed, using either Diffie–Hellman key exchange or based on a preshared symmetric key.
\(\texttt {ClientHello} \). The client begins by sending the \(\texttt {ClientHello} \) message, which contains \(r_{c}\) (a randomlysampled 256bit nonce value), as well as version and algorithm negotiation information.
Attached to the \(\texttt {ClientHello} \) is the \(\texttt {KeyShare} \) (\(\texttt {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 preshared 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 \({\texttt {CKS} }\) message contains only a single (EC)DHE key share.)
If a preshared secret has been established between the client and the server (either in a previous handshake or via some outofband mechanism) the client may include the \(\texttt {PreSharedKey} \) (\(\texttt {CPSK} \)) extension, which indicates handshake modes (such as PSK or PSK(EC)DHE) that the client supports, and a list of preshared symmetric identities that map to these PSKs. (As for the \(\texttt {KeyShare} \) extension, we do not consider negotiation here and only capture the single PSK entry that client and server agree upon.) If \(\texttt {CPSK} \) is included, the client computes a binder key value \(\mathrm {BK}\) for each preshared key \(\mathrm {PSK}\) in the list, from that a key \(\mathrm {fk}_{B}\), and a value \(\textit{binder}\leftarrow \textsf {HMAC} (\mathrm {fk}_{B}, H(\texttt {CH} ^\dagger ))\) that binds the current \(\texttt {CH} \) message (truncated to exclude the \(\textit{binder}\) value itself) to each \(\mathrm {PSK}\), also included in the \(\texttt {CPSK} \) message and checked by the server. This is captured on the righthand side of Fig. 1.
Finally, if the client wishes to use the preshared secret to send zeroroundtrip time (\(\text {0RTT} \)) data, the client can indicate this by sending a \(\texttt {EarlyDataIndication} \) extension. This will indicate to the server that the client will use the first preshared secret indicated in the \(\texttt {CPSK} \) list to derive an early traffic secret (\(\mathrm {ETS}\)), and early exporter master secret (\(\mathrm {EEMS}\)), and begin sending encrypted data to the server without first requiring the client to receive \(\texttt {ServerHello} \) response.
\(\texttt {ServerHello} \). The next message in the keyexchange phase is the \(\texttt {ServerHello} \) (\(\texttt {SH} \)) message. As in \(\texttt {CH} \), the server will randomly sample a 256bit nonce value \(r_{s}\). The server picks among the various algorithms and parameters offered by the client and responds with its selections. If \(\texttt {CPSK} \) was sent, the server decides whether to accept a PSKbased handshake. If so, then the preshared key identifier pskid associated with the selected \(\mathrm {PSK}\) is sent in the \(\texttt {PreSharedKey} \) (\(\texttt {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 \leftarrow g^y\), sending Y in the \(\texttt {KeyShare} \) (\(\texttt {SKS} \)) extension attached to \(\texttt {SH} \).
At this point, the server has enough information to compute the client handshake traffic secret (\(\mathrm {CHTS}\)) and server handshake traffic secret (\(\mathrm {SHTS}\)) values, and uses these to derive client and server handshake traffic keys (\(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\), respectively). The first part of Fig. 2 shows the key schedule for deriving these keys. Note that we consider \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\) being derived at the same point in time (namely when the handshake secret \(\mathrm {HS}\) becomes available), although \(\mathrm {tk}_{\text {chs}}\) is in principle only needed a bit later.
The server now begins to encrypt all handshake messages under \(\mathrm {tk}_{\text {shs}}\), and any extensions that are not required to establish the server handshake traffic key are sent (and encrypted) in the \(\texttt {EncryptedExtensions} \) (\(\texttt {EE} \)) messages.
3.2 Authentication Phase
The authentication phase now begins. All handshake messages in this phase are encrypted under \(\mathrm {tk}_{\text {shs}}\) or \(\mathrm {tk}_{\text {chs}}\). In the full 1RTT handshake, authentication is based on public key certificates; see the lefthand side of Fig. 1. In preshared 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 righthand side of Fig. 1.
Authentication in Full 1RTT Handshake The server can request publickeybased client authentication by sending a \(\texttt {CertificateRequest} \) (\(\texttt {CR} \)) message. The server will authenticate to the client by using the server’s longterm public keys. Here, the server begins by sending its certificate (carrying its public key) in the \(\texttt {ServerCertificate} \) (\(\texttt {SCRT} \)) message. The server then computes \(\texttt {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 \(\texttt {ServerCertificateVerify} \) message.
Server Key Confirmation and Key Derivation In all handshake modes, the final message that the server sends to the client is the \(\texttt {ServerFinished} \) (\(\texttt {SF} \)) message. The server first derives a server finished key \(\mathrm {fk}_{S}\) from \(\mathrm {SHTS}\) and then computes a MAC tag \(\texttt {SF} \) over the session hash. This value is also encrypted under \(\mathrm {tk}_{\text {shs}}\), sending the output ciphertext to the client. At this point, the server is able to compute the client application traffic secret (\(\mathrm {CATS}\)), the server application traffic secret (\(\mathrm {SATS}\)), and the exporter master secret (\(\mathrm {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 \(\mathrm {tk}_{\text {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.5RTT handshake.
Client Verification, Authentication, Key Confirmation, and Key Derivation The client, upon receiving these messages, checks that the signature \(\texttt {SCV} \) (if in full 1RTT mode) and the MAC \(\texttt {SF} \) verify correctly. If the server has requested client authentication, the client will begin by sending its digital certificate (carrying its publickey) in the \(\texttt {ClientCertificate} \) (\(\texttt {CCRT} \)) message, after which the client will compute its own certificate verify value \(\texttt {CCV} \) by signing the session hash, then send it to the server as the \(\texttt {CCV} \) message. The client finally derives the client finished key \(\mathrm {fk}_{C}\) from \(\mathrm {CHTS}\) and uses \(\mathrm {fk}_{C}\) to compute a MAC tag \(\texttt {CF} \) over the session hash.
Server Verification The server will verify the final MAC (\(\texttt {SF} \)) and optional signature (\(\texttt {SCV} \)) messages of the client.
Handshake Completion At this point both parties can compute the resumption master secret (\(\mathrm {RMS}\)) value that can be used as a preshared key for session resumption in the future. Both parties can now derive the client application traffic key (\(\mathrm {tk}_{\text {capp}}\)) and use the record layer for encrypted communication of application data with the resulting keys.
3.3 NewSessionTicket
The \(\texttt {NewSessionTicket} \) message is a posthandshake message in TLS 1.3 which refers to values from the handshake protocol. The \(\texttt {NewSessionTicket} \) message can be sent by a server to the client (encrypted under a server application traffic key \(\mathrm {tk}_{\text {sapp}}\)) to allow the client to compute values associated with resumption handshakes, including the \(\mathrm {PSK}\) used in resumption as well as an identifier to indicate to the server which preshared key is being used. The \(\texttt {NewSessionTicket} \) message contains two fields that are interesting for this purpose:

\(\texttt {ticket} \texttt {\_} \texttt {nonce} \), which is used by the client as the salt value to derive the preshared key to be used in future handshake for resumption: \(\mathrm {PSK}\leftarrow \textsf {HKDF} .\) \(\textsf {Expand} (\mathrm {RMS},\) “\(\texttt {resumption} \)”, \(\texttt {ticket} \texttt {\_} \texttt {nonce} )\).

\(\texttt {ticket} \), which is an opaque label used to publicly refer to the associated preshared key in future \(\texttt {PreSharedKey} \) messages. In our notation used in Fig. 1, the preshared key identifier \(pskid = \texttt {ticket} \).
In our analysis, we do not capture this \(\texttt {NewSessionTicket} \) message, nor the derivation of \(\mathrm {PSK}\) from \(\mathrm {RMS}\), and instead assume that the mapping between \(\mathrm {PSK}\) and pskid is established in some outofband way. In particular, we do not capture transmission of \(\texttt {NewSessionTicket} \) under a server application traffic key \(\mathrm {tk}_{\text {sapp}}\), as it would impact how we consider the usage of \(\mathrm {SATS}\). In our analysis, we currently consider \(\mathrm {SATS}\) an “\(\texttt {external key} \)“, used in an arbitrary symmetrickey protocol. To capture the transmission of \(\texttt {NewSessionTicket} \), we would need to capture the use of \(\mathrm {SATS}\) in deriving \(\mathrm {tk}_{\text {sapp}}\) and then establishing \(\mathrm {PSK}\). We choose to simplify the analysis by omitting this mechanism and leave this as future work.
4 MultiStage 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 multistage key exchange model in the version by Günther [61] which combines the original model by Fischlin and Günther [52] with followup 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 to actively modify the communication across multiple sessions of the key exchange protocol (spawning them via a \(\textsf {NewSession} \) oracle and directing communication via a \(\textsf {Send} \) oracle). The adversary is further allowed to expose the longterm secrets of interacting honest parties (via a \(\textsf {Corrupt} \) oracle) as well as the session keys in some protocol runs (through a \(\textsf {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 \(\textsf {Test} \) oracle).
The multistage 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 postspecified 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 longterm secret compromise. In a multistage key exchange protocol, forward secrecy may however be reached only from a certain stage on (e.g., due to mixingin forwardsecret key material). The model hence treats stagej 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 realorrandom 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 preshared keys. Our multistage model comes in two flavors that capture both the regular, publickey case (abbreviated as pMSKE) of longterm keys being public/secret key pairs (as in the TLS 1.3 full handshake) as well as the preshared–secret case (abbreviated sMSKE) case where preshared symmetric keys act as longterm secrets (as in the TLS 1.3 resumption handshake).
Replayability. For 0RTT 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 (0RTT) and regular nonreplayable 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 multistage 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 longterm 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:

Longterm keys (such as the signing keys of the server or client, but also their preshared keys), since longterm values have the potential to be compromised, and this is necessary to model forward secrecy; it is captured in our model by the \(\textsf {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 \(\textsf {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 1.3 is not designed to be secure if these values are compromised.

Internal values / session state (e.g., internally computed master secrets or MAC keys); this is disallowed since TLS 1.3 is not designed to be secure if these values are compromised.
Comparison with Previous Multistage Key Exchange Models Compared to the original MSKE model of Fischlin and Günther [52], the most notable changes in our model are the addition which models upgradeable authentication and accommodating both public and preshared 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].
4.1 Syntax
In our model, we explicitly separate some protocolspecific properties (as, e.g., various authentication flavors) from sessionspecific properties (as, e.g., the state of a running session). We represent protocolspecific properties as a vector \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) that captures the following:

\(\textsf {M} \in \mathbb {N}\): the number of stages (i.e., the number of keys derived). (We fix a maximum stage \(\textsf {M} \) only for ease of notation. Note that \(\textsf {M} \) can be arbitrarily large in order to cover protocols where the number of stages is not bounded apriori. Also note that stages and session key derivations may be “back to back,” without further protocol interactions between parties.)

\(\textsf {AUTH} \subseteq \{((u_{1},m_{1}),\dots ,(u_{\textsf {M} },m_{\textsf {M} })) \mid u_{j}, m_{j} \in \{1, \dots , \textsf {M} , \infty \} \}\): a set of vectors of pairs, each vector encoding a supported scheme for authentication and authentication upgrades, for each stage. For example, the ith 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 nondecreasing, and \(u_{i} = \infty \) or \(m_{i} = \infty \) denotes that unilateral, resp. mutual, authentication is never reached for stage i.

\(\textsf {FS} \in \{1,\dots ,\textsf {M} ,\infty \}\): the stage \(j = \textsf {FS} \) from which on keys are forward secret (or \(\infty \) in case of no forward secrecy). (A more general multistage key exchange model could have a vector tracking specifically which subset of stage keys have forward secrecy. We do not need such generality since forward secrecy is monotonic in TLS 1.3.)

\(\textsf {USE} \in \{\textsf {internal} , \textsf {external} \}^{\textsf {M} }\): the usage indicator for each stage, where \(\textsf {USE} _{i}\) indicates the usage of the stagei key. 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 \(\textsf {USE} = (\textsf {internal} : \{1,4\}, \textsf {external} : \{2,3,5\})\) to indicate that usage of keys in stage 1 and 4 is internal, and external for the other stages.

\(\textsf {REPLAY} \in \{\textsf {replayable} , \textsf {nonreplayable} \}^{\textsf {M} }\): the replayability indicator for each stage, where \(\textsf {REPLAY} _{i}\) indicates whether the ith 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 resending the same data in \(\text {0RTT} \) 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 \(\textsf {USE} \); e.g., \(\textsf {REPLAY} = (\textsf {nonreplayable} : \{1,2,3\})\) indicates that all three stages are nonreplayable.
We denote by \(\mathcal {U}\) the set of identities (or users) used to model the participants in the system, each identified by some \(U \in \mathcal {U}\). Sessions of a protocol are uniquely identified (on the administrative level of the model) using a label \(\textsf {label} \in \textsf {LABELS} = \mathcal {U}\times \mathcal {U}\times \mathbb {N}\), where \(\textsf {label} = (U, V, n)\) indicates the nth local session of identity U (the session owner) with V as the intended communication partner.
In the publickey variant of the model (pMSKE), each identity U is associated with a certified longterm public key \(\textsf {pk} _{U}\) and secret key \(\textsf {sk} _{U}\). In the preshared secret setting (sMSKE), a session instead holds an identifier \(\textsf {pssid} \in \{0,1\}^*\) for the preshared secret \(\textsf {pss} \in \mathcal {P}\) (from some preshared secret space \(\mathcal {P}\)) used. The challenger maintains maps \(\textsf {pss} _{U,V}:\{0,1\}^* \rightarrow \mathcal {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 preshared secret identifier \(\textsf {pssid} \) uniquely identifies the peer identity V it is shared with. (Requiring a fixed role in which a preshared 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 \(\textsf {List} _{\textsf {S} }\), where values in square brackets \([\,]\) indicate the default initial value. Some variables have values for each stage \(i \in \{1, \dots , \textsf {M} \}\).

\(\textsf {label} \in \textsf {LABELS} \): the unique (administrative) session label

\(\textsf {id} \in \mathcal {U}\): the identity of the session owner

\(\textsf {pid} \in \mathcal {U}\cup \{*\}\): 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 \(\mathcal {U}\) once by the protocol

\(\textsf {role} \in \{\textsf {initiator} , \textsf {responder} \}\): the session owner’s role in this session

\(\textsf {auth} \in \textsf {AUTH} \): the intended authentication type vector from the set of supported authentication properties \(\textsf {AUTH} \), where \(\textsf {auth} _{i}\) indicates the authentication level pair for stage i, and \(\textsf {auth} _{i,j}\) its jth entry

\(\textsf {pssid} \in \{0,1\}^* \cup \{\bot \}\): In the preshared secret (sMSKE) variant the identifier for the preshared secret (i.e., \(\textsf {pss} _{\textsf {id} ,\textsf {pid} }\) if \(\textsf {role} = \textsf {initiator} \), else \(\textsf {pss} _{\textsf {pid} ,\textsf {id} }\)) to be used in the session; can be initialized with \(\bot \) if \(\textsf {pid} = *\) is unknown and then must be set (once) when \(\textsf {pid} \) is set

\(\textsf {st} _{\textsf {exec} }\in (\textsf {RUNNING} \cup \textsf {ACCEPTED} \cup \textsf {REJECTED} )\): the state of execution [\(\textsf {running} _{0}\)], where \(\textsf {RUNNING} = \{\textsf {running} _{i} \mid i \in \mathbb {N}\cup \{0\}\}\), \(\textsf {ACCEPTED} = \{\textsf {accepted} _{i} \mid i \in \mathbb {N}\}\), \(\textsf {REJECTED} = \{\textsf {rejected} _{i} \mid i \in \mathbb {N}\}\); set to \(\textsf {accepted} _{i}\) in the moment a session accepts the ith key, to \(\textsf {rejected} _{i}\) when the session rejects that key (a session may continue after rejecting in a stage (this models, e.g., servers rejecting 0RTT data from a client, but continuing with the remaining handshake)), and to \(\textsf {running} _{i}\) when a session continues after accepting the ith key

\(\textsf {stage} \in \{0, \dots , \textsf {M} \}\): the current stage [0], where \(\textsf {stage} \) is incremented to i when \(\textsf {st} _{\textsf {exec} }\) reaches \(\textsf {accepted} _{i}\) resp. \(\textsf {rejected} _{i}\)

\(\textsf {sid} \in (\{0,1\}^* \cup \{\bot \})^{\textsf {M} }\): \(\textsf {sid} _{i}\) [\(\bot \)] indicates the session identifier in stage i, set once (and only) upon acceptance in that stage

\(\textsf {cid} \in (\{0,1\}^* \cup \{\bot \})^{\textsf {M} }\): \(\textsf {cid} _{i}\) [\(\bot \)] indicates the contributive identifier in stage i, may be set several times until acceptance in that stage

\(\textsf {key} \in (\{0,1\}^* \cup \{\bot \})^{\textsf {M} }\): \(\textsf {key} _{i}\) [\(\bot \)] indicates the established session key in stage i, set once upon acceptance in that stage

\(\textsf {st} _{\textsf {key} }\in \{\textsf {fresh} , \textsf {revealed} \}^{\textsf {M} }\): \(\textsf {st} _{\textsf {key} ,i}\) [\(\textsf {fresh} \)] indicates the state of the session key in stage i

\(\textsf {tested} \in \{\textsf {true} , \textsf {false} \}^{\textsf {M} }\): test indicator \(\textsf {tested} _{i}\) [\(\textsf {false} \)], where \(\textsf {true} \) means that \(\textsf {key} _{i}\) has been tested

\(\textsf {corrupted} \in \{0, \dots , \textsf {M} , \infty \}\): corruption indicator [\(\infty \)] holding the stage the session was in when a \(\textsf {Corrupt} \) was issued to its owner or intended partner, including the value 0 if the corruption had taken place before the session started, and \(\infty \) if none of the parties is corrupted
By convention, adding a not fully specified tuple \((\textsf {label} ,\textsf {id} ,\textsf {pid} ,\textsf {role} ,\textsf {auth} )\) resp. \((\textsf {label} ,\textsf {id} ,\textsf {pid} ,\textsf {role} ,\textsf {auth} ,\textsf {pssid} )\) to \(\textsf {List} _{\textsf {S} }\) sets all other entries to their default value. As shorthands, for some tuple with (unique) label \(\textsf {label} \) in \(\textsf {List} _{\textsf {S} }\) we furthermore write \(\textsf {label} .X\) for that tuple’s element X and \(\textsf {label} .(X,Y,Z)\) for the vector (X, Y, Z) of that tuple’s elements X, Y, and Z.
We define two distinct sessions \(\textsf {label} \) and \(\textsf {label} '\) to be partnered in stage i if both sessions hold the same session identifier in that stage, i.e., \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \), and require for correctness that two sessions having a nontampered joint execution are partnered in all stages upon acceptance.
Our security model treats corruption of longterm secrets (secret keys for pMSKE, preshared 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 publickey setting (pMSKE), the owner or peer secret key is compromised, or in the preshared secret setting (sMSKE), if the preshared secret used for that session is compromised. Forward secrecy comes into play when determining if keys derived prior to the longterm secret corruption are affected, too. In more precise notation, we say a session \(\textsf {label} \) is corrupted if

for pMSKE, the session’s owner \(\textsf {label} .\textsf {id} \) or intended communication partner \(\textsf {label} .\textsf {pid} \) is corrupted (i.e., \(\{\textsf {label} .\textsf {id} , \textsf {label} .\textsf {pid} \} \cap \textsf {corrupted} \ne \emptyset \)), resp.

for sMSKE, the used preshared secret is corrupted (i.e., \((\textsf {label} .\textsf {id} , \textsf {label} .\textsf {pid} , \textsf {label} .\) \(\textsf {pssid} ) \in \textsf {corrupted} \), the set of corrupted users) if \(\textsf {label} .\textsf {role} = \textsf {initiator} \), resp. \((\textsf {label} .\textsf {pid} , \textsf {label} .\textsf {id} , \textsf {label} .\textsf {pssid} ) \in \textsf {corrupted} \) if \(\textsf {label} .\textsf {role} = \textsf {responder} \).
Upgradable Authentication We capture that the authentication level of some stage may increase, possibly twice, with acceptance of a later stage through a perstage 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 postauthenticates 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 \( \textsf {rect\_auth} _{i}\) of some stage i in a session with intended authentication vector \(\textsf {auth} \), consisting of pairs \((\textsf {auth} _{i,1},\textsf {auth} _{i,2})\) describing the stage in which the ith session key gets unilaterally and mutually authenticated, with corruption indicator \(\textsf {corrupted} \), and with current execution stage \(\textsf {stage} \) as follows:
This encodes that authentication level of stage i is upgraded (to \(\textsf {unilateral} \) or \(\textsf {mutual} \)) when reaching stage \(\textsf {auth} _{i,1}\), resp. \(\textsf {auth} _{i,2}\), only if no corruption affected this session prior to these stages (\(\textsf {auth} _{i,1}\), resp. \(\textsf {auth} _{i,2}\)).
4.2 Adversary Model
We consider a probabilistic polynomialtime (PPT) adversary \(\mathcal {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 multistage 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 \(\textsf {lost} \) (initialized to \(\textsf {false} \)).
The adversary interacts with the protocol via the following queries.

\(\textsf {NewSecret} (U,V,\textsf {pssid} )\): This query is only available in the preshared secret (sMSKE) variant. Generates a fresh secret with identifier \(\textsf {pssid} \) shared between parties U and V, to be used by U in the initiator role and by V in the responder role. If \(\textsf {pss} _{U,V}(\textsf {pssid} )\) is already set, return \(\bot \) to ensure uniqueness of \(\textsf {pssid} \) identifiers between two parties in these roles. Otherwise, sample uniformly at random from the protocol’s preshared secret space \(\mathcal {P}\) and define \(\textsf {pss} _{U,V}(\textsf {pssid} ) := \textsf {pss} \).

\(\textsf {NewSession} (U, V, \textsf {role} , \textsf {auth} {} [, \textsf {pssid} ])\): Creates a new session with a (unique) new label \(\textsf {label} \) for owner identity \(\textsf {id} = U\) with role \(\textsf {role} \), having \(\textsf {pid} = V\) as intended partner (potentially unspecified, indicated by \(V = *\)) and aiming at authentication type \(\textsf {auth} \). In the preshared secret (sMSKE) variant, the additional parameter \(\textsf {pssid} \) identifies the preshared secret to be used, namely \(\textsf {pss} _{U,V}(\textsf {pssid} )\) if \(\textsf {role} = \textsf {initiator} \), resp. \(\textsf {pss} _{V,U}(\textsf {pssid} )\) if \(\textsf {role} = \textsf {responder} \). The identifier might be unspecified at this point (indicated by \(\textsf {pssid} = \bot \)) and may then be set later by the protocol once. Add \((\textsf {label} ,U,V,\textsf {role} ,\textsf {auth} )\), resp. \((\textsf {label} ,U,V,\textsf {role} ,\textsf {auth} ,\textsf {pssid} )\), to \(\textsf {List} _{\textsf {S} }\). If \(\textsf {label} \) is corrupted, set \(\textsf {label} .\textsf {corrupted} \leftarrow 0\). This encodes the information that the session is corrupt right from the beginning. Return \(\textsf {label} \).

\(\textsf {Send} (\textsf {label} , m)\): Sends a message m to the session with label \(\textsf {label} \). If there is no tuple with label \(\textsf {label} \) in \(\textsf {List} _{\textsf {S} }\), return \(\bot \). Otherwise, run the protocol on behalf of U on message m and return the response and the updated state of execution \(\textsf {label} .\textsf {st} _{\textsf {exec} }\). As a special case, if \(\textsf {label} .\textsf {role} = \textsf {initiator} \) and \(m = \textsf {init} \), the protocol is initiated (without any input message). If, during the protocol execution, the state of execution changes to \(\textsf {accepted} _{i}\), the protocol execution is immediately suspended and \(\textsf {accepted} _{i}\) is returned as result to the adversary. The adversary can later trigger the resumption of the protocol execution by issuing a special \(\textsf {Send} (\textsf {label} , \textsf {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 \(\textsf {st} _{\textsf {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 longterm keys in a finegrained manner after any acceptance of a key. If the state of execution changes to \(\textsf {label} .\textsf {st} _{\textsf {exec} }= \textsf {accepted} _{i}\) for some i and there is a partnered session \(\textsf {label} ' \ne \textsf {label} \) in \(\textsf {List} _{\textsf {S} }\) (i.e., \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\)) with \(\textsf {label} '.\textsf {tested} _{i} = \textsf {true} \), then set \(\textsf {label} .\textsf {tested} _{i} \leftarrow \textsf {true} \) and (only if \(\textsf {USE} _{i} = \textsf {internal} \)) \(\textsf {label} .\textsf {key} _{i} \leftarrow \textsf {label} '.\textsf {key} _{i}\). This ensures that, if the partnered session has been tested before, subsequent \(\textsf {Test} \) queries for the session are answered accordingly and, in case it is used internally, this session’s key \(\textsf {key} _{i}\) is set consistently. (Note that for internal keys this implicitly assumes the following property of the laterdefined \(\textsf {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 \(\textsf {label} .\textsf {st} _{\textsf {exec} }= \textsf {accepted} _{i}\) for some i and the session \(\textsf {label} \) is corrupted, then set \(\textsf {label} .\textsf {st} _{\textsf {key} ,i} \leftarrow \textsf {revealed} \).

\(\textsf {Reveal} (\textsf {label} , i)\): Reveals the session key \(\textsf {label} .\textsf {key} _{i}\) of stage i in the session with label \(\textsf {label} \). If there is no session with label \(\textsf {label} \) in \(\textsf {List} _{\textsf {S} }\) or \(\textsf {label} .\textsf {stage} < i\), then return \(\bot \). Otherwise, set \(\textsf {label} .\textsf {st} _{\textsf {key} ,i}\) to \(\textsf {revealed} \) and provide the adversary with \(\textsf {label} .\textsf {key} _{i}\).

\(\textsf {Corrupt} (U)\) or \(\textsf {Corrupt} (U, V, \textsf {pssid} )\): The first query is only used in the publickey (pMSKE) variant, the second query only in the preshared secret (sMSKE) variant. Provide the adversary with the corresponding longterm secret, i.e., \(\textsf {sk} _{U}\) (pMSKE), resp. \(\textsf {pss} _{U,V}(\textsf {pssid} )\) (sMSKE). Add to the set of corrupted entities \(\textsf {corrupted} \) the user U (for pMSKE), resp. (for sMSKE) the global preshared secret identifier \((U, V, \textsf {pssid} )\). Record the time of corruption in each session \(\textsf {label} \) with \(\textsf {label} .\textsf {id} = U\) or \(\textsf {label} .\textsf {pid} = U\) (pMSKE), resp. with \(\textsf {label} .(\textsf {role} ,\textsf {id} ,\textsf {pid} ,\textsf {pssid} ) \in \{(\textsf {initiator} , U, V, \textsf {pssid} ),\) \((\textsf {responder} , V, U, \textsf {pssid} )\}\) (sMSKE), by setting \(\textsf {label} .\textsf {corrupted} \leftarrow \textsf {label} .\textsf {stage} \) (unless \(\textsf {label} .\textsf {corrupted} \ne \infty \) already, in which case corruption had taken place earlier such that we leave the value unchanged). In the nonforwardsecret case, for each such session \(\textsf {label} \) and for all \(i \in \{1, \dots , \textsf {M} \}\), set \(\textsf {label} .\textsf {st} _{\textsf {key} ,i}\) to \(\textsf {revealed} \). I.e., all (previous and future) session keys are considered to be disclosed. In the case of stagej forward secrecy, \(\textsf {st} _{\textsf {key} ,i}\) of each such session \(\textsf {label} \) is instead set to revealed only if \(i < j\) or if \(i > \textsf {stage} \). This means that session keys before the jth stage (where forward secrecy kicks in) as well as keys that have not yet been established are potentially disclosed.

\(\textsf {Test} (\textsf {label} , i)\): Tests the session key of stage i in the session with label \(\textsf {label} \). In the security game this oracle is given a uniformly random test bit \(b_{\textsf {test} }\) as state which is fixed throughout the game. If there is no session with label \(\textsf {label} \) in \(\textsf {List} _{\textsf {S} }\) or if \(\textsf {label} .\textsf {st} _{\textsf {exec} }\ne \textsf {accepted} _{i}\) or \(\textsf {label} .\textsf {tested} _{i} = \textsf {true} \), return \(\bot \). If stage i is internal (i.e., \(\textsf {USE} ^i = \textsf {internal} \)) and there is a partnered session \(\textsf {label} '\) in \(\textsf {List} _{\textsf {S} }\) (i.e., \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\)) with \(\textsf {label} '.\textsf {st} _{\textsf {exec} }\ne \textsf {accepted} _{i}\), set the ‘lost’ flag to \(\textsf {lost} \leftarrow \textsf {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 \(\textsf {label} .{ \textsf {rect\_auth} _{i}} = \textsf {unauth} \), or if \(\textsf {label} .{ \textsf {rect\_auth} _{i}} = \textsf {unilateral} \) and \(\textsf {label} .\textsf {role} = \textsf {responder} \), but there is no session \(\textsf {label} '\) (for \(\textsf {label} \ne \textsf {label} '\)) in \(\textsf {List} _{\textsf {S} }\) with \(\textsf {label} .\textsf {cid} _{i} = \textsf {label} '.\textsf {cid} _{i}\), then set \(\textsf {lost} \leftarrow \textsf {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 \(\textsf {List} _{\textsf {S} }\) entries are only created for honest sessions, i.e., sessions generated by \(\textsf {NewSession} \) queries.) The check is based on the uncorrupted authentication level \( \textsf {rect\_auth} _{i}\) in order to take corruptions between authentication upgrades into account. Otherwise, set \(\textsf {label} .\textsf {tested} _{i}\) to \(\textsf {true} \). If the test bit \(b_{\textsf {test} }\) is 0, sample a key at random from the session key distribution \(\mathcal {D}\). If \(b_{\textsf {test} }= 1\), let \(K \leftarrow \textsf {label} .\textsf {key} _{i}\) be the real session key. If \(\textsf {USE} _{i} = \textsf {internal} \) (i.e., the tested ith key is indicated as being used internally), set \(\textsf {label} .\textsf {key} _{i} \leftarrow K\); in other words, when \(b_{\textsf {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_{\textsf {test} }=1\)) or random (in case \(b_{\textsf {test} }=0\)) key. This distinction between internal and external keys for \(\textsf {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 \(\textsf {label} '\) which has also just accepted the ith key (i.e., \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\) and \(\textsf {label} .\textsf {st} _{\textsf {exec} }= \textsf {label} '.\textsf {st} _{\textsf {exec} }= \textsf {accepted} _{i}\)), then also set \(\textsf {label} '.\textsf {tested} _{i} \leftarrow \textsf {true} \) and (only if \(\textsf {USE} _{i} = \textsf {internal} \)) \(\textsf {label} '.\textsf {key} _{i} \leftarrow \textsf {label} .\textsf {key} _{i}\) to ensure consistency (of later tests and (internal) key usage) in the special case that both \(\textsf {label} \) and \(\textsf {label} '\) are in state \(\textsf {accepted} _{i}\) and, hence, either of them can be tested first. Return K.
4.3 Security of MultiStage 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 randomlooking keys, refined under the term \(\textsf {Multi} \text {}\textsf {Stage} \) security according to the advanced security aspects for multistage key exchange: (stagej) forward secrecy, different authentication modes, and replayability. The \(\textsf {Match} \) property complements this notion by guaranteeing that the specified session identifiers \(\textsf {sid} \) effectively match the partnered sessions, and is likewise adapted to the multistage setting.
4.3.1 Match Security
The notion of \(\textsf {Match} \) security ensures soundness of the session identifiers \(\textsf {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 preshared 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 nonreplayable stage.
The \(\textsf {Match} \) security game \(G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Match} }\) thus is defined as follows.
Definition 4.1
(\(\textsf {Match} \) security) Let \(\textsf {KE} \) be a multistage key exchange protocol with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) and \(\mathcal {A}\) be a PPT adversary interacting with \(\textsf {KE} \) via the queries defined in Sect. 4.2 in the following game \(G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Match} }\):
 Setup.:

In the publickey variant (pMSKE), the challenger generates longterm public/ privatekey pairs for each participant \(U \in \mathcal {U}\).
 Query.:

The adversary \(\mathcal {A}\) receives the generated public keys (pMSKE) and has access to the queries \(\textsf {NewSecret} \), \(\textsf {NewSession} \), \(\textsf {Send} \), \(\textsf {Reveal} \), \(\textsf {Corrupt} \), and \(\textsf {Test} \).
 Stop.:

At some point, the adversary stops with no output.
We say that \(\mathcal {A}\) wins the game, denoted by \(G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Match} } = 1\), if at least one of the following conditions holds:

1.
There exist two distinct labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \) for some stage \(i \in \{1,\dots ,\textsf {M} \}\), but \(\textsf {label} .\textsf {key} _{i} \ne \textsf {label} '.\textsf {key} _{i}\). (Different session keys in some stage of partnered sessions.)

2.
There exist two distinct labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \) for some stage \(i \in \{1,\dots ,\textsf {M} \}\), but \(\textsf {label} .\textsf {role} = \textsf {label} '.\textsf {role} \) and \(\textsf {REPLAY} _{i} = \textsf {nonreplayable} \), or \(\textsf {label} .\textsf {role} = \textsf {label} '.\textsf {role} = \textsf {initiator} \) and \(\textsf {REPLAY} _{i} = \textsf {replayable} \). (Nonopposite roles of partnered sessions in nonreplayable stage.)

3.
There exist two distinct labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \) for some stage \(i \in \{1,\dots ,\textsf {M} \}\), but \(\textsf {label} .\textsf {auth} _{i} \ne \textsf {label} '.\textsf {auth} _{i}\). (Different authentication types in some stage of partnered sessions.) (Observe that \(\textsf {Match} \) security ensures agreement on the intended authentication levels (including potential upgrades); the rectified authentication level in contrast is a technical element of the security model capturing the actual level achieved in light of early corruptions when evaluating \(\textsf {Test} \) queries.)

4.
There exist two distinct labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \) for some stage \(i \in \{1,\dots ,\textsf {M} \}\), but \(\textsf {label} .\textsf {cid} _{i} \ne \textsf {label} '.\textsf {cid} _{i}\) or \(\textsf {label} .\textsf {cid} _{i} = \textsf {label} '.\textsf {cid} _{i} = \bot \). (Different or unset contributive identifiers in some stage of partnered sessions.)

5.
There exist two distinct labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} \ne \bot \) and \(\textsf {label} .\textsf {sid} _{j} = \textsf {label} '.\textsf {sid} _{j} \ne \bot \) for stages \(i,j \in \{1,\dots ,\textsf {M} \}\) where \(j \le i\), with \(\textsf {label} .\textsf {role} = \textsf {initiator} \) and \(\textsf {label} '.\textsf {role} = \textsf {responder} \) such that

\(\textsf {label} .\textsf {auth} _{j,1} \le i\) (unilateral authentication), but \(\textsf {label} .\textsf {pid} \ne \textsf {label} '.\textsf {id} \), or

\(\textsf {label} .\textsf {auth} _{j,2} \le i\) (mutual authentication), but \(\textsf {label} .\textsf {id} \ne \textsf {label} '.\textsf {pid} \) or (only for sMSKE) \(\textsf {label} .\textsf {pssid} \ne \textsf {label} '.\textsf {pssid} \).
(Different intended authenticated partner or (only sMSKE) different key identifiers in mutual authentication.)


6.
There exist two (not necessarily distinct) labels \(\textsf {label} \), \(\textsf {label} '\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{j} \ne \bot \) for some stages \(i, j \in \{1,\dots ,\textsf {M} \}\) with \(i \ne j\). (Different stages share the same session identifier.)

7.
There exist three pairwise distinct labels \(\textsf {label} \), \(\textsf {label} '\), \(\textsf {label} ''\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i} = \textsf {label} ''.\textsf {sid} _{i} \ne \bot \) for some stage \(i \in \{1,\dots ,\textsf {M} \}\) with \(\textsf {REPLAY} _{i} = \textsf {nonreplayable} \). (More than two sessions share the same session identifier in a nonreplayable stage.)
We say \(\textsf {KE} \) is \(\textsf {Match} \)secure if for all PPT adversaries \(\mathcal {A}\) the following advantage function is negligible in the security parameter:
4.3.2 MultiStage Security
The second and core notion, \(\textsf {Multi} \text {}\textsf {Stage} \) security, captures Bellare–Rogawaylike key secrecy in the multistage setting as follows.
Definition 4.2
(\(\textsf {Multi} \text {}\textsf {Stage} \) security) Let \(\textsf {KE} \) be a multistage key exchange protocol with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) and key distribution \(\mathcal {D}\), and \(\mathcal {A}\) a PPT adversary interacting with \(\textsf {KE} \) via the queries defined in Sect. 4.2 in the following game \(G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Multi} \text {}\textsf {Stage} ,\mathcal {D}}\):
 Setup.:

The challenger chooses the test bit at random and sets \(\textsf {lost} \leftarrow \textsf {false} \). In the publickey variant (pMSKE), it furthermore generates longterm public/privatekey pairs for each participant \(U \in \mathcal {U}\).
 Query.:

The adversary \(\mathcal {A}\) receives the generated public keys (pMSKE) and has access to the queries \(\textsf {NewSecret} \), \(\textsf {NewSession} \), \(\textsf {Send} \), \(\textsf {Reveal} \), \(\textsf {Corrupt} \), and \(\textsf {Test} \). Recall that such queries may set \(\textsf {lost} \) to \(\textsf {true} \).
 Guess.:

At some point, \(\mathcal {A}\) stops and outputs a guess b.
 Finalize.:

The challenger sets the ‘lost’ flag to \(\textsf {lost} \leftarrow \textsf {true} \) if there exist two (not necessarily distinct) labels \(\textsf {label} \), \(\textsf {label} '\) and some stage \(i \in \{1, \dots , \textsf {M} \}\) such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\), \(\textsf {label} .\textsf {st} _{\textsf {key} ,i} = \textsf {revealed} \), and \(\textsf {label} '.\textsf {tested} _{i} = \textsf {true} \). (Adversary has tested and revealed the key of some stage in a single session or in two partnered sessions.)
We say that \(\mathcal {A}\) wins the game, denoted by \(G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Multi} \text {}\textsf {Stage} ,\mathcal {D}} = 1\), if \(b = b_{\textsf {test} }\) and \(\textsf {lost} = \textsf {false} \). Note that the winning condition is independent of forward secrecy and authentication properties of \(\textsf {KE} \), as those are directly integrated in the affected (\(\textsf {Reveal} \) and \(\textsf {Corrupt} \)) queries and the finalization step of the game; for example, \(\textsf {Corrupt} \) is defined differently for nonforwardsecrecy versus stagej forward secrecy.
We say \(\textsf {KE} \) is \(\textsf {Multi} \text {}\textsf {Stage} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) if \(\textsf {KE} \) is \(\textsf {Match} \)secure and for all PPT adversaries \(\mathcal {A}\) the following advantage function is negligible in the security parameter:
5 Security Analysis of the TLS 1.3 Full 1RTT Handshake
We now come to analyzing the TLS 1.3 full 1RTT handshake in the publickey multistage key exchange (pMSKE) model.
Protocol Properties The full handshake targets the following protocolspecific properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\):

\(\textsf {M} = 6\): The full 1RTT handshake consists of six stages deriving, in order: the client and server handshake traffic keys \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\), the client and server application traffic secrets \(\mathrm {CATS}\) and \(\mathrm {SATS}\), the exporter master secret \(\mathrm {EMS}\), and the resumption master secret \(\mathrm {RMS}\). As shown in Fig. 1, we consider all stages’ keys being derived on either side as soon as the relevant main secret (\(\mathrm {ES}\), \(\mathrm {HS}\), \(\mathrm {MS}\)) becomes available, despite client/server keys derived in parallel might become active with some delay based on the flow direction.

\(\textsf {AUTH} = \big \{ ((3,m), (3,m), (3,m), (4,m), (5,m), (6,m)) \mid m \in \{6, \infty \} \big \}\): The handshake traffic keys \(\mathrm {tk}_{\text {chs}}\)/\(\mathrm {tk}_{\text {shs}}\) are initially unauthenticated and all keys are unilaterally authenticated after stage 3 is reached. With (optional) client authentication, all keys furthermore become mutually authenticated with stage \(m=6\); otherwise they never reach this level, \(m=\infty \).

\(\textsf {FS} = 1\): The full 1RTT handshake ensures forward secrecy for all keys derived.

\(\textsf {USE} = (\textsf {internal} : \{1,2\}, \textsf {external} : \{3,4,5,6\})\): The handshake traffic keys are used internally to encrypt the second part of the handshake; all other keys are external.

\(\textsf {REPLAY} = (\textsf {nonreplayable} : \{1,2,3,4,5,6\})\): The keys of all stages are nonreplayable in the full 1RTT handshake.
Session and Contributive Identifiers As part of the analysis in the pMSKE model, we need to define how session and contributive identifiers are set for each stage during execution of the TLS 1.3 full 1RTT handshake.
Session identifiers are set upon acceptance of each stage and include a label and all handshake messages up to this point (entering the key derivation):
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 \(\texttt {ClientHello} \) and \(\texttt {ClientKeyShare} \) messages set \(\textsf {cid} _{1} = (\text {``CHTS''},\texttt {CH} ,\texttt {CKS} )\), \(\textsf {cid} _{2} = (\text {``SHTS''},\texttt {CH} ,\texttt {CKS} )\) and later, upon receiving (resp. sending) the \(\texttt {ServerHello} \) and \(\texttt {ServerKeyShare} \) messages, extend it to \(\textsf {cid} _{1} =\) \((\text {``CHTS''},\texttt {CH} ,\texttt {CKS} ,\texttt {SH} ,\texttt {SKS} )\), \(\textsf {cid} _{2} = (\text {``SHTS''},\texttt {CH} ,\texttt {CKS} ,\texttt {SH} ,\texttt {SKS} )\). All other contributive identifiers are set to \(\textsf {cid} _{i} = \textsf {sid} _{i}\) (for stages \(i \in \{3,4,5,6\}\)) when the respective session identifier is set.
5.1 Match Security
We are now ready to give our formal security results for the TLS 1.3 full 1RTT handshake, beginning with \(\textsf {Match} \) security.
Theorem 5.1
(\(\textsf {Match} \) security of TLS1.3 full 1RTT). The TLS 1.3 full 1RTT handshake is \(\textsf {Match} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. For any efficient adversary \(\mathcal {A}\), we have
where \(n_{s}\) is the maximum number of sessions, q is the group order, and \(\text {nonce}=256\) is the bit length of the nonces.
Recall that \(\textsf {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.3full1RTT, 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 \(\textsf {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 \(\texttt {CKS} \) and \(\texttt {SKS} \) messages, fixing the only key input \(\mathrm {DHE}= g^{xy}\) to all derived stage keys (recall that \(\mathrm {PSK}= 0\) in the TLS 1.3 full 1RTT 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 \(\texttt {SKS} \), for stages 3–5 messages up to \(\texttt {SF} \), and for stage 6 all messages (up to \(\texttt {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.

2.
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 wrongrole incoming messages, and the initial \(\texttt {Hello} \) messages are typed with the sender’s role. There are no replayable stages in the TLS 1.3 full 1RTT 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 \(\textsf {unauth} \) and \(\textsf {unilateral} \) (from stage 3 on), respectively, hence agreed upon by all sessions. For the last stage, the presence of \(\texttt {CR} \), \(\texttt {CCRT} \), and \(\texttt {CCV} \) in \(\textsf {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 \(\textsf {cid} _{i}\) being final and equal to \(\textsf {sid} _{i}\) once the session identifier is set.

5.
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 1RTT handshake, peer identities are learned through the \(\texttt {Certificate} \) messages. As we are only concerned with honest client and server sessions for \(\textsf {Match} \) security, which will only send certificates attesting their own identity, agreement on \(\texttt {SCRT} \) ensures agreeing on the server (responder) identity, and vice versa for \(\texttt {CCRT} \) and the client (initiator) identity. Such agreement is ensured through including \(\texttt {SCRT} \) in the session identifier for stage 3 for unilateral authentication, and \(\texttt {SCRT} \) and \(\texttt {CCRT} \) for mutual authentication in \(\textsf {sid} _{6}\): once two sessions reach these stages and agree on \(\textsf {sid} _{3}\), resp. \(\textsf {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 nonreplayable 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_{s}^2 \cdot 1/q \cdot 2^{\text {nonce}}\), where \(n_{s}\) is the maximum number of sessions, q is the group order, and \(\text {nonce} = 256\) the nonces’ bit length. \(\square \)
5.2 MultiStage Security
We now come to the core multistage security result for the TLS 1.3 full 1RTT handshake.
Theorem 5.2
(\(\textsf {Multi} \text {}\textsf {Stage} \) security of TLS1.3full1RTT). The TLS 1.3 full 1RTT handshake is \(\textsf {Multi} \text {}\textsf {Stage} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. Formally, for any efficient adversary \(\mathcal {A}\) against the \(\textsf {Multi} \text {}\textsf {Stage} \) security there exist efficient algorithms \(\mathcal {B}_{1}\), ..., \(\mathcal {B}_{7}\) such that
where \(n_{s}\) is the maximum number of sessions and \(n_{u}\) is the maximum number of users.
For the TLS 1.3 full 1RTT handshake, \(\textsf {Multi} \text {}\textsf {Stage} \) security essentially follows from two lines of reasoning. First, the (unforgeable) signatures covering (a collisionresistant hash of) the full \(\texttt {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 \(\textsf {PRF} \text { }\textsf {ODH} \) and \(\textsf {PRF} \) assumptions on the \(\textsf {HKDF} .\textsf {Extract} \) and \(\textsf {HKDF} .\textsf {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 \(\textsf {Multi} \text {}\textsf {Stage} \) game, we bound the advantage difference of adversary \(\mathcal {A}\) between any two games by complexitytheoretic assumptions until we reach a game where the adversary \(\mathcal {A}\) cannot win, i.e., its advantage is at most 0.
Game 0. This is the original \(\textsf {Multi} \text {}\textsf {Stage} \) game, i.e.,
Game 1. In a first step, we restrict the adversary \(\mathcal {A}\) in the \(\textsf {Multi} \text {}\textsf {Stage} \) game to make only a single \(\textsf {Test} \) query. That is we can formally turn any multiquery adversary \(\mathcal {A}\) into an adversary \(\mathcal {A}_{1}\) which makes only a single \(\textsf {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 \(\mathcal {A}_{1}\) randomly guesses one of the sessions in advance and only performs the single \(\textsf {Test} \) query for this session. The other \(\textsf {Test} \) queries of a multiquery attacker are gradually substituted by carefully crafted \(\textsf {Reveal} \) queries, where the singlequery attacker \(\mathcal {A}_{1}\) needs to know the correct partnering of sessions via session identifiers \(\textsf {sid} \) for a correct simulation, e.g., to avoid losses due to bad \(\textsf {Reveal} \)\(\textsf {Test} \) combinations on session partners due to the new \(\textsf {Reveal} \) queries. The session identifiers \(\textsf {sid} _{1}\) and \(\textsf {sid} _{2}\) only contain public information such that partnering is easy to check for them. But then handshake encryption is turned on such that \(\textsf {sid} _{3},\dots ,\textsf {sid} _{6}\) are based on encrypted data. Fortunately, if the single \(\textsf {Test} \) query concerns a (client or server) handshake traffic secret then partnering is easy to decide based on \(\textsf {sid} _{1}\) resp. \(\textsf {sid} _{2}\). If the \(\textsf {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 \(\textsf {sid} _{3},\dots ,\textsf {sid} _{6}\) as well. We provide the full details of this hybrid argument in Appendix A.
Incorporating the transformation of \(\mathcal {A}\) into \(\mathcal {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 \(\textsf {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 \(\textsf {H} \). We can break the collision resistance of \(\textsf {H} \) in case of this event by letting a reduction \(\mathcal {B}_{1}\) output the two distinct input values to \(\textsf {H} \). Thus:
From here on, our security analysis separately considers the two (disjoint) cases that

A.
the tested session \(\textsf {label} \) has no honest contributive partner in the first stage (i.e., there exists no \(\textsf {label} ' \ne \textsf {label} \) with \(\textsf {label} .\textsf {cid} _{1} = \textsf {label} '.\textsf {cid} _{1}\)), and

B.
the tested session \(\textsf {label} \) has an honest contributive partner in the first stage (i.e., there exists \(\textsf {label} '\) with \(\textsf {label} .\textsf {cid} _{1} = \textsf {label} '.\textsf {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 \(\textsf {label} \) has no stage1 contributive partner, which implies it does not have a contributive partner in any stage. By definition, an adversary cannot win if the \(\textsf {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 \(\textsf {Test} \) oracle checks against this refined property. Hence, for a tested client session, \(\textsf {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, \(\textsf {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.
Game A.1. In this game, we let the challenger guess the peer identity \(U \in \mathcal {U}\) of the tested session \(\textsf {label} \) (observe that one must be set in order for \(\textsf {Test} \) to be admissible, as discussed above), and abort if that guess was incorrect (i.e., \(\textsf {label} .\textsf {pid} \ne U\)). This can reduce \(\mathcal {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 \(\textsf {label} \) receives, within the \(\texttt {CertificateVerify} \) message from its peer \(\textsf {label} .\textsf {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 \(\texttt {ClientHello} \Vert \ldots \Vert \texttt {ClientCert} \) resp. \(\texttt {ClientHello} \Vert \ldots \Vert \texttt {ServerCert} \) (cf. Table 2). Observe that, as discussed above, when the \(\textsf {Test} \) query is issued to \(\textsf {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 \(\mathcal {B}_{2}\) against the EUFCMA security of the signature scheme \(\textsf {SIG} \). In the reduction \(\mathcal {B}_{2}\) receives a public key \(\textit{pk}_{U}\) of a signature scheme, computes the longterm keys of all parties \(U' \in \mathcal {U}\setminus \{U\}\) except U and simulates \(G_{A.1}\) for \(\mathcal {A}_{1}\). Whenever in that simulation \(\mathcal {B}_{2}\) has to compute a signature under \(\textit{sk}_{U}\), it does so via its signing oracle. When \(\textsf {label} \) receives a valid signature \(\sigma \) on the (hash value of the) message m, adversary \(\mathcal {B}_{2}\) outputs \((\textsf {H} (m),\sigma )\) 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 \((\textsf {H} (m),\sigma )\) constitutes a successful forgery. To see this note that the tested session \(\textsf {label} \) computes the hash value \(\textsf {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 \(\textsf {H} (m')=\textsf {H} (m)\) for some other message \(m'\). We conclude that the hash value \(\textsf {H} (m)\) has not been signed by user U before.
It follows for Case A that the adversary cannot make a legitimate \(\textsf {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 \(\textsf {Test} \) query to a session with an honest contributive partner in the first stage.
Game B.1. In this game, we guess a session \(\textsf {label} ' \ne \textsf {label} \) (from at most \(n_{s}\) sessions in the game) and abort the game if \(\textsf {label} .\textsf {cid} _{1} \ne \textsf {label} '.\textsf {cid} _{1}\), i.e., that \(\textsf {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 \(\mathrm {HS}\) derived in the tested session and its contributive partner session with a uniformly random and independent string . We employ the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) assumption (Definition 2.3) in order to be able to simulate the computation of \(\mathrm {HS}\) in a partnered client session for a modified \(\texttt {ServerKeyShare} \) message. More precisely, we can turn any adversary capable of distinguishing this change into an adversary \(\mathcal {B}_{3}\) against the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) security of the \(\textsf {HKDF} .\textsf {Extract} \) function (taking \(\mathrm {dES}\) as first and \(\mathrm {DHE}\) as second input). For this \(\mathcal {B}_{3}\) asks for a \(\textsf {PRF} \) challenge on \(\mathrm {dES}\) computed in the test session and its honest contributive partner. It uses the obtained Diffie–Hellman shares \(g^x\), \(g^y\) within \(\texttt {ClientKeyShare} \) and \(\texttt {ServerKeyShare} \) of the tested and contributive sessions, and the \(\textsf {PRF} \) challenge value as \(\mathrm {HS}\) in the tested session. If necessary, \(\mathcal {B}_{3}\) uses its \(\textsf {PRF} \text { }\textsf {ODH} \) queries to derive \(\mathrm {HS}\) in the partnered session on differing \(g^{y'} \ne g^y\). Providing a sound simulation of either \(G_{B.1}\) (if the bit sampled by the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) challenger was 0 and thus \(\widetilde{\mathrm {HS}} = \textsf {HKDF} .\textsf {Extract} (\mathrm {dES},g^{xy})\)), or \(G_{B.2}\) (if the bit sampled by the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) challenger was 1 and thus ), this bounds the advantage difference of \(\mathcal {A}\) as:
Game B.3. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {HS}}\) replaced in \(G_{B.2}\). This affects the derivation of the client handshake traffic secret \(\mathrm {CHTS}\), the server handshake traffic secret \(\mathrm {SHTS}\) and the derived handshake secret \(\mathrm {dHS}\) in the target session and its matching partner, and the derived handshake secret \(\mathrm {dHS}\) in all sessions using the same handshake secret \(\widetilde{\mathrm {HS}}\). Note that for \(\mathrm {CHTS}\) and \(\mathrm {SHTS}\), these values are distinct from any other session using the same handshake secret value \(\widetilde{\mathrm {HS}}\), as the evaluation also takes as input the hash value \(H_{2} = \textsf {H} (\texttt {CH} \Vert \texttt {SH} )\), (where \(\texttt {CH} \) and \(\texttt {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 \(\mathrm {CHTS}\), \(\mathrm {SHTS}\) and \(\mathrm {dHS}\) in such sessions with random values . To ensure consistency, we replace derivations of \(\mathrm {dHS}\) with the replaced \(\widetilde{\mathrm {dHS}}\) sampled by the first session to evaluate \(\textsf {HKDF} .\textsf {Expand} \) using \(\widetilde{\mathrm {HS}}\). We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game, \(\widetilde{\mathrm {HS}}\) is a uniformly random value, and the replacement is sound. Thus:
At this point, \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are independent of any values computed in any session nonpartnered (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 \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are unique.
Game B.4. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the values \(\widetilde{\mathrm {CHTS}}\), \(\widetilde{\mathrm {SHTS}}\) replaced in \(G_{B.3}\). This affects the derivation of the client handshake traffic key \(\mathrm {tk}_{\text {chs}}\), and the server handshake traffic key \(\mathrm {tk}_{\text {shs}}\) in the target session and its contributive partner. We replace the derivation of \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\) with random values and , 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 \(\mathcal {A}\) by the security of two evaluations of the pseudorandom functions \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are uniformly random values, and these replacements are sound. Thus:
Game B.5. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations of the value \(\widetilde{\mathrm {dHS}}\) replaced in \(G_{B.3}\). This affects the derivation of the master secret \(\mathrm {MS}\) in any session using the same derived handshake secret \(\widetilde{\mathrm {dHS}}\). We replace the derivation of \(\mathrm {MS}\) in such sessions with the random value . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that by \(G_{B.3}\), \(\widetilde{\mathrm {dHS}}\) is a uniformly random value and this replacement is sound. Thus:
Game B.6. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations of the value \(\widetilde{\mathrm {MS}}\) replaced in \(G_{B.5}\) in the targeted session and its matching session. This affects the derivation of the client application traffic secret \(\mathrm {CATS}\), the server application traffic secret \(\mathrm {SATS}\), the exporter master secret \(\mathrm {EMS}\), and the resumption master secret \(\mathrm {RMS}\). For \(\mathrm {CATS}\), \(\mathrm {SATS}\), and \(\mathrm {EMS}\), these evaluations are distinct from any session nonpartnered with the tested session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{4} = \textsf {H} (\texttt {CH} \Vert \ldots \Vert \texttt {SF} )\) (where \(\texttt {CH} \) and \(\texttt {SH} \) contain the client and server random values \(r_{c}\) and \(r_{s}\) respectively), and by Game \(G_{2}\) we exclude hash collisions. For \(\mathrm {RMS}\), this evaluation is distinct from any session nonpartnered with the tested session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{5} = \textsf {H} (\texttt {CH} \Vert \ldots \Vert \texttt {CF} )\). We replace the derivation of \(\mathrm {CATS},\) \(\mathrm {SATS}\), \(\mathrm {EMS}\), and \(\mathrm {RMS}\) with random values \(\widetilde{\mathrm {CATS}}\), \(\widetilde{\mathrm {SATS}}\), \(\widetilde{\mathrm {EMS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the secret of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {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 in the tested session with uniformly random values which, in the protocol execution, are independent of values in any nonpartnered session to the tested session. Thus:
Combining the given single bounds yields the security statement below:
\(\square \)
6 Security Analysis of the TLS 1.3 PSK/PSK(EC)DHE (with Optional 0RTT) Handshakes
We now turn to analyzing the TLS 1.3 preshared key handshakes, with and without Diffie–Hellman key exchange (PSK(EC)DHE, resp. PSK) and with optional 0RTT keys, in the preshared–secret multistage key exchange (sMSKE) model.
Protocol Properties The PSK/PSK(EC)DHE (0RTT) handshakes targets the following protocolspecific properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\):

\(\textsf {M} = 8\): The PSK handshakes with optional 0RTT consist of eight stages deriving, in order: the early traffic secret \(\mathrm {ETS}\) and early exporter master secret \(\mathrm {EEMS}\) (both only in 0RTT mode), the client and server handshake traffic keys \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\), the client and server application traffic secrets \(\mathrm {CATS}\) and \(\mathrm {SATS}\), the exporter master secret \(\mathrm {EMS}\), and the resumption master secret \(\mathrm {RMS}\).

The authentication properties \(\textsf {AUTH} \) differ between the PSK(only) and the PSK(EC)DHE (0RTT) handshakes:

– for PSK (0RTT), \(\textsf {AUTH} = \big \{((1,1), (2,2), \ldots , (8,8))\big \}\): All keys are immediately mutually authenticated (from the preshared key).

– for PSK(EC)DHE (0RTT), \(\textsf {AUTH} = \big \{ ((1,1),(2,2),(5,8),(5,8),(5,8),(6,8),(7,8),(8,8)) \big \}\): The 0RTT keys \(\mathrm {ETS}\)/\(\mathrm {EEMS}\) are always mutually authenticated, the handshake traffic keys \(\mathrm {tk}_{\text {chs}}\)/\(\mathrm {tk}_{\text {shs}}\) are initially unauthenticated, all non0RTT 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 PSKonly handshake. Consider the handshake traffic keys in the PSK(EC)DHE handshake: in the model, the adversary \(\mathcal {A}\) could send its own \(g^x\) share to a server session; the server will derive the handshake traffic keys from \(\mathrm {PSK}\) and \(\mathrm {DHE}\). Those keys should now be considered forward secret (due to the ephemeral DH shares); however, when \(\mathcal {A}\) corrupts \(\mathrm {PSK}\), it can compute the handshake traffic keys. Hence, these keys cannot be treated as forward secret and mutually authenticated at the same time.


Forward secrecy of the PSK handshake depends on whether an ephemeral Diffie–Hellman key exchange is performed:

– for PSKonly, \(\textsf {FS} = \infty \): The PSKonly handshake does not provide any forward secrecy.

– for PSK(EC)DHE, \(\textsf {FS} = 3\): The PSK(EC)DHE handshake provides forward secrecy for all non–0RTT keys.


\(\textsf {USE} = (\textsf {internal} : \{3,4\}, \textsf {external} : \{1,2,5,6,7,8\})\): The handshake traffic keys are used internally to encrypt the second part of the handshake; all other keys are external.

\(\textsf {REPLAY} = (\textsf {replayable} : \{1,2\}, \textsf {nonreplayable} : \{3,4,5,6,7,8\})\): The 0RTT keys \(\mathrm {ETS}\) and \(\mathrm {EEMS}\) are replayable, all other stages’ keys are not.
Session and Contributive Identifiers As for the full 1RTT 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:
Components indicated with \(^\dagger \) are present only in the PSK(EC)DHE variant.
For the contributive identifiers in stages 3 and 4, as for the full handshake we want to ensure server sessions with honest client contribution can be tested, even if the server’s response never reaches the client. Therefore, we let client (resp. server) upon sending (resp. receiving) the \(\texttt {ClientHello} \), \(\texttt {ClientKeyShare} ^\dagger \) and \(\texttt {ClientPreSharedKey} \) messages set \(\textsf {cid} _{3} = (\text {``CHTS''},\texttt {CH} ,\texttt {CKS} ^\dagger , \texttt {CPSK} )\), \(\textsf {cid} _{4} = (\text {``SHTS''},\texttt {CH} ,\texttt {CKS} ^\dagger , \texttt {CPSK} )\) and later, upon receiving (resp. sending) the \(\texttt {ServerHello} \), \(\texttt {ServerKeyShare} ^\dagger \) and \(\texttt {ServerPreSharedKey} \) messages, extend it to \(\textsf {cid} _{3} = (\text {``CHTS''},\texttt {CH} ,\texttt {CKS} ^\dagger ,\texttt {CPSK} ,\texttt {SH} ,\texttt {SKS} ^\dagger ,\texttt {SPSK} )\), \(\textsf {cid} _{4} = (\text {``SHTS''},\texttt {CH} ,\texttt {CKS} ^\dagger ,\texttt {CPSK} ,\texttt {SH} ,\texttt {SKS} ^\dagger ,\texttt {SPSK} )\). All other contributive identifiers are set to \(\textsf {cid} _{i} = \textsf {sid} _{i}\) (for stages \(i \in \{1,2,5,6,7,8\}\)) when the respective session identifier is set.
6.1 TLS 1.3 PSKonly (0RTT optional)
We can begin to give our security results for the TLS 1.3 PSKonly \(\text {0RTT} \) handshake. We start with \(\textsf {Match} \) security.
6.1.1 Match Security
Theorem 6.1
(\(\textsf {Match} \) security of TLS1.3PSK0RTT). The TLS 1.3 PSKonly 0RTT handshake is \(\textsf {Match} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. For any efficient adversary \(\mathcal {A}\), there exists an efficient algorithm \(\mathcal {B}\) such that
where \(n_{s}\) is the maximum number of sessions, \(n_{p}\) is the maximum number of preshared secrets, \(\mathcal {P}\) is the size of the preshared secret space, and \(\textit{nonce}=256\) is the bit length of the nonces.
Recall that \(\textsf {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 \(\textsf {Match} \) security for TLS1.3full1RTT, 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 \(\textsf {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 preshared identifier \(\textsf {pssid} = pskid\) (through the \(\texttt {CPSK} \) and \(\texttt {SPSK} \) messages, fixing the only key input \(\mathrm {PSK}\) (as both parties agree upon a mapping \(\textsf {pss} _{U,V}(\textsf {pssid} ) = \textsf {pss} = \mathrm {PSK}\) to all derived stage keys (recall that \(\mathrm {DHE}= 0\) in the TLS 1.3 PSKonly 0RTT 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 \(\texttt {CPSK} \) for stages 3 and 4 messages up to \(\texttt {SPSK} \), for stages 5, 6, 7 messages up to \(\texttt {SF} \), and for stage 8 all messages (up to \(\texttt {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.

2.
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 wrongrole incoming messages, and the initial \(\texttt {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 PSKonly 0RTT 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 PSKonly 0RTT 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 \(\textsf {cid} _{i}\) being final and equal to \(\textsf {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 \(\textsf {pssid} \) and binder values sent as part of the \(\texttt {ClientHello} \). The \(\textsf {pssid} \) thus is trivially agreed upon. The binder value is derived from that \(\mathrm {PSK}\) through a sequence of \(\textsf {HKDF} \)/\(\textsf {HMAC} \) computations. If we treat \(\textsf {HMAC} \) as an unkeyed collisionresistant hash function over both inputs, the key and the message space, agreement on binder implies agreement on \(\mathrm {PSK}\). This step is necessary, as \(\mathcal {A}\) can set multiple \(\mathrm {PSK}\) values to share the same \(\textsf {pssid} \), and thus a \(\textsf {pssid} \) does not necessarily uniquely determine a preshared secret \(\mathrm {PSK}\) from each peer’s perspective. Instead, we use binder to uniquely determine agreement upon \(\mathrm {PSK}\) between peers. As all \(\mathrm {PSK}\) values are chosen uniformly at random within the \(\textsf {NewSecret} \) query, they collide only with negligible probability, bounded by the birthday bound \(n_{p}^2 / \mathcal {P}\), where \(\mathcal {P}\) is the preshared secret space and \(n_{p}\) the maximum number of preshared secrets. Therefore, agreement on binder and \(\mathrm {PSK}\) finally implies that \(\textsf {pssid} \), as interpreted by the partnered client and server session, originates from the same \(\textsf {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 nonreplayable stage.
Recall that stages 1 and 2 are replayable, so we only need to consider stages \(i \in \{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 \(\texttt {ClientHello} \) and \(\texttt {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_{s}^2 \cdot 2^{\textit{nonce}}\), where \(n_{s}\) is the maximum number of sessions, and \(\textit{nonce} = 256\) the nonces’ bit length. \(\square \)
6.1.2 MultiStage Security
Theorem 6.2
(\(\textsf {Multi} \text {}\textsf {Stage} \) security of TLS1.3PSK0RTT). The TLS 1.3 PSK 0RTT handshake is \(\textsf {Multi} \text {}\textsf {Stage} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. Formally, for any efficient adversary \(\mathcal {A}\) against the \(\textsf {Multi} \text {}\textsf {Stage} \) security there exist efficient algorithms \(\mathcal {B}_{1}\), ..., \(\mathcal {B}_{8}\) such that
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 preshared secrets.
For the TLS 1.3 PSK 0RTT handshake, \(\textsf {Multi} \text {}\textsf {Stage} \) security follows from the security of the preshared key: all keys are derived from a preshared secret \(\mathrm {PSK}\) unknown to the adversary (since the PSK mode is not forward secret, \(\mathrm {PSK}\) may not be corrupted in the tested session) As such, derived keys are indistinguishable from random (under PRF assumptions on the \(\textsf {HKDF} .\textsf {Extract} \) and \(\textsf {HKDF} .\textsf {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 \(\mathcal {A}\)’s advantage in winning the final game is 0.
Game 0. This is the original \(\textsf {Multi} \text {}\textsf {Stage} \) game, i.e.,
Game 1. We restrict \(\mathcal {A}\) to a single \(\textsf {Test} \) query, reducing its advantage by a factor of at most \(1/8n_{s}\). Formally, we construct an adversary from \(\mathcal {A}\) making only a single \(\textsf {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 \(\textsf {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 \(\textsf {H} \). If this event occurs, this can be used to break the collision resistance of \(\textsf {H} \) by letting a reduction \(\mathcal {B}_{1}\) (with approximately the same running time as \(\mathcal {A}\)) output the two distinct input values to \(\textsf {H} \). Thus:
Game 3. In this game, the challenger guesses the preshared secret \(\mathrm {PSK}\) used in the tested session, and aborts the game if that guess was incorrect. This reduces \(\mathcal {A}\)’s advantage by a factor of at most \(1/n_{p}\) for \(n_{p}\) being the maximum number of registered preshared secrets, thus:
Game 4. In this game, we replace the outputs of the pseudorandom function \(\textsf {HKDF} .\) \(\textsf {Extract} \) in all evaluations using the tested session’s guessed preshared secret \(\mathrm {PSK}\) as a key by random values. This affects the derivation of the early secret \(\mathrm {ES}\) in any session using the same shared \(\mathrm {PSK}\). We replace the derivation of \(\mathrm {ES}\) in such sessions with a random value . We can bound the difference this step introduces in the advantage of \(\mathcal {A}\) by the dual PRF security of \(\textsf {HKDF} .\textsf {Extract} \). Note that any successful adversary cannot issue a \(\textsf {Corrupt} \) query to reveal the \(\mathrm {PSK}\) used in the tested session, and thus the preshared secret is an unknown and uniformly random value, and the simulation is sound. Thus:
Game 5. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {ES}}\) replaced in \(G_{4}\). This affects the derivation of the derived early secret \(\mathrm {dES}\), the binder key \(\mathrm {BK}\), the early traffic secret \(\mathrm {ETS}\), and the early exporter master secret \(\mathrm {EEMS}\) in any session using the same early secret value \(\widetilde{\mathrm {ES}}\) due to the stage being replayable. We replace the derivation of \(\mathrm {dES}\), \(\mathrm {BK}\), \(\mathrm {ETS}\) and \(\mathrm {EEMS}\) in such sessions with random values \(\widetilde{\mathrm {dES}}\), \(\widetilde{\mathrm {BK}}\), \(\widetilde{\mathrm {ETS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by Game \(G_{4}\), \(\widetilde{\mathrm {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 (\(\widetilde{\mathrm {ETS}}\) and \(\widetilde{\mathrm {EEMS}}\), respectively). We note that if \(\mathcal {A}\) issues a \(\textsf {Reveal} (\textsf {label} ,i)\) query to a session \(\textsf {label} '\) such that the tested session \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\), then \(\mathcal {A}\) would lose the game. Since these stages are replayable, there may be multiple such sessions such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\), however if any of these stages is revealed, \(\mathcal {A}\) loses the game.
Game 6. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations using the value \(\widetilde{\mathrm {dES}}\) replaced in \(G_{5}\). This affects the derivation of the handshake secret \(\mathrm {HS}\) in any session using the same derived early secret value \(\widetilde{\mathrm {dES}}\), as the derivation of \(\mathrm {HS}\) includes no additional entropy. We replace the derivation of \(\mathrm {HS}\) in such sessions with a random value . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that by the previous game, \(\widetilde{\mathrm {dES}}\) is a uniformly random value, and the simulation is sound. Thus:
Game 7. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {HS}}\) replaced in \(G_{6}\). This affects the derivation of the client handshake traffic secret \(\mathrm {CHTS}\), the server handshake traffic secret \(\mathrm {SHTS}\) in the target session and (if it exists) its matching partner, and the derived handshake secret \(\mathrm {dHS}\) in all sessions using the same handshake secret \(\widetilde{\mathrm {HS}}\). Note that for \(\mathrm {CHTS}\) and \(\mathrm {SHTS}\), these values are distinct from any other session using the same handshake secret value \(\widetilde{\mathrm {HS}}\), as the evaluation also takes as input the hash value \(H_{2} = \textsf {H} (\texttt {CH} \Vert \texttt {CPSK} \Vert \texttt {SH} \Vert \texttt {SPSK} )\), where \(\texttt {CH} \) and \(\texttt {SH} \) contain the client and server random values \(r_{c}\), \(r_{s}\) respectively, and by Game \(G_{2}\) we exclude hash collisions. However, \(\mathrm {dHS}\) may be derived in multiple sessions, as it includes no additional entropy in its computation. We replace the derivation of \(\mathrm {CHTS}\), \(\mathrm {SHTS}\) and \(\mathrm {dHS}\) in such sessions with random values . To ensure consistency, we replace derivations of \(\mathrm {dHS}\) with the replaced \(\widetilde{\mathrm {dHS}}\) sampled by the first session to evaluate \(\textsf {HKDF} .\textsf {Expand} \) using \(\widetilde{\mathrm {HS}}\). We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game, \(\widetilde{\mathrm {HS}}\) is a uniformly random value, and the replacement is sound. Thus:
Game 8. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the values \(\widetilde{\mathrm {CHTS}}\), \(\widetilde{\mathrm {SHTS}}\) replaced in \(G_{7}\). This affects the derivation of the client handshake traffic key \(\mathrm {tk}_{\text {chs}}\), and the server handshake traffic key \(\mathrm {tk}_{\text {shs}}\) in the target session and its matching partner. We replace the derivation of \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\) with random values and , 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 \(\mathcal {A}\) by the security of two evaluations of the pseudorandom functions \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are uniformly random values, and these replacements are sound. Thus:
Game 9. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations of the value \(\widetilde{\mathrm {dHS}}\) replaced in \(G_{8}\). This affects the derivation of the master secret \(\mathrm {MS}\) in any session using the same derived handshake secret \(\mathrm {dHS}\). We replace the derivation of \(\mathrm {MS}\) in such sessions with the random value . \(\mathrm {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 \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that by Game \(G_{7}\), \(\mathrm {dHS}\) is a uniformly random value and this replacement is sound. Thus:
Game 10. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations of the value \(\widetilde{\mathrm {MS}}\) replaced in \(G_{9}\) in the targeted session and its matching session. This affects the derivation of the client application traffic secret \(\mathrm {CATS}\), the server application traffic secret \(\mathrm {SATS}\) the exporter master secret \(\mathrm {EMS}\) and the resumption master secret \(\mathrm {RMS}\). For \(\mathrm {CATS}\), \(\mathrm {SATS}\) and \(\mathrm {EMS}\), these evaluations are distinct from any other session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{4} = \textsf {H} (\texttt {CH} \Vert \texttt {CPSK} \Vert \texttt {SH} \Vert \texttt {SPSK} \Vert \texttt {SF} )\), where \(\texttt {CH} \) and \(\texttt {SH} \) contain the client and server random values \(r_{c}\) and \(r_{s}\) respectively, and by Game \(G_{2}\) we exclude hash collisions. For \(\mathrm {RMS}\), this evaluation is distinct from any other session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{5} = \textsf {H} (\texttt {CH} \Vert \texttt {CPSK} \Vert \texttt {SH} \Vert \texttt {SPSK} \Vert \texttt {SF} \Vert \texttt {CF} )\). We replace the derivation of \(\mathrm {CATS},\mathrm {SATS}\), \(\mathrm {EMS}\) and \(\mathrm {RMS}\) with random values \(\widetilde{\mathrm {CATS}}\), \(\widetilde{\mathrm {SATS}}\), \(\widetilde{\mathrm {EMS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the secret of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {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. \(\square \)
6.2 TLS 1.3 PSK(EC)DHE (0RTT optional)
We can now turn to the security results for the TLS 1.3 PSK(EC)DHE \(\text {0RTT} \) handshake, starting again with \(\textsf {Match} \) security.
6.2.1 Match Security
Theorem 6.3
(\(\textsf {Match} \) security of TLS1.3PSK(EC)DHE0RTT). The TLS 1.3 PSK(EC)DHE 0RTT handshake is \(\textsf {Match} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. For any efficient adversary \(\mathcal {A}\), there exists an efficient algorithm \(\mathcal {B}\) such that
where \(n_{s}\) is the maximum number of sessions, q is the group order, \(n_{p}\) is the maximum number of preshared secrets, \(\mathcal {P}\) is the size of the preshared secret space, and \(\textit{nonce}=256\) is the bit length of the nonces.
As before, the soundness properties of \(\textsf {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 \(\textsf {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 both the preshared identifier pskid and the Diffie–Hellman shares \(g^x\) and \(g^y\) (through the \(\texttt {CPSK} \) and \(\texttt {SPSK} \), and \(\texttt {CKS} \), \(\texttt {SKS} \) messages respectively), fixing both the preshared key input \(\mathrm {PSK}\) and the Diffie–Hellman key input \(\mathrm {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 \(\texttt {CPSK} \), for stages 3 and 4 messages up to \(\texttt {SPSK} \), for stages 5, 6, 7 messages up to \(\texttt {SF} \), and for stage 8 all messages (up to \(\texttt {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.

2.
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 wrongrole incoming messages, and the initial \(\texttt {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 0RTT handshake.

3.
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 \(\textsf {cid} _{i}\) being final and equal to \(\textsf {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 \(\textsf {pssid} \) and binder values sent as part of the \(\texttt {ClientHello} \). The \(\textsf {pssid} \) thus is trivially agreed upon and uniquely determining a preshared secret \(\mathrm {PSK}\) from each peer’s perspective. The binder value is derived from that \(\mathrm {PSK}\) through a sequence of \(\textsf {HKDF} \)/\(\textsf {HMAC} \) computations. If we treat \(\textsf {HMAC} \) as an unkeyed collisionresistant hash function over both inputs, the key and the message space, agreement on binder implies agreement on \(\mathrm {PSK}\). This step is necessary, as \(\mathcal {A}\) can set multiple \(\mathrm {PSK}\) values to share the same \(\textsf {pssid} \), and thus a \(\textsf {pssid} \) does not necessarily uniquely determine a preshared secret \(\mathrm {PSK}\) from each peer’s perspective. Instead, we use binder to uniquely determine agreement upon \(\mathrm {PSK}\) between peers. As all \(\mathrm {PSK}\) values are chosen uniformly at random within the \(\textsf {NewSecret} \) query, they collide only with negligible probability, bounded by the birthday bound \(n_{p}^2 / \mathcal {P}\), where \(\mathcal {P}\) is the preshared secret space and \(n_{p}\) the maximum number of preshared secrets. Therefore, agreement on binder and \(\mathrm {PSK}\) finally implies that \(\textsf {pssid} \), as interpreted by the partnered client and server session, originates from the same \(\textsf {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 nonreplayable stage. Recall that stages 1 and 2 are replayable, so we consider only stages \(i \in \{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 \(\texttt {ClientHello} \) and \(\texttt {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_{s}^2 \cdot 1/q \cdot 2^{\textit{nonce}}\), where \(n_{s}\) is the maximum number of sessions, q is the group order, and \(\textit{nonce} = 256\) the nonces’ bit length. \(\square \)
6.2.2 MultiStage Security
Theorem 6.4
(\(\textsf {Multi} \text {}\textsf {Stage} \) security of TLS1.3PSK(EC)DHE0RTT). The TLS 1.3 PSK(EC)DHE 0RTT handshake is \(\textsf {Multi} \text {}\textsf {Stage} \)secure with properties \((\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )\) given above. Formally, for any efficient adversary \(\mathcal {A}\) against the \(\textsf {Multi} \text {}\textsf {Stage} \) security there exist efficient algorithms \(\mathcal {B}_{1}\), ..., \(\mathcal {B}_{16}\) such that
where \(n_{s}\) is the maximum number of sessions, \(n_{p}\) the maximum number of preshared secrets established between any two parties, and \(n_{u}\) is the maximum number of users.
For the TLS 1.3 PSK(EC)DHE 0RTT handshake, \(\textsf {Multi} \text {}\textsf {Stage} \) security essentially follows from two lines of reasoning. First, the (unforgeable) MAC tags covering (a collisionresistant hash of) the full \(\texttt {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 \(\textsf {PRF} \text { }\textsf {ODH} \) and dualPRFsec/\({\textsf {PRF} \text {}\textsf {sec} }\) assumptions on the \(\textsf {HKDF} .\textsf {Extract} \) and \(\textsf {HKDF} .\textsf {Expand} \) steps), and for nonforwardsecret stages the keys are derived from a preshared secret unknown to the adversary, and are also indistinguishable from random (under \(\textsf {PRF} \) assumptions on the \(\textsf {HKDF} .\textsf {Expand} \) and \(\textsf {HKDF} .\textsf {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 \(\textsf {Multi} \text {}\textsf {Stage} \) game and bounding the advantage (differences) of adversary \(\mathcal {A}\).
Game 0. This is the original \(\textsf {Multi} \text {}\textsf {Stage} \) game, i.e.,
Game 1. We again restrict \(\mathcal {A}\) to a single \(\textsf {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 \(\textsf {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 \(\textsf {H} \). We can break the collision resistance of \(\textsf {H} \) in case of this event by letting a reduction \(\mathcal {B}_{1}\) output the two distinct input values to \(\textsf {H} \). Thus:
From this point, our analysis separately considers the following three (disjoint) cases:

A.
that the tested session \(\textsf {label} \) has no honest contributive partner in the third stage (i.e., there exists no \(\textsf {label} ' \ne \textsf {label} \) with \(\textsf {label} .\textsf {cid} _{3} = \textsf {label} '.\textsf {cid} _{3}\)), and,

B.
the tested session \(\textsf {label} \) has an honest contributive partner in the third stage (i.e., there exists \(\textsf {label} '\) with \(\textsf {label} .\textsf {cid} _{3} = \textsf {label} '.\textsf {cid} _{3}\)) and \(\mathcal {A}\) issues a \(\textsf {Test} \) query to the nonforwardsecret stages (i.e., \(\mathcal {A}\) issues \(\textsf {Test} (\textsf {label} , i)\) where \(i \in \{1,2\}\).

C.
the tested session \(\textsf {label} \) has an honest contributive partner in the third stage (i.e., there exists \(\textsf {label} '\) with \(\textsf {label} .\textsf {cid} _{3} = \textsf {label} '.\textsf {cid} _{3}\)) and \(\mathcal {A}\) issues a \(\textsf {Test} \) query to the forwardsecret stages (i.e., \(\mathcal {A}\) issues \(\textsf {Test} (\textsf {label} , i)\) where \(i \in \{3, \ldots , 8\}\).
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 \(\textsf {label} \) has no stage 3 contributive partner. For tested initiator sessions, this means that there exists no honest session that has output the received \(\texttt {SH} \), \(\texttt {SKS} \), and \(\texttt {SPSK} \) messages. For tested responder session, this means that there exists no honest initiator session that has output the received \(\texttt {CH} \), \(\texttt {CKS} \), or \(\texttt {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 \(\textsf {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 \(\textsf {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 \(\textsf {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 preshared secret \(\mathrm {PSK}\) used in the tested session, and aborts the game if that guess was incorrect. This reduces \(\mathcal {A}\)’s advantage by a factor of at most \(1/n_{p}\) (for \(n_{p}\) the maximum number of preshared secrets), thus:
Game A.2. In this game, the challenger aborts immediately if the initiator (resp. responder) session with label \(\textsf {label} \) accepts in the fifth (resp. eighth) stage without an honest contributive partner in stage 3. Let \(\textsf {abort} ^{G_{A.2}, \mathcal {A}}_{acc}\) denote the event this occurs in \(G_{A.2}\). Thus:
Note that Case A restricts \(\mathcal {A}\) to issuing a \(\textsf {Test} \) query to a session without an honest contributive partner in stage 3. Because of the authentication type of \(\texttt {TLS1.3} \text {}\texttt {PSK} \text {}\texttt {(EC)DHE} \text {}\texttt {0RTT} \), this \(\textsf {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 \(\textsf {abort} ^{G_{A.2}, \mathcal {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 \(\mathcal {A}\) from making a \(\textsf {Corrupt} (U,V,k)\) query such that \(\textsf {label} .\textsf {id} = U\), \(\textsf {label} .\textsf {pid} = V\), \(\textsf {label} .\textsf {pssid} = k\), and show that this does not impact \(\mathcal {A}\)’s advantage in winning this case. By the definition of the case, there does not exist a session \(\textsf {label} '\) such that \(\textsf {label} '.\textsf {cid} _{3} = \textsf {label} .\textsf {cid} _{3}\) where \(\mathcal {A}\)’s \(\textsf {Test} \) query is issued to \(\textsf {label} \). Since PSK(EC)DHE mode is unilaterally authenticated in stage 5 and mutually authenticated in stage 8, if the adversary issues a \(\textsf {Corrupt} (U,V,k)\) query before the tested session \(\textsf {label} \) (without an honest contributive partner in stage 3) reaches accept in its partner’s authenticating stage, when \(\mathcal {A}\) issues a \(\textsf {Test} (\textsf {label} ,i)\) query (where \(i \in \{1,\ldots ,8\}\)) the lost flag is set and \(\mathcal {A}\) will lose the game. By the previous games, we abort when the initiator session \(\textsf {label} \) (resp. responder session) reaches stage 5 (resp. stage 8) without an honest contributive partner, and thus \(\mathcal {A}\) will never issue a \(\textsf {Corrupt} (U,V,k)\) query. In the following games, this will allow us to replace the preshared secret \(\textsf {pss} \) in the tested session (and all sessions with the same \(\textsf {pss} \) value) without being inconsistent or detectable with regard to the \(\textsf {Corrupt} \) query. In what follows, let \(\textsf {pss} _{U,V,k}\) be the guessed preshared secret.
Game A.4. In this game, we replace the outputs of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations using the tested session’s guessed preshared secret \(\textsf {pss} _{U,V,k}\) as a key by random values. This affects the derivation of the early secret \(\mathrm {ES}\) in any session using the same shared \(\mathrm {PSK}\). We replace the derivation of \(\mathrm {ES}\) in such sessions with a random value . We can bound the difference this step introduces in the advantage of \(\mathcal {A}\) by the (dual) security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that any successful adversary cannot issue a \(\textsf {Corrupt} \) query to reveal \(\textsf {pss} _{U,V,k}\) used in the tested session, and thus the preshared secret is an unknown and uniformly random value, and the simulation is sound. Thus:
Game A.5. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {ES}}\) replaced in \(G_{A.4}\). This affects the derivation of the derived early secret \(\mathrm {dES}\), the binder key \(\mathrm {BK}\), the early traffic secret \(\mathrm {ETS}\), and the early exporter master secret \(\mathrm {EEMS}\) in any session using the same early secret value \(\widetilde{\mathrm {ES}}\) due to the stage being replayable. We replace the derivation of \(\mathrm {dES}\), \(\mathrm {BK}\), \(\mathrm {ETS}\) and \(\mathrm {EEMS}\) in such sessions with random values \(\widetilde{\mathrm {dES}}\), \(\widetilde{\mathrm {BK}}\), \(\widetilde{\mathrm {ETS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by Game \(G_{A.4}\), \(\widetilde{\mathrm {ES}}\) is an unknown and uniformly random value, and this replacement is sound. Thus:
Game A.6. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations using the value \(\widetilde{\mathrm {dES}}\) replaced in \(G_{A.5}\). This affects the derivation of the handshake secret \(\mathrm {HS}\) in any session using the same derived early secret value \(\widetilde{\mathrm {dES}}\), due to the stage being replayable. We replace the derivation of \(\mathrm {HS}\) in such sessions with a random value . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that by the previous game, \(\widetilde{\mathrm {dES}}\) is a uniformly random value, and the simulation is sound. Thus:
Game A.7. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {HS}}\) replaced in \(G_{A.6}\). This affects the derivation of the client handshake traffic secret \(\mathrm {CHTS}\), the server handshake traffic secret \(\mathrm {SHTS}\) in the target session and its matching partner, and the derived handshake secret \(\mathrm {dHS}\) in all sessions using the same handshake secret \(\widetilde{\mathrm {HS}}\). Note that for \(\mathrm {CHTS}\) and \(\mathrm {SHTS}\), these values are distinct from any other session using the same handshake secret value \(\widetilde{\mathrm {HS}}\), as the evaluation also takes as input the hash value \(H_{2} = \textsf {H} (\texttt {CH} \Vert \texttt {SH} )\), (where \(\texttt {CH} \) and \(\texttt {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 \(\mathrm {CHTS}\), \(\mathrm {SHTS}\) and \(\mathrm {dHS}\) in such sessions with random values . To ensure consistency, we replace derivations of \(\mathrm {dHS}\) with the replaced \(\widetilde{\mathrm {dHS}}\) sampled by the first session to evaluate \(\textsf {HKDF} .\textsf {Expand} \) using \(\widetilde{\mathrm {HS}}\). We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game, \(\widetilde{\mathrm {HS}}\) is a uniformly random value, and the replacement is sound. Thus:
Game A.8. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the client handshake traffic secret \(\widetilde{\mathrm {CHTS}}\) replaced in \(G_{A.7}\). This affects the derivation of the client handshake traffic key \(\mathrm {tk}_{\text {chs}}\), and the client finished key \(\mathrm {fk}_{C}\) in the target session. We replace the derivation of \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {fk}_{C}\) with random values , , 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 \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {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 \(\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}\) (where the tested session has a responder role) can be used to build an adversary \(\mathcal {B}_{7}\) that breaks the existential unforgeability of the \(\textsf {HMAC} \) scheme. We let \(\mathcal {B}_{7}\) simulate \(G_{A.8}\) for \(\mathcal {A}\) as specified, but when the guessed session requires a MAC computation using \(\widetilde{\mathrm {fk}_{C}}\), \(\mathcal {B}_{7}\) instead invokes a MAC oracle to generate that value. Since \(\widetilde{\mathrm {fk}_{C}}\) is a uniformly random and independent value, this simulation is sound. When \(\mathcal {A}\) triggers \(\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}\) (for responder test sessions), the accepting session must have received a \(\texttt {ClientFinished} \) message that is a valid MAC tag over the hash value \(H_{4}=\textsf {H} (\texttt {CH} \Vert \ldots \Vert \texttt {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 \(\mathcal {A}\) triggering \(\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}\) due to a stage8 accepting responder session without a stage3 contributive partner by:
Note that for the rest of this case, we bound the probability of an adversary triggering \(\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}\) when the tested session has an initiator role.
Game A.10. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the server handshake traffic secret \(\widetilde{\mathrm {SHTS}}\) replaced in \(G_{A.9}\). This affects the derivation of the server handshake traffic key \(\mathrm {tk}_{\text {shs}}\), and the server finished key \(\mathrm {fk}_{S}\) in the target session. We replace the derivation of \(\mathrm {tk}_{\text {shs}}\) and \(\mathrm {fk}_{S}\) with random values . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by a previous game \(\widetilde{\mathrm {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 \(\textsf {abort} ^{G_{A.11}, \mathcal {A}}_{acc}\) (where the test session is an initiator session) can be used to build an adversary \(\mathcal {B}_{9}\) that breaks the existential unforgeability of the \(\textsf {HMAC} \) scheme. We let \(\mathcal {B}_{9}\) simulate \(G_{A.10}\) for \(\mathcal {A}\) as specified, but when the guessed session or its partner session requires a MAC computation using \(\widetilde{\mathrm {fk}_{S}}\), \(\mathcal {B}_{9}\) instead invokes a MAC oracle to generate that value. Since \(\widetilde{\mathrm {fk}_{S}}\) is a uniformly random and independent value, this simulation is sound. When \(\mathcal {A}\) triggers \(\textsf {abort} ^{G_{A.11}, \mathcal {A}}_{acc}\) (for initiator test sessions), the accepting session must have received a \(\texttt {ServerFinished} \) message that is a valid MAC tag over the hash value \(H_{7}=\textsf {H} (\texttt {CH} \Vert \ldots \Vert \texttt {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 \(\mathcal {A}\) triggering \(\textsf {abort} ^{G_{A.11}, \mathcal {A}}_{acc}\) due to a stage5 accepting initiator session without a stage3 contributive identifier by:
Combining the given single bounds yield the security statement below:
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 \(\mathcal {A}\) issues a \(\textsf {Test} (\textsf {label} ,i)\) query such that \(i \in \{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 preshared secret \(\mathrm {PSK}\) used in the tested session and abort on a wrong guess. This reduces \(\mathcal {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 \(\mathcal {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 \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations using the tested session’s guessed preshared secret \(\textsf {pss} _{U,V,k}\) as a key by random values. This affects the derivation of the early secret \(\mathrm {ES}\) in any session using the same shared \(\mathrm {PSK}\). We replace the derivation of \(\mathrm {ES}\) in such sessions with a random value . We can bound the difference this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that any successful adversary cannot issue a \(\textsf {Corrupt} \) query to reveal \(\textsf {pss} _{U,V,k}\) used in the tested session (as \(\mathcal {A}\) will issue a query \(\textsf {Test} (\textsf {label} , i)\) such that \(i \in \{1,2\}\) by the definition of this case, and \(\mathcal {A}\) will cause the lost flag to be set if \(\textsf {Corrupt} (U,V,k)\) is issued), and thus the preshared 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 \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {ES}}\) replaced in \(G_{B.3}\). This affects the derivation of the derived early secret \(\mathrm {dES}\), the binder key \(\mathrm {BK}\), the early traffic secret \(\mathrm {ETS}\), and the early exporter master secret \(\mathrm {EEMS}\) in any session using the same early secret value \(\widetilde{\mathrm {ES}}\) due to the stage being replayable. We replace the derivation of \(\mathrm {dES}\), \(\mathrm {BK}\), \(\mathrm {ETS}\) and \(\mathrm {EEMS}\) in such sessions with random values \(\widetilde{\mathrm {dES}}\), \(\widetilde{\mathrm {BK}}\), \(\widetilde{\mathrm {ETS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by Game \(G_{B.3}\), \(\widetilde{\mathrm {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 (\(\widetilde{\mathrm {ETS}}\) and \(\widetilde{\mathrm {EEMS}}\), respectively). We note that if \(\mathcal {A}\) issues a \(\textsf {Reveal} (\textsf {label} ,i)\) query to a session \(\textsf {label} '\) such that the tested session \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\), then \(\mathcal {A}\) would lose the game. Since these stages are replayable, then there may be multiple such sessions such that \(\textsf {label} .\textsf {sid} _{i} = \textsf {label} '.\textsf {sid} _{i}\). Since \(\widetilde{\mathrm {ETS}}\) and \(\widetilde{\mathrm {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 \(\mathcal {A}\) issues a \(\textsf {Test} (\textsf {label} ,i)\) query such that \(i \in \{3,\ldots ,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 \(\mathcal {A}\)’s advantage by a factor of at most \(1/n_{s}\) and thus:
Game C.2. In this game, we replace the handshake secret \(\mathrm {HS}\) derived in the tested session and its contributive partner session with a uniformly random and independent string . We employ the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) assumption in order to be able to simulate the computation of \(\mathrm {HS}\) in a partnered client session for a modified \(\texttt {ServerKeyShare} \) message. More precisely, we can turn any adversary capable of distinguishing this change into an adversary \(\mathcal {B}_{12}\) against the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) security of the \(\textsf {HKDF} .\textsf {Extract} \) function (taking \(\mathrm {dES}\) as first and \(\mathrm {DHE}\) as second input). For this, \(\mathcal {B}_{12}\) asks for a \(\textsf {PRF} \) challenge on \(\mathrm {dES}\). It uses the obtained DiffieHellman shares \(g^x\), \(g^y\) within \(\texttt {ClientKeyShare} \) and \(\texttt {ServerKeyShare} \) of the tested session and its contributive partner session, and the PRF challenge value as \(\mathrm {HS}\) in the test session. If necessary, \(\mathcal {B}_{12}\) uses its \(\textsf {PRF} \text { }\textsf {ODH} \) queries to derive \(\mathrm {HS}\) in the partnered session on differing \(g^{y'} \ne g^y\). Providing a sound simulation of either \(G_{C.1}\) (if the bit sampled by the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) challenger was 0 and thus \(\widetilde{\mathrm {HS}} = \textsf {PRF} (\mathrm {dES},g^{xy})\)) or \(G_{C.2}\) (if the bit sampled by the \(\textsf {dual} \text { }\textsf {snPRF} \text { }\textsf {ODH} \) challenger was 1 and thus ), this bounds the advantage difference of \(\mathcal {A}\) as:
Game C.3. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the value \(\widetilde{\mathrm {HS}}\) replaced in \(G_{C.2}\). This affects the derivation of the client handshake traffic secret \(\mathrm {CHTS}\), the server handshake traffic secret \(\mathrm {SHTS}\) in the target session and its matching partner, and the derived handshake secret \(\mathrm {dHS}\) in all sessions using the same handshake secret \(\widetilde{\mathrm {HS}}\). Note that for \(\mathrm {CHTS}\) and \(\mathrm {SHTS}\), these values are distinct from any other session using the same handshake secret value \(\widetilde{\mathrm {HS}}\), as the evaluation also takes as input the hash value \(H_{2} = \textsf {H} (\texttt {CH} \Vert \texttt {SH} )\), (where \(\texttt {CH} \) and \(\texttt {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 \(\mathrm {CHTS}\), \(\mathrm {SHTS}\) and \(\mathrm {dHS}\) in such sessions with random values . To ensure consistency, we replace derivations of \(\mathrm {dHS}\) with the replaced \(\widetilde{\mathrm {dHS}}\) sampled by the first session to evaluate \(\textsf {HKDF} .\textsf {Expand} \) using \(\widetilde{\mathrm {HS}}\). We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game, \(\widetilde{\mathrm {HS}}\) is a uniformly random value, and the replacement is sound. Thus:
At this point, \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are independent of any values computed in any session nonpartnered (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 \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are unique.
Game C.4. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations using the values \(\widetilde{\mathrm {CHTS}}\), \(\widetilde{\mathrm {SHTS}}\) replaced in \(G_{C.3}\). This affects the derivation of the client handshake traffic key \(\mathrm {tk}_{\text {chs}}\), and the server handshake traffic key \(\mathrm {tk}_{\text {shs}}\) in the target session and its matching partner. In the derivation, we replace \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\) with random values and , 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 \(\mathcal {A}\) by the security of two evaluations of the pseudorandom functions \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {CHTS}}\) and \(\widetilde{\mathrm {SHTS}}\) are uniformly random values, and these replacements are sound. Thus:
Game C.5. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \) in all evaluations of the value \(\widetilde{\mathrm {dHS}}\) replaced in Game \(G_{C.4}\). This affects the derivation of the master secret \(\mathrm {MS}\) in any session using the same derived handshake secret \(\mathrm {dHS}\). We replace the derivation of \(\mathrm {MS}\) in such sessions with the random value . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the security of the pseudorandom function \(\textsf {HKDF} .\textsf {Extract} \). Note that by Game \(G_{C.3}\), \(\widetilde{\mathrm {dHS}}\) is a uniformly random value and this replacement is sound. Thus:
Game C.6. In this game, we replace the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \) in all evaluations of the value \(\widetilde{\mathrm {MS}}\) replaced in \(G_{C.5}\) in the targeted session and its matching session. This affects the derivation of the client application traffic secret \(\mathrm {CATS}\), the server application traffic secret \(\mathrm {SATS}\) the exporter master secret \(\mathrm {EMS}\) and the resumption master secret \(\mathrm {RMS}\). For \(\mathrm {CATS}\), \(\mathrm {SATS}\) and \(\mathrm {EMS}\), these evaluations are distinct from any other session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{4} = \textsf {H} (\texttt {CH} \Vert \texttt {SH} \Vert \texttt {SF} )\) (where \(\texttt {CH} \) and \(\texttt {SH} \) contain the client and server random values \(r_{c}\) and \(r_{s}\) respectively), and by Game \(G_{2}\) we exclude hash collisions. For \(\mathrm {RMS}\), this evaluation is distinct from any other session, as the evaluation of \(\textsf {HKDF} .\textsf {Expand} \) also takes as input \(H_{5} = \textsf {H} (\texttt {CH} \Vert \texttt {SH} \Vert \texttt {SF} \Vert \texttt {CF} )\). We replace the derivation of \(\mathrm {CATS}\), \(\mathrm {SATS}\), \(\mathrm {EMS}\), and \(\mathrm {RMS}\) with random values \(\widetilde{\mathrm {CATS}}\), \(\widetilde{\mathrm {SATS}}\), \(\widetilde{\mathrm {EMS}}\), . We can bound the difference that this step introduces in the advantage of \(\mathcal {A}\) by the secret of the pseudorandom function \(\textsf {HKDF} .\textsf {Expand} \). Note that by the previous game \(\widetilde{\mathrm {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 38) in the tested session with uniformly random values independent of the protocol execution and thus
Combining the given single bounds yields the security statement below:
\(\square \)
7 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.
7.1 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 draft05 in [38], draft10 and draftdh in [39], and draft14 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 multistage 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 \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {(EC)DHE} \) had 3 stages: handshake traffic key, application traffic key, and the resumption master secret \(\mathrm {RMS}\). draftdh and \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {(EC)DHE} \) added the exporter master secret \(\mathrm {EMS}\). In this paper we have 6 stages capturing the final RFC’s main handshake: handshake traffic keys \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\); application traffic secrets \(\mathrm {CATS}\) and \(\mathrm {SATS}\); and \(\mathrm {EMS}\) and \(\mathrm {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 (\(\mathrm {tk}_{\text {chs}}, \mathrm {tk}_{\text {shs}}, \mathrm {CATS}, \mathrm {SATS}\)).
Stages—PSK Handshake \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {SR} \) had 2 stages: handshake traffic key and application traffic key. \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {PSK} \) added \(\mathrm {EMS}\). \(\texttt {draft} \text {}\texttt {14} \text {}\texttt {PSK} \text {}\texttt {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 \(\mathrm {ETS}\); early exporter master secret \(\mathrm {EEMS}\); handshake traffic keys \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {shs}}\); application traffic secrets \(\mathrm {CATS}\) and \(\mathrm {SATS}\); and \(\mathrm {EMS}\) and \(\mathrm {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, \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {(EC)DHE} \) and \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {(EC)DHE} \) included \(\texttt {ClientCertificate} \) in the application key session identifiers but not \(\texttt {ServerFinished} \), whereas TLS 1.3 analyzed in this paper does not include \(\texttt {CCRT} \) but does include \(\texttt {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 \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {(EC)DHE} \), draftdh, \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {(EC)DHE} \), and this paper remain the same. (In early papers we used the notation \(\textsf {PRF} \text { }\textsf {ODH} \) rather than the newer notation \({\textsf {snPRF} \text {}\textsf {ODH} }\) introduced by [17], but the actual assumption was the same.)
Cryptographic Assumptions—PSK Handshake In draft05, no (EC)DHE variant of the PSK handshake was present (then called “session resumption handshake”), so the proof of \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {SR} \) relied solely on symmetrickey assumptions. \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {PSK} \) relied on the same assumptions as \(\texttt {draft} \text {}\texttt {05} \text {}\texttt {SR} \), whereas \(\texttt {draft} \text {}\texttt {10} \text {}\texttt {PSK} \text {}\texttt {(EC)DHE} \) added an \({\textsf {EUF} \text {}\textsf {CMA} }\) assumption on \(\textsf {HMAC} \) as well as the \(\textsf {PRF} \text { }\textsf {ODH} \) assumption. \(\texttt {draft} \text {}\texttt {14} \text {}\texttt {PSK} \text {}\texttt {0RTT} \) and \(\texttt {draft} \text {}\texttt {14} \text {}\texttt {PSK} \text {}\texttt {(EC)DHE} \text {}\texttt {0RTT} \) added a randomness assumption on \(\textsf {HMAC} \), which in the analysis of the final RFC’s \(\texttt {TLS1.3} \text {}\texttt {PSK} \text {}\texttt {0RTT} \) and \(\texttt {TLS1.3} \text {}\texttt {PSK} \text {}\texttt {(EC)DHE} \text {}\texttt {0RTT} \) in this paper is superseded by a \({\textsf {dual} \text {}\textsf {PRF} \text {}\textsf {sec} }\) assumption on \(\textsf {HKDF} .\textsf {Extract} \) in the multistage security bounds. The latter more explicitly indicates those places where \(\textsf {HKDF} .\textsf {Extract} \) is keyed through the second argument, which were treated more implicitly in the theorem statements of earlier versions.
\(\textsf {Match} \)security of \(\texttt {TLS1.3} \text {}\texttt {PSK} \text {}\texttt {0RTT} \) and \(\texttt {TLS1.3} \text {}\texttt {PSK} \text {}\texttt {(EC)DHE} \text {}\texttt {0RTT} \) in this paper adds a collision resistance assumption on \(\textsf {HMAC} \) due to the introduction of the PSK binder.
7.2 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 \(\texttt {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 laterstage 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 interprotocol effects of security breakdowns. (Some early drafts had less key independence: for example, in draft05, each exported key was derived directly from the master secret \(\mathrm {MS}\). Since \(\mathrm {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 \(\mathrm {EMS}\) is derived from \(\mathrm {MS}\), and then all exported keys are derived from \(\mathrm {EMS}\): we can treat \(\mathrm {EMS}\) as an output stage key, and consider the derivation of exported keys as a symmetric protocol using \(\mathrm {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 secondlevel 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 \(\mathrm {CHTS}\)/\(\mathrm {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 multistage 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 \(\mathrm {HS}\), enabling \(\mathrm {CHTS}\)/\(\mathrm {SHTS}\) to become firstorder session keys on the same level as all others. This in turn would allow a more uniform interface for composition with arbitrary symmetrickey 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 DelignatLavaud 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 applicationlayer protocol), including the session hash is appropriate. While the standardized tlsunique [8] and proposed tlsuniqueprf [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 \(\textsf {HKDF} .\textsf {Extract} \) computations over a 0string using the preshared key as the key. All sessions sharing the same preshared 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 \(\mathrm {tk}_{\text {chs}}\) and \(\mathrm {tk}_{\text {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 \(\mathrm {tk}_{\text {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 \(\texttt {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 \(\mathrm {fk}_{C}\)/\(\mathrm {fk}_{S}\).
Interestingly, according to our proofs, the \(\texttt {Finished} \) messages do not contribute to the implicit authentication and secrecy of the output keys in the full handshake or the PSKonly 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 PSKonly handshake, all keys are derived from the PSK which provides implicit authentication. While \(\texttt {Finished} \) messages are not needed to provide implicit authentication in PSKonly 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 \(\texttt {Finished} \) messages do contribute authentication of the ephemeral Diffie–Hellman public keys under (a key derived from) the PSK. The \(\texttt {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 \(\texttt {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 hashthensign 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 collisionresistant 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.
0RTT 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 0RTT keys has no negative effects on the cryptographic security of subsequently derived keys. From a practical, applicationlayer perspective, the potential for 0RTT 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 0RTT data,” and at the same time urges implementations to at least implement a certain basic level of antireplay protection (like singleuse session tickets, \(\texttt {ClientHello} \) recording, or freshness checks). The 0RTT modes of Google’s QUIC protocol and TLS 1.3 spawned a series of academic treatments of 0RTT key exchange [52, 62, 78] and new designs of forwardsecure encryption [30, 59] to achieve forwardsecret and nonreplayable 0RTT key exchange [46, 57] and TLS session resumption [6].
Also, from a cryptographic perspective, the Diffie–Hellmanbased 0RTT 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 0RTT communication [53, 74]. This handshake variant was abandoned with draft13 in favor of performance and structural simplification.
7.3 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 followup (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 followup 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 multistage 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, multikey, multiplexed, and streaming nature of the TLS 1.3 record protocol [23, 54, 60, 85, 88].
PostQuantum 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. Postquantum key exchange, however, is usually formulated generically as a key encapsulation mechanism (KEM). If TLS 1.3 is to be extended to support postquantum or hybrid (i.e., traditional plus postquantum) key exchange [36], our results on the full 1RTT and PSK(EC)DHE modes will need to be revisited in the context of specific postquantum KEMs or generic properties of KEMs. As we rely on the \(\textsf {PRF} \text { }\textsf {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 INDCCA KEM. Brendel et al. [16] discuss challenges arising when moving Diffie–Hellmanstyle key exchanges to the postquantum setting and Schwabe et al. [93] present a KEMbased alternative to the TLS 1.3 handshake with modified message flow.
7.4 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 1RTT handshake mode as well as the PSKbased resumption handshake modes, with optional 0RTT keys, in the reductionist framework of an enhanced multistage 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 wideranging 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 realworld 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.
References
L. Akhmetzyanova, E. Alekseev, E. Smyshlyaeva, A. Sokolov, Continuing to reflect on TLS 1.3 with external PSK. Cryptology ePrint Archive, Report 2019/421 (2019). https://eprint.iacr.org/2019/421
D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J.A. Halderman, N. Heninger, D. Springall, E. Thomé, L. Valenta, B. VanderSloot, E. Wustrow, S. ZanellaBéguelin, P. Zimmermann, Imperfect forward secrecy: How DiffieHellman fails in practice, in ACM CCS 15 (2015)
G. Arfaoui, X. Bultel, P.A. Fouque, A. Nedelcu, C. Onete, The privacy of the TLS 1.3 protocol. PoPETs, 2019(4), 190–210 (2019). https://doi.org/10.2478/popets20190065
N. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering, J.C.N. Schuldt, On the security of RC4 in TLS, in Proceedings of 22nd USENIX Security Symposium, pp. 305–320. USENIX (2013)
M. Abdalla, M. Bellare, P. Rogaway, The oracle DiffieHellman assumptions and an analysis of DHIES. In David Naccache, editor, CTRSA 2001, volume 2020 of LNCS, pp. 143–158. Springer, Heidelberg, (2001). https://doi.org/10.1007/3540453539_12
N. Aviram, K. Gellert, T. Jager, Session resumption protocols and efficient forward security for TLS 1.3 0RTT. Journal of Cryptology (2021). To appear. Available as Cryptology ePrint Archive, Report 2019/228. https://eprint.iacr.org/2019/228
N.J. AlFardan, K.G. Paterson, Lucky thirteen: breaking the TLS and DTLS record protocols, in 2013 IEEE Symposium on Security and Privacy, pp. 526–540. IEEE Computer Society Press, (2013). https://doi.org/10.1109/SP.2013.42
J. Altman, N. Williams, L. Zhu, Channel Bindings for TLS. RFC 5929 (Proposed Standard), 2010. http://www.ietf.org/rfc/rfc5929.txt
B. Beurdouche, K. Bhargavan, A. DelignatLavaud, C. Fournet, M. Kohlweiss, A. Pironti, P.Y. Strub, J.K. Zinzindohoue, A messy state of the union: taming the composite state machines of TLS, in 2015 IEEE Symposium on Security and Privacy, pp. 535–552. IEEE Computer Society Press, 2015. https://doi.org/10.1109/SP.2015.39
B. Beurdouche, K. Bhargavan, A. DelignatLevaud, C. Fournet, M. Kohlweiss, A. Pironti, P.Y. Strub, J.K. Zinzindohoue, A messy state of the union: Taming the composite state machines of TLS, in Proceedings of IEEE Symposium on Security & Privacy (S&P) 2015, pp. 535–552. IEEE (2015)
K. Bhargavan, C. Brzuska, C. Fournet, M. Green, M. Kohlweiss, S. ZanellaBéguelin. Downgrade resilience in keyexchange protocols, in 2016 IEEE Symposium on Security and Privacy, pp. 506–525. IEEE Computer Society Press, 2016. https://doi.org/10.1109/SP.2016.37
M. Bellare, R. Canetti, H. Krawczyk, Keying hash functions for message authentication, in Neal Koblitz, editor, CRYPTO’96, vol. 1109 of LNCS, pp. 1–15. Springer, Heidelberg (1996). https://doi.org/10.1007/3540686975_1
K. Bhargavan, A. DelignatLavaud, C. Fournet, A. Pironti, P.Y. Strub, Triple handshakes and cookie cutters: breaking and fixing authentication over TLS, in 2014 IEEE Symposium on Security and Privacy, pp. 98–113. IEEE Computer Society Press (2014). https://doi.org/10.1109/SP.2014.14
M. Bellare, New proofs for NMAC and HMAC: Security without collisionresistance, in Cynthia Dwork, editor, CRYPTO 2006, vol. 4117 of LNCS, pp. 602–619. Springer, Heidelberg (2006). https://doi.org/10.1007/11818175_36
J. Brendel, M. Fischlin, F. Günther, Breakdown resilience of key exchange protocols: NewHope, TLS 1.3, and hybrids, in K. Sako, S. Schneider, P.Y.A. Ryan, editors, ESORICS 2019, Part II, volume 11736 of LNCS, pp. 521–541. Springer, Heidelberg (2019). https://doi.org/10.1007/9783030299620_25
J. Brendel, M. Fischlin, F. Günther, C. Janson, D. Stebila, Challenges in proving postquantum key exchanges based on key encapsulation mechanisms. Cryptology ePrint Archive, Report 2019/1356, 2019. https://eprint.iacr.org/2019/1356
J. Brendel, M. Fischlin, F. Günther, C. Janson, PRFODH: relations, instantiations, and impossibility results. In J. Katz, H. Shacham, editors, CRYPTO 2017, Part III, vol. 10403 of LNCS, pp. 651–681. Springer, Heidelberg (2017). https://doi.org/10.1007/9783319636979_22
K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, P.Y. Strub, Implementing TLS with verified cryptographic security, in 2013 IEEE Symposium on Security and Privacy, pp. 445–459. IEEE Computer Society Press (2013). https://doi.org/10.1109/SP.2013.37
K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, P.Y. Strub, S. Z. Béguelin, Proving the TLS handshake secure (as it is). In J.A. Garay, R. Gennaro, editors, CRYPTO 2014, Part II, vol. 8617 of LNCS, pp. 235–255. Springer, Heidelberg (2014). https://doi.org/10.1007/9783662443811_14
K. Bhargavan, C. Fournet, M. Kohlweiss, miTLS: verifying protocol implementations against realworld attacks. IEEE Security & Privacy, 14(6), 18–25 (2016) https://doi.org/10.1109/MSP.2016.123
C. Brzuska, M. Fischlin, N.P. Smart, B. Warinschi, S.C. Williams. Less is more: Relaxed yet composable security notions for key exchange. International Journal of Information Security, 12(4), 267–297 (2013) https://doi.org/10.1007/s102070130192y
C. Brzuska, M. Fischlin, B. Warinschi, S.C. Williams, Composability of BellareRogaway key exchange protocols, in Y. Chen, G. Danezis, V. Shmatikov, editors, ACM CCS 2011, pp. 51–62. ACM Press (2011). https://doi.org/10.1145/2046707.2046716
C. Boyd, B. Hale, Secure channels and termination: the last word on TLS. In T. Lange, O. Dunkelman, editors, LATINCRYPT 2017, vol. 11368 of LNCS, pp. 44–65. Springer, Heidelberg (2017). https://doi.org/10.1007/9783030252830_3
C. Badertscher, C. Matt, U. Maurer, P. Rogaway, B. Tackmann, Augmented secure channels and the goal of the TLS 1.3 record layer. In M. H. Au, A. Miyaji, editors, ProvSec 2015, vol. 9451 of LNCS, pp. 85–104. Springer, Heidelberg (2015). https://doi.org/10.1007/9783319260594_5
M. Bellare, P. Rogaway, Entity authentication and key distribution. In D.R. Stinson, editor, CRYPTO’93, vol. 773 of LNCS, pp. 232–249. Springer, Heidelberg (1994). https://doi.org/10.1007/3540483292_21
C. Brzuska, On the Foundations of Key Exchange. PhD thesis, Technische Universität Darmstadt, Darmstadt, Germany (2013). http://tuprints.ulb.tudarmstadt.de/3414/
M. Bellare, B. Tackmann. The multiuser security of authenticated encryption: AESGCM in TLS 1.3, in M. Robshaw, J. Katz, editors, CRYPTO 2016, Part I, vol. 9814 of LNCS, pp. 247–276. Springer, Heidelberg (2016). https://doi.org/10.1007/9783662530184_10
K. CohnGordon, C. Cremers, K. Gjøsteen, H. Jacobsen, T. Jager, Highly efficient key exchange protocols with optimal tightness, in A. Boldyreva, D. Micciancio, editors, CRYPTO 2019, Part III, vol. 11694 of LNCS, pp. 767–797. Springer, Heidelberg (2019). https://doi.org/10.1007/9783030269548_25
C. Cremers, M. Horvat, J. Hoyland, S. Scott, T. van der Merwe, A comprehensive symbolic analysis of TLS 1.3. In B.M. Thuraisingham, D. Evans, T. Malkin, D. Xu, editors, ACM CCS 2017, pp. 1773–1788. ACM Press (2017). https://doi.org/10.1145/3133956.3134063
R. Canetti, S. Halevi, J. Katz, A forwardsecure publickey encryption scheme, in E. Biham, editor, EUROCRYPT 2003, vol. 2656 of LNCS, pp. 255–271. Springer, Heidelberg (2003). https://doi.org/10.1007/3540392009_16
C. Cremers, M. Horvat, S. Scott, T. van der Merwe, Automated analysis and verification of TLS 1.3: 0RTT, resumption and delayed authentication, in 2016 IEEE Symposium on Security and Privacy, pp. 470–485. IEEE Computer Society Press (2016). https://doi.org/10.1109/SP.2016.35
S. Chen, S. Jero, M. Jagielski, A. Boldyreva, C. NitaRotaru, Secure communication channel establishment: TLS 1.3 (over TCP fast open) vs. QUIC, in K. Sako, S. Schneider, P.Y.A. Ryan, editors, ESORICS 2019, Part I, vol. 11735 of LNCS, pp. 404–426. Springer, Heidelberg (2019). https://doi.org/10.1007/9783030299590_20
R. Canetti, H. Krawczyk, Analysis of keyexchange protocols and their use for building secure channels. In B. Pfitzmann, editor, EUROCRYPT 2001, vol. 2045 of LNCS, pp. 453–474. Springer, Heidelberg (2001). https://doi.org/10.1007/3540449876_28
R. Canetti, H. Krawczyk, Security analysis of IKE’s signaturebased keyexchange protocol, in M. Yung, editor, CRYPTO 2002, vol. 2442 of LNCS, pp. 143–161. Springer, Heidelberg (2002). http://eprint.iacr.org/2002/120/. https://doi.org/10.1007/3540457089_10
Codenomicon. The Heartbleed bug. http://heartbleed.com (2014)
E. Crockett, C. Paquin, D. Stebila, Prototyping postquantum and hybrid key exchange and authentication in TLS and SSH, in NIST 2nd PostQuantum Cryptography Standardization Conference 2019 (2019)
T. Dierks, C, Allen, The TLS Protocol Version 1.0. RFC 2246 (Proposed Standard) (1999). Obsoleted by RFC 4346, updated by RFCs 3546, 5746, 6176, 7465, 7507, 7919. https://www.rfceditor.org/rfc/rfc2246.txt, https://doi.org/10.17487/RFC2246
B. Dowling, M. Fischlin, F. Günther, D. Stebila, A cryptographic analysis of the TLS 1.3 handshake protocol candidates, in I. Ray, N. Li, C. Kruegel, editors, ACM CCS 2015, pp. 1197–1210. ACM Press (2015). https://doi.org/10.1145/2810103.2813653
B. Dowling, M. Fischlin, F. Günther, D. Stebila, A cryptographic analysis of the TLS 1.3 draft10 full and preshared key handshake protocol. Cryptology ePrint Archive, Report 2016/081 (2016). http://eprint.iacr.org/2016/081
A. DelignatLavaud, C. Fournet, M. Kohlweiss, J. Protzenko, A. Rastogi, N. Swamy, S. ZanellaBéguelin, K. Bhargavan, J. Pan, J.K. Zinzindohoue, Implementing and proving the TLS 1.3 record layer, in 2017 IEEE Symposium on Security and Privacy, pp. 463–482. IEEE Computer Society Press (2017). https://doi.org/10.1109/SP.2017.58
A. DelignatLavaud, C. Fournet, B. Parno, J. Protzenko, T. Ramananandro, J. Bosamiya, J. Lallemand, I. Rakotonirina, Y. Zhou, A security model and fully verified implementation for the IETF QUIC record layer. Cryptology ePrint Archive, Report 2020/114 (2020). https://eprint.iacr.org/2020/114
C.D. de Saint Guilhem, M. Fischlin, B. Warinschi, Authentication in keyexchange: Definitions, relations and composition. Cryptology ePrint Archive, Report 2019/1203 (2019). https://eprint.iacr.org/2019/1203
H. Davis, F. Günther. Tighter proofs for the SIGMA and TLS 1.3 key exchange protocols, in 19th International Conference on Applied Cryptography and Network Security, ACNS 2021, 2021. To appear. Available as Cryptology ePrint Archive, Report 2020/1029. https://eprint.iacr.org/2020/1029
N. Drucker, S. Gueron, Selfie: reflections on TLS 1.3 with PSK. Journal of Cryptology (2021). To appear. Available as Cryptology ePrint Archive, Report 2019/347. https://eprint.iacr.org/2019/347.
D. Diemert, T. Jager, On the tight security of TLS 1.3: theoreticallysound cryptographic parameters for realworld deployments. Journal of Cryptology (2021). To appear. Available as Cryptology ePrint Archive, Report 2020/726. https://eprint.iacr.org/2020/726
D. Derler, T. Jager, D. Slamanig, C. Striecks, Bloom filter encryption and applications to efficient forwardsecret 0RTT key exchange. In J.B. Nielsen, V. Rijmen, editors, EUROCRYPT 2018, Part III, vol. 10822 of LNCS, pp. 425–455. Springer, Heidelberg (2018). https://doi.org/10.1007/9783319783727_14
B. Dowling, Provable Security of Internet Protocols. Ph.D. thesis, Queensland University of Technology, Brisbane, Australia (2017). http://eprints.qut.edu.au/108960/
T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346 (Proposed Standard), April 2006. Obsoleted by RFC 5246, updated by RFCs 4366, 4680, 4681, 5746, 6176, 7465, 7507, 7919. https://www.rfceditor.org/rfc/rfc4346.txt. https://doi.org/10.17487/RFC4346
T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard), August 2008. Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685, 7905, 7919. https://www.rfceditor.org/rfc/rfc5246.txt, https://doi.org/10.17487/RFC5246
B. Dowling, D. Stebila, Modelling ciphersuite and version negotiation in the TLS protocol, in E. Foo, D. Stebila, editors, ACISP 15, vol. 9144 of LNCS, pp. 270–288. Springer, Heidelberg (2015). https://doi.org/10.1007/9783319199627_16
T. Duong. BEAST. http://vnhacker.blogspot.com.au/2011/09/beast.html (2011)
M. Fischlin, F. Günther, Multistage key exchange and the case of Google’s QUIC protocol, in G.J. Ahn, M. Yung, N. Li, editors, ACM CCS 2014, pp. 1193–1204. ACM Press (2014). https://doi.org/10.1145/2660267.2660308
M. Fischlin, F. Günther, Replay attacks on zero roundtrip time: the case of the TLS 1.3 handshake candidates, in 2017 IEEE European Symposium on Security and Privacy, EuroS&P 2017, pp. 60–75, Paris, France (2017). IEEE
M. Fischlin, F. Günther, G.A. Marson, K.G. Paterson, Data is a stream: Security of streambased channels, in R. Gennaro, M.J.B. Robshaw, editors, CRYPTO 2015, Part II, vol. 9216 of LNCS, pp. 545–564. Springer, Heidelberg (2015). https://doi.org/10.1007/9783662480007_27
M. Fischlin, F. Günther, B. Schmidt, B. Warinschi, Key confirmation in key exchange: a formal treatment and implications for TLS 1.3, in 2016 IEEE Symposium on Security and Privacy, pp. 452–469. IEEE Computer Society Press (2016). https://doi.org/10.1109/SP.2016.34
S. Gajek, A universally composable framework for the analysis of browserbased security protocols, in J. Baek, F. Bao, K. Chen, X. Lai, editors, ProvSec 2008, vol. 5324 of LNCS, pp. 283–297. Springer, Heidelberg (2008)
F. Günther, B. Hale, T. Jager, S. Lauer, 0RTT key exchange with full forward secrecy, in J.S. Coron, J.B. Nielsen, editors, EUROCRYPT 2017, Part III, vol. 10212 of LNCS, pp. 519–548. Springer, Heidelberg (2017). https://doi.org/10.1007/9783319566177_18
F. Giesen, F. Kohlar, D. Stebila, On the security of TLS renegotiation, in A.R. Sadeghi, V.D. Gligor, M. Yung, editors, ACM CCS 2013, pp. 387–398. ACM Press (2013). https://doi.org/10.1145/2508859.2516694
M.D. Green, I. Miers, Forward secure asynchronous messaging from puncturable encryption, in 2015 IEEE Symposium on Security and Privacy, pp. 305–320. IEEE Computer Society Press (2015). https://doi.org/10.1109/SP.2015.26
F. Günther, S. Mazaheri, A formal treatment of multikey channels, in J. Katz, H. Shacham, editors, CRYPTO 2017, Part III, vol. 10403 of LNCS, pp. 587–618. Springer, Heidelberg (2017). https://doi.org/10.1007/9783319636979_20
F. Günther, Modeling advanced security aspects of key exchange and secure channel protocols. PhD thesis, Technische Universität Darmstadt, Darmstadt, Germany (2018). http://tuprints.ulb.tudarmstadt.de/7162/
B. Hale, T. Jager, S. Lauer, J. Schwenk, Simple security definitions for and constructions of 0RTT key exchange, in D. Gollmann, A. Miyaji, H. Kikuchi, editors, ACNS 17, vol. 10355 of LNCS, pp. 20–38. Springer, Heidelberg (2017). https://doi.org/10.1007/9783319612041_2
J. Jonsson, B.S. Kaliski Jr., On the security of RSA encryption in TLS, in Moti Yung, editor, CRYPTO 2002, vol. 2442 of LNCS, pp. 127–142. Springer, Heidelberg (2002). https://doi.org/10.1007/3540457089_9
T. Jager, F. Kohlar, S. Schäge, J. Schwenk, On the security of TLSDHE in the standard model, in R. SafaviNaini, R. Canetti, editors, CRYPTO 2012, vol. 7417 of LNCS, pp. 273–293. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642320095_17
S. Josefsson, Channel bindings for TLS based on the PRF. https://tools.ietf.org/html/draftjosefssonsasltlscb03 (2015)
T. Jager, J. Schwenk, J. Somorovsky, On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption, in I. Ray, N. Li, C. Kruegel, editors, ACM CCS 2015, pp. 1185–1196. ACM Press (2015). https://doi.org/10.1145/2810103.2813657
H. Krawczyk, M. Bellare, R. Canetti, HMAC: KeyedHashing for Message Authentication. RFC 2104 (Informational) (1997). Updated by RFC 6151. https://www.rfceditor.org/rfc/rfc2104.txt, https://doi.org/10.17487/RFC2104
H. Krawczyk, P. Eronen, HMACbased ExtractandExpand Key Derivation Function (HKDF). RFC 5869 (Informational) (2010). https://www.rfceditor.org/rfc/rfc5869.txt, https://doi.org/10.17487/RFC5869
M. Kohlweiss, U. Maurer, C. Onete, B. Tackmann, D. Venturi, (De)constructing TLS 1.3, in A. Biryukov, V. Goyal, editors, INDOCRYPT 2015, vol. 9462 of LNCS, pp. 85–102. Springer, Heidelberg (2015). https://doi.org/10.1007/9783319266176_5
H. Krawczyk, K.G. Paterson, H. Wee, On the security of the TLS protocol: a systematic analysis. In R. Canetti, J.A. Garay, editors, CRYPTO 2013, Part I, vol. 8042 of LNCS, pp. 429–448. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642400414_24
H. Krawczyk, The order of encryption and authentication for protecting communications (or: How secure is SSL?). In J. Kilian, editor, CRYPTO 2001, vol. 2139 of LNCS, pp. 310–331. Springer, Heidelberg (2001). https://doi.org/10.1007/3540446478_19
H. Krawczyk, SIGMA: the “SIGnandMAc” approach to authenticated DiffieHellman and its use in the IKE protocols, in D. Boneh, editor, CRYPTO 2003, vol. 2729 of LNCS, pp. 400–425. Springer, Heidelberg (2003). https://doi.org/10.1007/9783540451464_24
H. Krawczyk, Cryptographic extraction and key derivation: the HKDF scheme, in T. Rabin, editor, CRYPTO 2010, vol. 6223 of LNCS, pp. 631–648. Springer, Heidelberg (2010). https://doi.org/10.1007/9783642146237_34
H. Krawczyk, [IETF TLS mailing list] Re: Call for consensus: Removing DHEbased 0RTT. https://mailarchive.ietf.org/arch/msg/tls/xmnvrKEQkEbDu8HTeQkyitmclY (2016)
H. Krawczyk, A unilateraltomutual authentication compiler for key exchange (with applications to client authentication in TLS 1.3). In E.R. Weippl, S. Katzenbeisser, C. Kruegel, A.C. Myers, S. Halevi, editors, ACM CCS 2016, pp. 1438–1450. ACM Press (2016). https://doi.org/10.1145/2976749.2978325
F. Kohlar, S. Schäge, and J. Schwenk, On the security of TLSDH and TLSRSA in the standard model. Cryptology ePrint Archive, Report 2013/367 (2013). http://eprint.iacr.org/2013/367
H. Krawczyk, H. Wee, The OPTLS protocol and TLS 1.3, in 2016 IEEE European Symposium on Security and Privacy, pp. 81–96. IEEE (2016). https://doi.org/10.1109/EuroSP.2016.18
R. Lychev, S. Jero, A. Boldyreva, C. NitaRotaru, How secure and quick is QUIC? Provable security and performance analyses, in 2015 IEEE Symposium on Security and Privacy, pp. 214–231. IEEE Computer Society Press (2015). https://doi.org/10.1109/SP.2015.21
B.A. LaMacchia, K. Lauter, A. Mityagin, Stronger security of authenticated key exchange, in W. Susilo, J.K. Liu, Y. Mu, editors, ProvSec 2007, vol. 4784 of LNCS, pp. 1–16. Springer, Heidelberg (2007)
A. Luykx, K.G. Paterson. Limits on authenticated encryption use in TLS (2017). http://www.isg.rhul.ac.uk/~kp/TLSAEbounds.pdf
Y. Li, S. Schäge, Z. Yang, F. Kohlar, J. Schwenk, On the security of the preshared key ciphersuites of TLS, in H. Krawczyk, editor, PKC 2014, volume 8383 of LNCS, pp. 669–684. Springer, Heidelberg (2014). https://doi.org/10.1007/9783642546310_38
X. Li, J. Xu, Z. Zhang, D. Feng, H. Hu, Multiple handshakes security of TLS 1.3 candidates, in 2016 IEEE Symposium on Security and Privacy, pp. 486–505. IEEE Computer Society Press (2016). https://doi.org/10.1109/SP.2016.36
C. MacCárthaigh, [IETF TLS mailing list] Security review of TLS1.3 0RTT. https://mailarchive.ietf.org/arch/msg/tls/mHxiO3du9OQHkc6CBWBpc_KBpA (2017)
B. Möller, T. Duong, K. Kotowicz, This POODLE bites: exploiting the SSL 3.0 fallback. https://www.openssl.org/~bodo/sslpoodle.pdf (2014)
G.A. Marson, B. Poettering, Security notions for bidirectional channels. IACR Trans. Symm. Cryptol., 2017(1):405–426 (2017). https://doi.org/10.13154/tosc.v2017.i1.405426
P. Morrissey, N.P. Smart, B. Warinschi, A modular security analysis of the TLS handshake protocol, in J. Pieprzyk, editor, ASIACRYPT 2008, vol. 5350 of LNCS, pp. 55–73. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540892557_5
K.G. Paterson, T. Ristenpart, T. Shrimpton, Tag size does matter: attacks and proofs for the TLS record protocol, in D.H. Lee, X. Wang, editors, ASIACRYPT 2011, vol. 7073 of LNCS, pp. 372–389. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642253850_20
C. Patton, T. Shrimpton, Partially specified channels: the TLS 1.3 record layer without elision, in D. Lie, M. Mannan, M. Backes, X. Wang, editors, ACM CCS 2018, pp. 1415–1428. ACM Press (2018). https://doi.org/10.1145/3243734.3243789
K.G. Paterson, T. van der Merwe, Reactive and proactive standardisation of TLS, in L. Chen, D.A. McGrew, C.J. Mitchell, editors, Security Standardisation Research: Third International Conference (SSR 2016), volume 10074 of Lecture Notes in Computer Science, pp. 160–186, Gaithersburg, MD, USA, December 5–6 (2016). Springer
E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446 (Proposed Standard) (2018). https://www.rfceditor.org/rfc/rfc8446.txt, https://doi.org/10.17487/RFC8446
P. Rogaway, Formalizing human ignorance, in P.Q. Nguyen, editor, Progress in Cryptology  VIETCRYPT 06, vol. 4341 of LNCS, pp. 211–228. Springer, Heidelberg (2006)
E. Rescorla, H. Tschofenig, N. Modadugu, The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 – draftietftlsdtls1333. https://tools.ietf.org/html/draftietftlsdtls1333 (2019)
P. Schwabe, D. Stebila, T. Wiggers, Postquantum TLS without handshake signatures, in J. Ligatti, X. Ou, J. Katz, G. Vigna, editors, ACM CCS 20, pp. 1461–1480. ACM Press (2020). https://doi.org/10.1145/3372297.3423350
M. Thomson, S. Turner, Using TLS to Secure QUIC – draftietfquictls29. https://tools.ietf.org/html/draftietfquictls29 (2020)
Acknowledgements
We thank Markulf Kohlweiss for insightful discussions on the necessity of the PRFODH assumption for proofs of the TLS 1.3 handshakes. We thank Håkon Jacobsen for comments on the proof for the preshared key handshake, Joseph Jaeger and Damiano Abram for comments on the formalization of Match security, and Denis Diemert for comments on the handshake protocol figures. We also thank the reviewers of this and earlier versions of this work for valuable comments. Benjamin Dowling was supported by EPSRC grant EP/L018543/1. The work of Marc Fischlin has been funded in part by the German Federal Ministry of Education and Research and the Hessen State Ministry for Higher Education, Research and the Arts within their joint support of the National Research Center for Applied Cybersecurity. Felix Günther has been supported in part by Research Fellowship grant GU 1859/11 of the German Research Foundation (DFG) and National Science Foundation (NSF) grants CNS1526801 and CNS1717640. Douglas Stebila was supported by Australian Research Council (ARC) Discovery Project grant DP130104304, Natural Sciences and Engineering Research Council of Canada (NSERC) Discovery grant RGPIN201605146, and NSERC Discovery Accelerator Supplement grant RGPIN201605146. This work has been cofunded by the DFG as part of project S4 within the CRC 1119 CROSSING.
Open Access
This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
Funding
Open Access funding enabled and organized by Projekt DEAL.
Author information
Authors and Affiliations
Corresponding author
Additional information
Communicated by Colin Boyd.
A Reducing Multiple to Single Test Queries
A Reducing Multiple to Single Test Queries
In this section we give more details on the hybrid argument to reduce adversaries \(\mathcal {A}_{\mathrm{multi}}\) which make multiple \(\textsf {Test} \) queries in the \(\textsf {Multi} \text {}\textsf {Stage} \) game for the TLS 1.3 handshakes to adversaries \(\mathcal {A}_{\mathrm{single}}\) which restrict themselves to a single \(\textsf {Test} \) query. Note that any multiquery adversary cannot make more (reasonable) \(\textsf {Test} \) queries than the number \(n_{s}\) of overall sessions times the maximum number \(\textsf {M} \) of stages. Any adversary making more queries needs to repeat queries for some keys, yielding the reply \(\bot \), and such queries can be easily sorted out.
The main step is the hybrid argument where adversary \(\mathcal {A}_{\mathrm{single}}\) simulates \(\mathcal {A}_{\mathrm{multi}}\)’s attack, making only a single \(\textsf {Test} \) query. To do so, for a randomly chosen index \(n\) between 1 and the maximum number \(n_{s}\) of \(\textsf {Test} \) queries, adversary \(\mathcal {A}_{\mathrm{single}}\) returns the genuine keys in the first \(n1\) queries of \(\mathcal {A}_{\mathrm{multi}}\), poses the \(\textsf {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, \(\mathcal {A}_{\mathrm{single}}\) instead calls the \(\textsf {Reveal} \) oracle.
The above works along the common argument in hybrid games if we can ensure that \(\mathcal {A}_{\mathrm{single}}\) does not lose because of the additional \(\textsf {Reveal} \) queries it makes, i.e., if it reveals a key for the partner of the (only) \(\textsf {Test} \) session. One option to ensure this is to demand that \(\mathcal {A}_{\mathrm{multi}}\) never tests a session and its partner. Luckily, the multistage security model in Sect. 4 supports this smoothly. Namely, testing a session in stage i for which the \(\textsf {tested} _{i}\) flag has been already set to \(\textsf {true} \) will immediately return \(\bot \). 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 \(\textsf {Send} \) call and there is already a partner with \(\textsf {tested} _{i}=\textsf {true} \) (triggered in the \(\textsf {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 \(\textsf {Test} \) oracle execution).
Furthermore, a \(\textsf {Test} \) call to a session stage i for which the session has already passed, i.e., \(\textsf {st} _{\textsf {exec} }\ne \textsf {accepted} _{i}\), also returns \(\bot \). In other words, any \(\textsf {Test} \) query of \(\mathcal {A}_{\mathrm{multi}}\) to a partner of a previous \(\textsf {Test} \) query returns \(\bot \). We can therefore avoid such queries and let \(\mathcal {A}_{\mathrm{single}}\) answer \(\bot \) for such queries directly. In this case the remaining \(\textsf {Reveal} \) queries, substituting the first \(\textsf {Test} \) queries in the hybrid argument, cannot cause \(\mathcal {A}_{\mathrm{single}}\) to lose, because now they are for sure not partnered with the (only) \(\textsf {Test} \) query of \(\mathcal {A}_{\mathrm{single}}\).
There are two caveats in the above reasoning. First, adversary \(\mathcal {A}_{\mathrm{single}}\) needs to know if two session stages are partnered in order to correctly respond \(\bot \) for some \(\textsf {Test} \) queries. While this is trivial to deduce from the public communication data for \(\textsf {sid} _{1}\) and \(\textsf {sid} _{2}\), the session identifiers \(\textsf {sid} _{3},\dots ,\textsf {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 \(\mathcal {A}_{\mathrm{single}}\) know these two \(\textsf {internal} \) keys via carefully selected \(\textsf {Reveal} \) queries when testing for a stage \(i\ge 3\) then it can decrypt the communication and decide partnering with other sessions for this stage. Since these further \(\textsf {Reveal} \) queries are for earlier stages, they essentially cannot interfere with the stage of the \(\textsf {Test} \) session.
It is convenient to store the information about tested sessions in an internal array \(\textsf {simTested} _{i}[\textsf {label} ]\) which is set to \(\textsf {true} \) if session \(\textsf {label} \) would have been marked as \(\textsf {tested} _{i}\) in the game, if \(\mathcal {A}_{\mathrm{multi}}\) would have actually made that query. We write this as an array in order to distinguish this internal list to \(\mathcal {A}_{\mathrm{single}}\) from entries in sessions \(\textsf {label} \). At any point in time, the array \(\textsf {simTested} \) in \(\mathcal {A}_{\mathrm{single}}\)’s simulation will hold the same information as the entries \(\textsf {tested} \) if \(\mathcal {A}_{\mathrm{multi}}\) had actually made all \(\textsf {Test} \) queries.
The second issue arises from the fact that internal keys (i.e., keys in stages i with \(\textsf {USE} _{i} = \textsf {internal} \)) are overwritten in partners to tested sessions. This can happen in the \(\textsf {Send} (\textsf {label} ,m)\) command if a partner \(\textsf {label} \) of a tested session stage for \(\textsf {label} '\) (with \(\textsf {label} '.\textsf {tested} _{i}=\textsf {true} \)) goes to \(\textsf {accepted} _{i}\). Then the security game sets \(\textsf {label} .\textsf {key} _{i}\leftarrow \textsf {label} '.\textsf {key} _{i}\). The other case can occur in the \(\textsf {Test} (\textsf {label} ,i)\) query itself if a partnered session \(\textsf {label} '\) to the tested session is already in state \(\textsf {label} '.\textsf {st} _{\textsf {exec} }=\textsf {accepted} _{i}\). Then the internal key of that session \(\textsf {label} '\) is replaced by the answer for the tested session. But our adversary \(\mathcal {A}_{\mathrm{single}}\) with a single \(\textsf {Test} \) query of course only sets one session stage to be tested, influencing at most one further session, whereas \(\mathcal {A}_{\mathrm{multi}}\)’s multiple \(\textsf {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 \(\mathcal {A}_{\mathrm{multi}}\) through \(\mathcal {A}_{\mathrm{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 \(\mathcal {A}_{\mathrm{single}}\) keep internal arrays \(\textsf {actualKey} _{i}[\textsf {label} ]\) and \(\textsf {simKey} _{i}[\textsf {label} ]\) for the internal keys (in the actual attack of \(\mathcal {A}_{\mathrm{single}}\), resp. in the simulation of \(\mathcal {A}_{\mathrm{multi}}\)) at stage \(i\in \{1,2\}\) and let \(\mathcal {A}_{\mathrm{single}}\) adapt authenticated encryptions with respect to such keys when relaying them between the simulation \(\mathcal {A}_{\mathrm{multi}}\) and \(\textsf {Send} \).
Lemma A.1
Let \(\mathcal {A}_{\mathrm{multi}}\) be an adversary making at most \(n_{\textsf {Test} }\le \textsf {M} \cdot n_{s}\) calls to \(\textsf {Test} \) attacking TLS 1.3 full 1RTT handshake in the \(\textsf {Multi} \text {}\textsf {Stage} \) game. Then, there exists an adversary \(\mathcal {A}_{\mathrm{single}}\) which makes only a single \(\textsf {Test} \) query such that
In addition, \(\mathcal {A}_{\mathrm{single}}\) initiates the same maximum number \(n_{s}\) of sessions as \(\mathcal {A}_{\mathrm{multi}}\).
The lemma holds analogously for the other handshake variants of TLS 1.3 since the argument uses only specifics which are shared by all variants.
Proof
We build our adversary \(\mathcal {A}_{\mathrm{single}}\) from \(\mathcal {A}_{\mathrm{multi}}\) via a blackbox simulation. Adversary \(\mathcal {A}_{\mathrm{single}}\) proceeds as follows. Initially, it picks \(n\in \{1,2,\dots ,n_{\textsf {Test} }\}\) at random and initializes empty arrays \(\textsf {actualKey} _{i}[\,]\leftarrow \bot \), \(\textsf {simKey} _{i}[\,]\leftarrow \bot \) for \(i=1,2\) and \(\textsf {simTested} _{i}[\,]\leftarrow \textsf {false} \) for \(i\in \{1,2,\dots ,\textsf {M} \}\). Algorithm \(\mathcal {A}_{\mathrm{single}}\) then invokes \(\mathcal {A}_{\mathrm{multi}}\), relaying all oracle queries except for the \(\textsf {Send} \) and \(\textsf {Test} \) queries.
Simulating \(\textsf {Send} \) queries. A \(\textsf {Send} (\textsf {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=\textsf {label} .\textsf {stage} \) denote the current stage, meaning that the session has already accepted at stage i:

If \(i\le 1\) or \(m=\textsf {init} \) or \(m=\textsf {continue} \) then pass the command to the own \(\textsf {Send} \) oracle. Such messages are not encrypted, and we do not need to reencrypt the communication data.

If \(i\ge 2\) and \(\textsf {simTested} _{i}[\textsf {label} ]=\textsf {true} \), i.e., the data is encrypted under a key which has potentially changed due to the (virtual) test, then reencrypt with the client resp. server handshake traffic key in the experiment of \(\mathcal {A}_{\mathrm{single}}\). Note that session identifiers (esp. for stages \(i\ge 3\)) are not affected by this reencryption as they are defined over the cleartexts:

– If \(\textsf {label} .\textsf {role} =\textsf {initiator} \), i.e., we expect the client to receive a message protected under the server’s traffic handshake secret (the stage2 key), then decrypt m with key \(\textsf {simKey} _{2}[\textsf {label} ]\) and reencrypt the result with \(\textsf {actualKey} _{2}[\textsf {label} ]\) to \(m'\) before passing \((\textsf {label} ,m'\)) to the own \(\textsf {Send} \) oracle. Here, and in the following, we assume that encryption always succeeds for messages different from \(\bot \), and that \(\bot \) is encrypted to something which again decrypts to \(\bot \).

– If \(\textsf {label} .\textsf {role} =\textsf {responder} \), i.e., we expect the server to receive a message protected under the client’s traffic handshake secret (the stage1 key), then decrypt m with key \(\textsf {simKey} _{1}[\textsf {label} ]\) and reencrypt the result with \(\textsf {actualKey} _{1}[\textsf {label} ]\) to \(m'\) before passing \((\textsf {label} ,m'\)) to the own \(\textsf {Send} \) oracle.


In any other case just forward \((\textsf {label} ,m)\) to the own \(\textsf {Send} \) oracle.
For the response m from the \(\textsf {Send} \) oracle do the following:

If \(i\le 1\) then hand back the response unchanged.

If \(i\ge 2\) and \(\textsf {simTested} _{i}[\textsf {label} ]=\textsf {true} \), then adapt encryption to the keys expected by \(\mathcal {A}_{\mathrm{multi}}\):

If \(\textsf {label} .\textsf {role} =\textsf {initiator} \) then decrypt m with key \(\textsf {actualKey} _{1}[\textsf {label} ]\) and reencrypt the result with \(\textsf {simKey} _{1}[\textsf {label} ]\) to \(m'\) before returning \(m'\).

If \(\textsf {label} .\textsf {role} =\textsf {responder} \) then decrypt m with key \(\textsf {actualKey} _{2}[\textsf {label} ]\) and reencrypt the result with \(\textsf {simKey} _{2}[\textsf {label} ]\) to \(m'\) before returning \(m'\).


In any other case return m.
In addition, check if one needs to set the status of \(\textsf {simTested} \). If the \(\textsf {Send} \) call changes the status to \(\textsf {accepted} _{i+1}\) —about which the adversary \(\mathcal {A}_{\mathrm{single}}\) is informed— then do the following:

For \(i+1\le 2\), if there is a session \(\textsf {label} '\ne \textsf {label} \) with \(\textsf {label} '.\textsf {sid} _{i+1}=\textsf {label} .\textsf {sid} _{i+1}\) and \(\textsf {simTested} _{i+1}[\textsf {label} ']=\textsf {true} \), then set the test status for the session here, \(\textsf {simTested} _{i+1}[\textsf {label} ]\leftarrow \textsf {true} \). Note that since the session identifiers in the first two stages consists of the cleartext messages, this is easy to check in this case. Also copy the \(\textsf {internal} \) keys, \(\textsf {actualKey} _{i+1}[\textsf {label} ]\leftarrow \textsf {actualKey} _{i+1}[\textsf {label} ']\) and \(\textsf {simKey} _{i+1}[\textsf {label} ]\leftarrow \textsf {simKey} _{i+1}[\textsf {label} ']\).

For \(i+1\ge 3\), if \(\textsf {simTested} _{1}[\textsf {label} ]=\textsf {true} \) then fetch the key \(\textsf {actualKey} _{1}[\textsf {label} ]\), else make a \(\textsf {Reveal} \) query \((\textsf {label} ,1)\), and analogously for the key for stage 2. Since the session under consideration has already accepted in stage \(i+1\ge 3\) at this point, our adversary \(\mathcal {A}_{\mathrm{single}}\) obtains the two handshake traffic keys and uses these keys to decrypt the communication (in its attack) to recover \(\textsf {sid} _{i+1}\) in session \(\textsf {label} \). Compare this value to the session identifiers in all sessions \(\textsf {label} '\) with \(\textsf {simTested} _{i+1}[\textsf {label} ']=\textsf {true} \) for the same stage \(i+1\). Note that a session \(\textsf {label} '\) can only be partnered in stage \(i+1\ge 3\) if it is already partnered in the first two stages, because \(\textsf {sid} _{i+1}\) contains the identifiers \(\textsf {sid} _{1}\) and \(\textsf {sid} _{2}\) as prefix (except for the label). This also implies that such sessions can only derive the same handshake traffic keys. Thus, we can use the same handshake keys as for \(\textsf {label} \) to decrypt for \(\textsf {label} '\). If there is a match, then update \(\textsf {simTested} _{i+1}[\textsf {label} ]\leftarrow \textsf {true} \) and copy the keys from session \(\textsf {label} '\) as before, \(\textsf {actualKey} _{i+1}[\textsf {label} ]\leftarrow \textsf {actualKey} _{i+1}[\textsf {label} ']\) and \(\textsf {simKey} _{i+1}[\textsf {label} ]\leftarrow \textsf {simKey} _{i+1}[\textsf {label} ']\).
Except for the copying of the actual key, this now corresponds exactly to the update step in the \(\textsf {Send} \) query.
Simulating \(\textsf {Test} \) queries. The tth \(\textsf {Test} \) query \((\textsf {label} ,i)\) is answered as follows:

If there is no session \(\textsf {label} \), or the session \(\textsf {label} \) has not accepted in stage i yet—which is known to the adversary because it gets to learn \(\textsf {label} .\textsf {st} _{\textsf {exec} }\) upon successful completion of the ith stage— or \(\textsf {simTested} _{i}[\textsf {label} ]=\textsf {true} \), then immediately return \(\bot \).

Otherwise proceed as follows:

– If \(t<n\) then make a \(\textsf {Reveal} (\textsf {label} ,i)\) call to get the key K and return it to \(\mathcal {A}_{\mathrm{multi}}\). Set \(\textsf {simTested} _{i}[\textsf {label} ]\leftarrow \textsf {true} \) and, if \(i\le 2\) and the key is \(\textsf {internal} \), also set \(\textsf {actualKey} _{i}[\textsf {label} ]\leftarrow K\) and \(\textsf {simKey} _{i}[\textsf {label} ]\leftarrow K\).

– If \(t=n\) then make a \(\textsf {Test} (\textsf {label} ,i)\) call and return the answer K to \(\mathcal {A}_{\mathrm{multi}}\). Set \(\textsf {simTested} _{i}[\textsf {label} ]\leftarrow \textsf {true} \) and, if \(i\le 2\), also set \(\textsf {actualKey} _{i}[\textsf {label} ]\leftarrow K\) and \(\textsf {simKey} _{i}[\textsf {label} ]\leftarrow K\).

– If \(t>n\) then pick a key randomly and return it to \(\mathcal {A}_{\mathrm{multi}}\). Set \(\textsf {simTested} _{i}[\textsf {label} ]\leftarrow \textsf {true} \) and, if \(i\le 2\), this time define \(\textsf {actualKey} _{i}[\textsf {label} ]\leftarrow \textsf {Reveal} (\textsf {label} ,i)\) and \(\textsf {simKey} _{i}[\textsf {label} ]\leftarrow K\).


Finally, we need to check as in the original \(\textsf {Test} \) query if there is already a partnered session in accepted state for the same stage, and, if so, modify its status. If there exists a session \(\textsf {label} '\ne \textsf {label} \) which is partnered, \(\textsf {label} '.\textsf {sid} _{i}=\textsf {label} .\textsf {sid} _{i}\), and where \(\textsf {label} '.\textsf {st} _{\textsf {exec} }=\textsf {label} .\textsf {st} _{\textsf {exec} }=\textsf {accepted} _{i}\), then set \(\textsf {simTested} _{i}[\textsf {label} ']\leftarrow \textsf {true} \). If \(i\le 2\) then also copy the keys, \(\textsf {actualKey} _{i}[\textsf {label} ']\leftarrow \textsf {actualKey} _{i}[\textsf {label} ]\) and \(\textsf {simKey} _{i}[\textsf {label} ']\leftarrow \textsf {simKey} _{i}[\textsf {label} ]\). We note that the checking against a match to \(\textsf {label} '\) is done analogously to the \(\textsf {Send} \) query.
We remark that we do not alter the simulated \(\textsf {Reveal} \) oracle but let queries through without modifications. There are cases now where the multiquery adversary \(\mathcal {A}_{\mathrm{multi}}\) may thus obtain a different \(\textsf {internal} \) key than expected. But this can only happen for sessions which have been (virtually) tested, such that any \(\textsf {Reveal} \) query or such a partnered session where the key has been changed would make \(\mathcal {A}_{\mathrm{multi}}\) lose. We thus ignore these cases and simply continue with the misaligned answer.
Analysis Note that the additional \(\textsf {Reveal} \) queries, which \(\mathcal {A}_{\mathrm{single}}\) makes for \(\textsf {internal} \) keys in the simulation of \(\textsf {Send} \) and \(\textsf {Test} \) above, cannot interfere with its only \(\textsf {Test} \) query. Recall that \(\mathcal {A}_{\mathrm{single}}\) may make \(\textsf {Reveal} (\textsf {label} ,1)\) and \(\textsf {Reveal} (\textsf {label} ,2)\) queries when simulating the \(\textsf {Send} \) and \(\textsf {Test} \) queries.
In the simulated \(\textsf {Send} \) query we need to check that the potential \(\textsf {Reveal} (\textsf {label} ,1)\) and \(\textsf {Reveal} (\textsf {label} ,2)\) queries for the \(\textsf {internal} \) keys in stages 1 and 2 do not conflict with the (only) \(\textsf {Test} \) query for session \(\textsf {label} _{\textsf {tested} }\) which \(\mathcal {A}_{\mathrm{single}}\) makes for stage i. Note that these queries would only be made if the session \(\textsf {label} \) has accepted at a stage \(\ge 3\). Assume that indeed \(i\in \{1,2\}\) and that \(\textsf {label} _{\textsf {tested} }\) is partnered with \(\textsf {label} \) in that stage i. For this distinguish the point in time when the \(\textsf {Test} \) call to \(\textsf {label} _{\textsf {tested} }\) is made:

If the \(\textsf {Test} \) call for \(\textsf {label} _{\textsf {tested} }\) is made later, after session \(\textsf {label} \) has continued after accepting in stage \(i\le 2\) , then the adversary \(\mathcal {A}_{\mathrm{multi}}\) loses. The reason is that in this case there is a partnered session \(\textsf {label} \) which has continued beyond stage \(i\in \{1,2\}\) and has used the \(\textsf {internal} \) key already. Such a \(\textsf {Test} \) call sets \(\textsf {lost} \leftarrow \textsf {true} \) according to the model.

If the \(\textsf {Test} \) call for \(\textsf {label} _{\textsf {tested} }\) has already been made for stage \(i\in \{1,2\}\) before session \(\textsf {label} \) has continued after accepting in that stage, then the session \((\textsf {label} ,i)\) partnered to \((\textsf {label} _{\textsf {tested} },i)\) for \(i\in \{1,2\}\) must have been marked as tested, \(\textsf {simTested} _{i}[\textsf {label} ]=\textsf {true} \), in a simulation of \(\textsf {Test} \) or \(\textsf {Send} \) (without using \(\textsf {Reveal} \) queries for this stage with cleartext session identifiers). In this case, however, our algorithm \(\mathcal {A}_{\mathrm{single}}\) does not make a \(\textsf {Reveal} \) query for this stage but reads off the key from the array \(\textsf {actualKey} _{i}[\textsf {label} ]\).
Hence, in the first case we can only increase the success probability and in the second case we avoid a conflicting \(\textsf {Reveal} \) query straight away. Note that the same is true for the final check in the simulation of \(\textsf {Test} \).
It remains to argue the compatibility of the other potential \(\textsf {Reveal} \) queries in the simulated \(\textsf {Test} \) query. If the \(n\)th query for session \(\textsf {label} _{\textsf {tested} }\) and stage i (which \(\mathcal {A}_{\mathrm{single}}\) forwards to its \(\textsf {Test} \) oracle) would be partnered with the tth query \((\textsf {label} ,i)\), then the call of \(\mathcal {A}_{\mathrm{multi}}\) to its (simulated) \(\textsf {Test} \) oracle for \(\textsf {label} _{\textsf {tested} }\) later

would either make \(\mathcal {A}_{\mathrm{multi}}\) lose if the session \(\textsf {label} _{\textsf {tested} }\) was at the point of the query already past the state \(\textsf {accepted} _{i}\) for the \(\textsf {internal} \) key (according to the description of the \(\textsf {Test} \) oracle), or

the session \(\textsf {label} _{\textsf {tested} }\) is already in state \(\textsf {accepted} _{i}\) when the test query here is made, in which case the (simulated) \(\textsf {Test} \) oracle would mark that session \(\textsf {label} _{\textsf {tested} }\) as tested, \(\textsf {simTested} _{i}[\textsf {label} _{\textsf {tested} }]=\textsf {true} \), because it is partnered to the now (virtually) tested session \(\textsf {label} \), or

the session \(\textsf {label} _{\textsf {tested} }\) is not yet in state \(\textsf {accepted} _{i}\) when the test query here is made, in which case later the (simulated) \(\textsf {Send} \) oracle would mark that session \(\textsf {label} _{\textsf {tested} }\) as tested when it eventually accepts in stage i, \(\textsf {simTested} _{i}[\textsf {label} _{\textsf {tested} }]=\textsf {true} \), because it is then partnered to the (virtually) tested session \(\textsf {label} \) here.
We ignore the first case because it cannot contribute to \(\mathcal {A}_{\mathrm{multi}}\)’s success probability. For the latter two cases it follows that the \(n\)th query of \(\mathcal {A}_{\mathrm{multi}}\) will actually not be forwarded to \(\mathcal {A}_{\mathrm{single}}\)’s oracle \(\textsf {Test} \), because for such marked sessions with \(\textsf {simTested} _{i}[\textsf {label} _{\textsf {tested} }]=\textsf {true} \) the simulated \(\textsf {Test} \) oracle immediately returns \(\bot \). Hence, \(\mathcal {A}_{\mathrm{single}}\) does not make any \(\textsf {Test} \) query in these cases at all, and in particular cannot lose because of a \(\textsf {Reveal} \) query for a session partnered to the one in the \(\textsf {Test} \) query.
By the above it follows that \(\mathcal {A}_{\mathrm{single}}\) only sets \(\textsf {lost} \) in its attack if \(\mathcal {A}_{\mathrm{multi}}\) does so in the simulation. For the final step in the analysis of the hybrid argument observe that if \(n=1\) and \(b_{\textsf {test} }=0\) (for the challenge bit in \(\mathcal {A}_{\mathrm{single}}\)’s game) then our adversary \(\mathcal {A}_{\mathrm{single}}\) only returns random keys to \(\mathcal {A}_{\mathrm{multi}}'\) (or error messages \(\bot \)) in simulated \(\textsf {Test} \) queries. Furthermore, unless \(\mathcal {A}_{\mathrm{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 reencryption. Hence, in this case we have that \(\mathcal {A}_{\mathrm{single}}\) predicts its value \(b_{\textsf {test} }\) with the same probability as \(\mathcal {A}_{\mathrm{multi}}'\) when receiving only random keys in all (valid) \(\textsf {Test} \) queries. Analogously, if \(n=n_{\textsf {Test} }\) and \(b_{\textsf {test} }=1\) then \(\mathcal {A}_{\mathrm{single}}\) always returns genuine keys (or errors) to \(\mathcal {A}_{\mathrm{multi}}'\), again, in a sound simulation unless \(\mathcal {A}_{\mathrm{multi}}'\) loses. This therefore corresponds to the case that \(\mathcal {A}_{\mathrm{multi}}'\) only receives genuine keys in all (valid) \(\textsf {Test} \) queries.
For the analysis, let b be the output of \(\mathcal {A}_{\mathrm{single}}\) and \(b_{\textsf {test} }\) be its challenge bit. Similarly, let \(b'\) be the output of \(\mathcal {A}_{\mathrm{multi}}\) in an actual attack for test bit \(b_{\textsf {test} }'\). We denote by \(b=b_{\textsf {test} }\) resp. \(b'=b_{\textsf {test} }'\) the events that the bit is correct and the \(\textsf {lost} \) flag is not set. Then,
and noting that the simulation conditioned on \(b_{\textsf {test} }=1\) and \(n=n_{0}\) is equivalent to the simulation for \(b_{\textsf {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 \(\mathcal {A}_{\mathrm{multi}}\) does not lose) and thus at least the probability in an actual attack. We remark that our adversary \(\mathcal {A}_{\mathrm{single}}\) may trigger \(\textsf {lost} \leftarrow \textsf {true} \) less often than \(\mathcal {A}_{\mathrm{multi}}\), e.g., because of the omitted \(\textsf {Test} \) queries and potential conflicts with \(\textsf {Reveal} \) queries. Hence, we obtain
proving the claim of the lemma. \(\square \)
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the 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/.
About this article
Cite this article
Dowling, B., Fischlin, M., Günther, F. et al. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol. J Cryptol 34, 37 (2021). https://doi.org/10.1007/s00145021093841
Received:
Revised:
Accepted:
Published:
DOI: https://doi.org/10.1007/s00145021093841
Keywords
 Authenticated key exchange
 Transport Layer Security (TLS)
 Handshake protocol