A Cryptographic Analysis of the TLS 1.3 Handshake Protocol

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

Introduction

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

Development and Standardization of TLS 1.3

With concerns rising about the security of TLS version 1.2 due to the many attacks, but also motivated by desire to deprecate old algorithms, enhance privacy, and reduce connection establishment latency, in 2014 the IETF’s TLS working group initiated a multi-year process to develop and standardize a new version of TLS, eventually called version 1.3. From 2014 through 2018, a total 29 drafts of TLS 1.3 were published, with active feedback from industry and academia, including extensive security analyses by various teams from academia (see [89] for a chronicle of the development and analysis of TLS 1.3). The document standardizing TLS 1.3, RFC 8446 [90], was published in August 2018 and has already seen widespread adoption.

From a cryptographic perspective, major design changes in TLS 1.3 compared to version 1.2 include: (1) encrypting some handshake messages with an intermediate session key, to provide confidentiality of handshake data such as the client certificate; (2) signing the entire handshake transcript for authentication; (3) including hashes of handshake messages in a variety of key calculations; (4) using different keys to encrypt handshake messages and application data; (5) deprecating a variety of cryptographic algorithms (including RSA key transport, finite-field Diffie–Hellman key exchange, SHA-1, RC4, CBC mode, MAC-then-encode-then-encrypt); (6) using modern authenticated encryption with associated data (AEAD) schemes for protecting application data; and (7) providing handshakes with fewer message flows to reduce latency.

There are two primary modes of the TLS 1.3 handshake protocol. One is the full, one round-trip time (1-RTT) handshake, which uses public-key certificates for server and (optionally) client authentication, and (elliptic curve) Diffie–Hellman ephemeral ((EC)DHE) key exchange, inspired by Krawczyk’s ‘SIGn-and-MAc’ (SIGMA) design [72]. Several session keys are established for a variety of purposes in this mode: to encrypt part of the handshake, to enable export of keying material to other applications, for session resumption, and of course to encrypt application data. This mode gets its name from the fact that application data can be sent from the client to the server with the handshake’s completion after a full round trip, meaning there is one round-trip time (1-RTT) until the first application message can be sent (not counting non-TLS networking operations such as DNS lookups or the TCP 3-way handshake).

The other primary mode of the TLS 1.3 handshake protocol is the resumption or pre-shared key (PSK) mode, in which authentication is based on a symmetric pre-shared key, with optional (EC)DHE key exchange for forward secrecy; this generalizes the abbreviated session resumption handshake from earlier versions of TLS. The PSK mode can optionally be augmented with a zero round-trip time (0-RTT) key establishment, allowing the client to send—along with its first TLS flow—application data encrypted under a key derived from the PSK.

Security Analyses of TLS

TLS 1.2 and Prior Versions A long line of work has analyzed various versions of the SSL/TLS protocol using both formal methods and reductionist security proofs. In the reductionist security paradigm, early work [56, 63, 86] on the handshake protocol dealt with modified or truncated versions of the protocol, necessary because TLS 1.2 and earlier did not have strict key separation: the session key was also used to encrypt messages within the handshake protocol, barring security proofs in strong indistinguishability-based 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 1-RTT handshake by Diemert and Jager [45] and Davis and Günther [43] translated techniques of Cohn-Gordon et al. [28] to establish tighter reductions. There have also been academic proposals for improvements to or modifications of TLS 1.3, considering forward security for the 0-RTT handshake [6], running TLS 1.3 over a different network protocol [32], or defining a KEM-based alternative handshake enabling the deployment of post-quantum schemes [93].

Our Contributions

We give a reductionist security analysis of three modes of the TLS 1.3 handshake: the full 1-RTT handshake, the PSK handshake (with optional 0-RTT mode), and the PSK-(EC)DHE handshake (with optional 0-RTT mode); based on a cryptographic abstraction of the protocols we provide in Sect. 3. In order to carry out our analysis, we formalize a multi-stage key exchange security model which can capture a variety of characteristics associated to each stage key. Our analysis shows that the design of the TLS 1.3 handshake follows sound cryptographic principles.

Security Model Our security model, given in Sect. 4, follows the Bellare–Rogaway (BR) model [25] for authenticated key exchange security based on session key indistinguishability, as formalized by Brzuska et al. [22, 26], and our model builds specifically on the multi-stage model of Fischlin and Günther [52, 61]. The latter deals with key exchange protocols that derive a series of session keys in the course of multiple protocol stages. Our extension of their multi-stage key exchange model allows us to capture the following characteristics associated to the session key established at each stage, which we call the stage key:

• Authentication: whether a stage key is unauthenticated, unilaterally authenticated, or mutually authenticated. We further extend the multi-stage model to capture upgradable authentication: a stage’s key may be considered, say, unauthenticated at the time it is accepted, but the authentication level of this key may be “raised” to unilaterally authenticated or, potentially in a second step, mutually authenticated after some later operations, such as verification of a signature in a later message.

• Forward secrecy: whether a stage key is meant to provide forward secrecy, namely that it remains secure after compromise of a long-term secret involved in its derivation.

• Key usage: whether a stage key is meant to be used internally within the protocol (for example, to encrypt later handshake messages), or externally (for example, composed with a symmetric encryption scheme to protect application messages or used in some other external symmetric-key protocol).

• Replayability: whether it is guaranteed that a stage key is not established in result of a replay attack; early stages of the 0-RTT modes do not have this guarantee.

Our security model comes in two flavors that capture security established through two types of credentials: public keys or symmetric pre-shared keys. Following the BR model, our model of compromise includes long-term key compromise ($\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 multi-stage key exchange security model in Sects. 5 and 6 to analyze the three modes of the TLS 1.3 handshake: full 1-RTT, PSK, and PSK-(EC)DHE, with the latter two having optional 0-RTT keys. There are four main classes of stage keys covered in the analysis: early data encryption and export keys ($\mathrm {ETS}, \mathrm {EEMS}$, only present in the PSK with 0-RTT 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 1-RTT mode and eight stage keys in the PSK modes.

As noted above, our security model allows us to precisely capture various characteristics of different stage keys. For example, consider the client handshake traffic secret $\mathrm {tk}_{\text {chs}}$, used to encrypt handshake messages from the client to the server. In the full 1-RTT handshake, this key is initially unauthenticated, then unilaterally authenticated through a server signature after stage 3 is reached, and may ultimately be mutually authenticated after stage 6 is reached if the client authenticates; it is forward secret; it is intended for internal use within the protocol; and it is guaranteed to be non-replayed. In contrast, in the PSK handshake, this key is mutually authenticated as soon as it is established, but does not have forward secrecy. Finally, in the PSK-EC(DHE) handshake, this key is unauthenticated initially, then is upgraded to unilateral and eventually mutual authentication after stages 5 and 8, when MACs within the $\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 1-RTT resp. PSK handshake), hash function collision resistance, PRF security (and in some cases dual PRF security), and an interactive Diffie–Hellman assumption (a variant of the PRF-Oracle-Diffie–Hellman assumption [17, 64] called dual-snPRF-ODH).

Observations on the Design and Security of TLS 1.3 In Sect. 7, we include a discussion about various characteristics of TLS 1.3 based on results of our security analysis, including how a variety of TLS 1.3 design decisions positively impact the security analysis (key separation and key independence, including the session hash in signatures and key derivation), some subtleties on the role of handshake encryption and key confirmation via $\texttt {Finished}$ messages, as well as the susceptibility of 0-RTT keys to replays.

Relation to Our Earlier Work This paper is successor work to [38, 39] and [53], as well as [47, 61]. In [38], we first extended the multi-stage key exchange model of [52] as needed, then applied it to analyze two early drafts of TLS 1.3: draft-05, which has the same basic signed-Diffie–Hellman structure but a simplified key schedule compared to the final version, and an alternative proposal called draft-dh incorporating ideas from the OPTLS design [77], in which servers could have a semi-static DH key share. In [39], we updated our analysis to draft-10 and added an analysis of the, by then revised, pre-shared-key handshake mode. In [53], a subset of us analyzed the 0-RTT pre-shared key and PSK-(EC)DHE mode in draft-14, as well as the later deprecated Diffie–Hellman-based 0-RTT mode using semi-static DH key shares in draft-12, which introduced the notion of replayable stages into the multi-stage key exchange security model. In a PhD thesis [47], one of us updated the work from [39] to address the full, PSK, and PSK-(EC)DHE handshakes in draft-16; in another PhD thesis [61], another of us unified the MSKE model and the aforementioned results on the full and PSK handshakes of draft-10 and the 0-RTT handshakes of draft-12 and draft-14.

This paper updates this prior work to the final version of TLS 1.3 as published in RFC 8446 [90] (recall that there were 29 drafts leading up to the final standard). It addresses, in a unified security model, the full, PSK, and PSK-(EC)DHE handshakes, the latter two with optional 0-RTT keys. The security model in this paper includes enhancements not present in earlier works, particularly for capturing upgradable authentication. The model and analysis for the PSK mode have been updated to reflect the observations of Drucker and Gueron’s “Selfie” attack [44] by associating intended roles with a pre-shared key.

Section 7.1 provides more details on technical differences between this paper and our earlier work.

Limitations The TLS 1.3 protocol allows users to support and negotiate different cryptographic algorithms including the used signature schemes, Diffie–Hellman groups, and authenticated encryption schemes. Many implementations will simultaneously support TLS 1.3, TLS 1.2, and even earlier versions. We do not aim to capture the security of this negotiation process nor security when a cryptographic key (e.g., a signing key) is re-used across different algorithm combinations or with earlier versions of TLS [66]. For the PSK modes of TLS 1.3, we do not treat how parties negotiate which pre-shared key to use. Our analysis assumes that all parties use only TLS 1.3 with a single combination of cryptographic algorithms and do not re-use keying material outside of that context (beyond consuming session keys established by the TLS 1.3 handshake).

In our proofs of key indistinguishability for all three TLS 1.3 handshake modes, some of our proof steps involve guessing parties and/or sessions, and thus are non-tight, similar to most proofs of authenticated key exchange protocols. Recently, Diemert and Jager [45] as well as Davis and Günther [43] have established new security proofs for the TLS 1.3 full 1-RTT handshake with tight reductions to the strong Diffie–Hellman assumption, translating techniques of Cohn-Gordon et al. [28].

Our focus is entirely on the TLS 1.3 handshake protocol, and thus does not address security of the record layer’s authenticated encryption. TLS 1.3 also includes a variety of additional functionalities outside the core handshake that we treat as out of scope. Examples include session tickets, post-handshake authentication [75], the alert protocol, and changes for Datagram TLS (DTLS) 1.3 [92], as well as other extensions to TLS 1.3 currently in the Internet-Draft state.

Security in practice obviously relies on many more factors, such as good implementations and good operational security, which are important but outside the scope of this analysis.

Preliminaries

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

Notation

With $\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}$.

Collision-Resistant Hash Functions

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

Definition 2.1

(Hash function and collision resistance) A hash function $\textsf {H} :\{0,1\}^* \rightarrow \{0,1\}^\lambda$ maps arbitrary-length 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 non-negligible with respect to the security parameter $\lambda$.

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 extract-then-expand 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 (non-secret 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]).

Dual PRF Security and the PRF-ODH Assumption

Most key derivation steps in TLS 1.3 rely on regular pseudorandom function (PRF) security for the HKDF and HMAC functions. In our analysis of the PSK handshakes, we also treat HMAC as a collision-resistant unkeyed hash function over the pair of inputs, as in Definition 2.1. For some of its applications, we, however, need to deploy stronger assumptions which we recap here.

The first assumption is concerned with the use of HMAC as a dual PRF (cf. [14]).

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

$$\begin{aligned} \textsf {Adv} _{f,\mathcal {A}}^{{\textsf {dual} \text {-}\textsf {PRF} \text {-}\textsf {sec} }} := \textsf {Adv} _{f^{\textsf {swap} },\mathcal {A}}^{{\textsf {PRF} \text {-}\textsf {sec} }}. \end{aligned}$$

The second assumption, the so-called pseudorandom-function oracle-Diffie–Hellman PRF-ODH assumption, has been introduced by Jager et al. [64] in their analysis of the TLS 1.2 key exchange. It is a variant of the oracle-Diffie–Hellman assumption introduced by Abdalla et al. [5] in the context of the DHIES encryption scheme. Basically, the PRF-ODH assumption states that the value $\textsf {PRF} (g^{uv},x^{\star })$ for a Diffie–Hellman-type key $g^{uv}$ is indistinguishable from a random string, even when given $g^u$ and $g^v$ and when being able to see related values $\textsf {PRF} (S^u,x)$ and/or $\textsf {PRF} (T^v,x)$ for chosen values S, T, and x. The PRF-ODH assumption comes in various variants, which have been generalized and studied by Brendel et al. [17].

For our analysis of TLS 1.3, we will deploy only the snPRF-ODH assumption providing limited oracle access to only a single related value $\textsf {PRF} (S^u,x)$, as well as its dual variant, dual-snPRF-ODH. Both have been established by Brendel et al. [17] to hold for $\textsf {HMAC}$ in the random oracle model under the strong Diffie–Hellman assumption.

Definition 2.3

(snPRF-ODH and dual-snPRF-ODH  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 snPRF-ODH 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 snPRF-ODH advantage function as

$$\begin{aligned} \textsf {Adv} _{\textsf {PRF} ,\mathbb {G},\mathcal {A}}^{{\textsf {snPRF} \text {-}\textsf {ODH} }} := 2\cdot \Pr [b^\prime = b] - 1. \end{aligned}$$

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.

The TLS 1.3 Handshake Protocol

In this section we describe the TLS 1.3 handshake protocol modes, specifically the full one round-trip time (1-RTT) handshake, depicted on the left-hand side of Fig. 1, and the combined zero round-trip time ($\text {0-RTT}$) and pre-shared key handshake, depicted on the right-hand side of in Fig. 1. Our focus in Fig. 1 and throughout the paper is on the cryptographic aspects of the TLS 1.3 handshake. As such, we omit many other components of the protocol, including most hello extensions, aspects of version and algorithm negotiation, post-handshake messages, the record layer protocol, and the alert protocol.

In TLS 1.3, the 1-RTT and PSK handshakes are divided into two distinct phases: a key exchange phase, where the client and the server exchange Hello messages to indicate support for different cryptographic options and use the selected parameters to generate key exchange material; and an authentication phase, where the client and the server exchange CertificateVerify and Finished messages, authenticating each other using long-term asymmetric (or symmetric) values. Figure 2 illustrates the key schedule of TLS 1.3, Table 1 lists abbreviations for messages and keys used throughout the paper, and Table 2 details some of the computations and inputs.

Fig. 1

The TLS 1.3 full 1-RTT handshake protocol (left) and the PSK/PSK-(EC)DHE handshake protocol with optional 0-RTT (right). Shorthands are explained in Table 1; the values of context and label inputs ($H_*$, resp. $\texttt {Label} _{*}$) and details on the calculation of traffic keys ($\mathrm {tk}_*$) can be found in Table 2

Key-Exchange 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 pre-shared symmetric key.

$\texttt {ClientHello}$. The client begins by sending the $\texttt {ClientHello}$ message, which contains $r_{c}$ (a randomly-sampled 256-bit 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 pre-shared keys or (EC)DHE groups) or handshake modes, but instead our analysis considers each handshake mode and ciphersuite combination in isolation. This can be seen in Fig. 1, e.g., the ${\texttt {CKS} }$ message contains only a single (EC)DHE key share.)

If a pre-shared secret has been established between the client and the server (either in a previous handshake or via some out-of-band mechanism) the client may include 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 pre-shared 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 pre-shared 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 right-hand side of Fig. 1.

Finally, if the client wishes to use the pre-shared secret to send zero-round-trip time ($\text {0-RTT}$) 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 pre-shared 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 key-exchange phase is the $\texttt {ServerHello}$ ($\texttt {SH}$) message. As in $\texttt {CH}$, the server will randomly sample a 256-bit nonce value $r_{s}$. The server picks among the various algorithms and parameters offered by the client and responds with its selections. If $\texttt {CPSK}$ was sent, the server decides whether to accept a PSK-based handshake. If so, then the pre-shared key identifier pskid associated with the selected $\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.

Fig. 2

The TLS 1.3 key schedule. The values of context and label inputs ($H_*$, resp. $\texttt {Label} _{*}$) and details on the calculation of traffic keys ($\textsf {Exp} _{*}$) can be found in Table 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 1-RTT handshake, authentication is based on public key certificates; see the left-hand side of Fig. 1. In pre-shared key handshakes (both PSK and PSK-(EC)DHE), the server and client will authenticate each other by relying on a message authentication code applied to the transcript; see the right-hand side of Fig. 1.

Authentication in Full 1-RTT Handshake The server can request public-key-based client authentication by sending a $\texttt {CertificateRequest}$ ($\texttt {CR}$) message. The server will authenticate to the client by using the server’s long-term 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.5-RTT handshake.

Client Verification, Authentication, Key Confirmation, and Key Derivation The client, upon receiving these messages, checks that the signature $\texttt {SCV}$ (if in full 1-RTT 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 public-key) 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 pre-shared 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.

Table 1 Shorthands for TLS 1.3 messages (in protocol order) and derived keys/values (alphabetical)

NewSessionTicket

The $\texttt {NewSessionTicket}$ message is a post-handshake 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 pre-shared 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 pre-shared 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 pre-shared key in future $\texttt {PreSharedKey}$ messages. In our notation used in Fig. 1, the pre-shared 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 out-of-band 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 symmetric-key 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.

Table 2 Secret, context, and label inputs to the $\textsf {HKDF} .\textsf {Expand}$ resp. authentication functions as well as traffic key calculation in the TLS 1.3 handshake (Fig. 1) and key schedule (Fig. 2)

Multi-Stage Key Exchange Security Model

In order to capture the security of all variants of the TLS 1.3 handshake within a single comprehensive security model, we adopt the multi-stage key exchange model in the version by Günther [61] which combines the original model by Fischlin and Günther [52] with follow-up extensions [38, 39, 53]. We refer to Günther [61] for an extensive discussion of the model, but recap its core concepts and definitions as well as adaptations for our analysis in the following.

The model follows the classical paradigm for key exchange models of Bellare and Rogaway [25] in the formalism of Brzuska et al. [22, 26]. This paradigm captures a strong adversary that controls the network and is able to both passively eavesdrop and 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 long-term 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 multi-stage key exchange model now extends the basic key exchange setting by capturing protocols that derive a series of session keys in multiple stages. Each stage is associated with particular security properties, steering admissibility of certain adversarial actions for that stage and under which conditions the key of this stage is considered fresh. These security properties model the following aspects:

Authentication. Our model distinguishes between unauthenticated stages, unilaterally authenticated stages where only the responder (the server in TLS 1.3) authenticates, and mutually authenticated stages where both peers authenticate. We treat the authentication of each stage individually and consider concurrent executions of different authentication modes of the same protocol. The identities of communication partners may be learned only during the execution of the protocol (e.g., through exchanged certificates), which we implement through post-specified peers following Canetti and Krawczyk [34]. Our model demands a strong notion of security for sessions with unauthenticated peers, namely that such sessions achieve key secrecy when receiving their messages from an honest session (identified via a contributive identifier), independent of whether that honest peer session later becomes partnered.

Moreover, the authentication level of some stage may be raised with acceptance of a later stage, e.g., from unauthenticated to unilaterally or even mutually authenticated. This may happen for instance if a party later signs previously transmitted data, as in case of TLS 1.3. We capture this by allowing a protocol to specify the authentication level for each acceptance stage, as well as at which later stage(s) that level increases.

Note that we capture authentication implicitly through key secrecy (i.e., keys are only known to the intended peer session) but do not prove explicit authentication (i.e., the existence of a partnered session). The SIGMA design [72], on which the main TLS 1.3 handshake is based, ensures explicit authentication. de Saint Guilhem et al. [42] give a generic argument that explicit authentication follows from implicit key secrecy (which is shown for TLS 1.3 in this article) and key confirmation [55].

Forward secrecy.We capture the usual notion of forward secrecy, which ensures that accepted session keys remain secure after a long-term secret compromise. In a multi-stage key exchange protocol, forward secrecy may however be reached only from a certain stage on (e.g., due to mixing-in forward-secret key material). The model hence treats stage-j forward secrecy, indicating that keys from stage j on are forward secret.

Key usage.Some stage keys might be used internally in the key exchange protocol, e.g., in the case of TLS 1.3 the handshake key is used to encrypt part of the key exchange communication. We distinguish the usage of keys as internal when used within the key exchange, and external when exclusively used outside of the key exchange (e.g., to encrypt application data). In the former case, our model ensures that tested real-or-random keys are accordingly used in subsequent key exchange steps, and pauses the protocol execution to enable testing of those keys. We note that the declaration of whether a key is internal or external is a parameter to the model, and becomes a part of the protocol description and its security guarantees.

Public or pre-shared keys. Our multi-stage model comes in two flavors that capture both the regular, public-key case (abbreviated as pMSKE) of long-term keys being public/secret key pairs (as in the TLS 1.3 full handshake) as well as the pre-shared–secret case (abbreviated sMSKE) case where pre-shared symmetric keys act as long-term secrets (as in the TLS 1.3 resumption handshake).

Replayability. For 0-RTT key establishment, key exchange protocols (including TLS 1.3) regularly give up strong replay protection guarantees, in the sense that client (initiator) messages can be replayed to several server (responder) sessions. We capture this in our model by distinguishing between replayable (0-RTT) and regular non-replayable stages, taking potential replays into account for the former while still requiring key secrecy. Determining the replay type of a stage is again a parameter to the model and must be specified as part of the protocol description resp. the security claim.

We note that former variants of multi-stage key exchange models including [61] further differentiated whether the compromise of some stage’s key affects the security of other stages’ keys under the notion of key (in)dependence. Here, we always demand such compromise never affects other stages’ keys as the desirable goal, i.e., we postulate key independence and reduce the model’s complexity by incorporating this property straight into the model. As we will see, TLS 1.3 always achieves this property due to clean key separation in the key scheduling and already did so in earlier draft versions [38, 39, 53].

Secret Compromise Paradigm We follow the paradigm of the Bellare–Rogaway model [25], focusing on the leakage of long-term secret inputs and session key outputs of the key exchange, but not on internal values within the execution of a session. This contrasts to some extent with the model by Canetti and Krawczyk [33] resp. LaMacchia et al. [79] which include a “session state reveal” resp. “ephemeral secret reveal” query that allows accessing internal variables of the session execution.

In the context of TLS 1.3, this means we consider the leakage of:

• Long-term keys (such as the signing keys of the server or client, but also their pre-shared keys), since long-term values have the potential to be compromised, and this is necessary to model forward secrecy; it is captured in our model by the $\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 Multi-stage 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 pre-shared symmetric keys for authentication. We also do not track whether keys are independent or not, as all keys established in TLS 1.3 satisfy key independence (unlike in the analysis of QUIC in [52]). Key usage (internal versus external) and replayability were introduced to MSKE by [53].

Syntax

In our model, we explicitly separate some protocol-specific properties (as, e.g., various authentication flavors) from session-specific properties (as, e.g., the state of a running session). We represent protocol-specific properties as a vector $(\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 a-priori. 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 i-th entry $(u_{i},m_{i})$ in a vector says that the session key in stage i initially has the default unauthenticated level, i.e., provides no authentication for either communication partner, then at stage $u_{i}$ becomes unilaterally authenticated and thus authenticates only the responder (server), and becomes mutually authenticated to authenticate both communication partners at stage $m_{j}$. Note that we allow for example $u_{i}=i$ (or even $u_{i} = m_{i} = i$) such that the session key is immediately unilaterally (resp. mutually) authenticated when derived. Entries in each pair must be non-decreasing, and $u_{i} = \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 multi-stage 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 stage-i 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 i-th stage is replayable in the sense that an adversary can easily force identical communication and thus identical session identifiers and keys in this stage (e.g., by re-sending the same data in $\text {0-RTT}$ stages). Note that the adversary, however, should still not be able to distinguish such a replayed key from a random one. We remark that, from a security viewpoint, the usage of replayable stages should ideally be limited, although such stages usually come with an efficiency benefit. We use the same shorthand notation as for $\textsf {USE}$; e.g., $\textsf {REPLAY} = (\textsf {nonreplayable} : \{1,2,3\})$ indicates that all three stages are non-replayable.

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 n-th local session of identity U (the session owner) with V as the intended communication partner.

In the public-key variant of the model (pMSKE), each identity U is associated with a certified long-term public key $\textsf {pk} _{U}$ and secret key $\textsf {sk} _{U}$. In the pre-shared secret setting (sMSKE), a session instead holds an identifier $\textsf {pssid} \in \{0,1\}^*$ for the pre-shared secret $\textsf {pss} \in \mathcal {P}$ (from some pre-shared 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 pre-shared secret identifier $\textsf {pssid}$ uniquely identifies the peer identity V it is shared with. (Requiring a fixed role in which a pre-shared key can be used by either peer avoids the Selfie attack [1, 44].)

For each session, a tuple with the following information is maintained as an entry in the session list $\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 j-th entry

• $\textsf {pssid} \in \{0,1\}^* \cup \{\bot \}$: In the pre-shared secret (sMSKE) variant the identifier for the pre-shared 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 i-th 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 0-RTT data from a client, but continuing with the remaining handshake)), and to $\textsf {running} _{i}$ when a session continues after accepting the i-th 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 non-tampered joint execution are partnered in all stages upon acceptance.

Our security model treats corruption of long-term secrets (secret keys for pMSKE, pre-shared secrets for sMSKE). While the effects of such compromises on sessions may differ in each setting, we broadly consider the derived keys of some session to be revealed if, in the public-key setting (pMSKE), the owner or peer secret key is compromised, or in the pre-shared secret setting (sMSKE), if the pre-shared secret used for that session is compromised. Forward secrecy comes into play when determining if keys derived prior to the long-term secret corruption are affected, too. In more precise notation, we say a session $\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 pre-shared 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 per-stage vector in the authentication level matrix. When capturing security, our model however needs to carefully consider the interaction of authentication and corruptions (somewhat similar to what one might be used to for forward secrecy). More precisely, the authentication guarantee of some stage i after its acceptance can only step up (in some later stage $j > i$) if the involved parties are not corrupted by the time stage j accepts. Otherwise, the adversary may have impersonated the party up to the unauthenticated stage i and now post-authenticates as the party after corruption in stage j. This would effectively mean that the adversary has been in full control of the session and may thus know the session key of stage i.

We capture the upgrade by defining the rectified authentication level $\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 i-th session key gets unilaterally and mutually authenticated, with corruption indicator $\textsf {corrupted}$, and with current execution stage $\textsf {stage}$ as follows:

$$\begin{aligned} \textsf {rect\_auth} _{i} := {\left\{ \begin{array}{ll} \textsf {mutual} &{} \text {if } \textsf {stage} \ge \textsf {auth} _{i,2} \text { and } \textsf {corrupted} \ge \textsf {auth} _{i,2} \\ \textsf {unilateral} &{} \text {if } \textsf {stage} \ge \textsf {auth} _{i,1} \text { and } \textsf {corrupted} \ge \textsf {auth} _{i,1} \\ \textsf {unauth} &{} \text {otherwise} \end{array}\right. } \end{aligned}$$

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}$).

Adversary Model

We consider a probabilistic polynomial-time (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 multi-stage key exchange as outlined above. We conveniently capture admissibility of adversarial interactions and conditions where the adversary trivially loses (such as both revealing and testing the session key in partnered sessions) via a flag $\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 pre-shared 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 pre-shared 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 pre-shared secret (sMSKE) variant, the additional parameter $\textsf {pssid}$ identifies the pre-shared 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 long-term keys in a fine-grained 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 later-defined $\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 public-key (pMSKE) variant, the second query only in the pre-shared secret (sMSKE) variant. Provide the adversary with the corresponding long-term 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 pre-shared 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 non-forward-secret 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 stage-j 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 j-th 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 i-th 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 i-th 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.

Security of Multi-Stage Key Exchange Protocols

As in the formalization of the Bellare–Rogaway key exchange model by Brzuska et al. [22, 26], we model security according to two games, one for key indistinguishability, and one for session matching. The former is the classical notion of random-looking keys, refined under the term $\textsf {Multi} \text {-}\textsf {Stage}$ security according to the advanced security aspects for multi-stage key exchange: (stage-j) 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 multi-stage setting.

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 pre-shared secrets, share the same key identifier,

• 6. session identifiers do not match across different stages, and

• 7. at most two sessions have the same session identifier at any non-replayable stage.

The $\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 multi-stage 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 public-key variant (pMSKE), the challenger generates long-term public/ private-key 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}$. (Non-opposite roles of partnered sessions in non-replayable 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 non-replayable 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:

$$\begin{aligned} \textsf {Adv} _{\textsf {KE} ,\mathcal {A}}^{\textsf {Match} } := \Pr \left[ G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Match} } = 1 \right] . \end{aligned}$$

Multi-Stage Security

The second and core notion, $\textsf {Multi} \text {-}\textsf {Stage}$ security, captures Bellare–Rogaway-like key secrecy in the multi-stage setting as follows.

Definition 4.2

($\textsf {Multi} \text {-}\textsf {Stage}$ security) Let $\textsf {KE}$ be a multi-stage 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 public-key variant (pMSKE), it furthermore generates long-term public/private-key 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 non-forward-secrecy versus stage-j 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:

$$\begin{aligned} \textsf {Adv} _{\textsf {KE} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} := \Pr \left[ G_{\textsf {KE} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} = 1 \right] - \frac{1}{2}. \end{aligned}$$

Security Analysis of the TLS 1.3 Full 1-RTT Handshake

We now come to analyzing the TLS 1.3 full 1-RTT handshake in the public-key multi-stage key exchange (pMSKE) model.

Protocol Properties The full handshake targets the following protocol-specific properties $(\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )$:

• $\textsf {M} = 6$: The full 1-RTT 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 1-RTT 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 non-replayable in the full 1-RTT 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 1-RTT 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):

$$\begin{aligned} \textsf {sid} _{1}&= (\text {``CHTS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} ),\\ \textsf {sid} _{2}&= (\text {``SHTS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} ),\\ \textsf {sid} _{3}&= (\text {``CATS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} , \texttt {EE} , \texttt {CR} ^*, \texttt {SCRT} , \texttt {SCV} , \texttt {SF} ),\\ \textsf {sid} _{4}&= (\text {``SATS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} , \texttt {EE} , \texttt {CR} ^*, \texttt {SCRT} , \texttt {SCV} , \texttt {SF} ),\\ \textsf {sid} _{5}&= (\text {``EMS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} , \texttt {EE} , \texttt {CR} ^*, \texttt {SCRT} , \texttt {SCV} , \texttt {SF} ),\\ \textsf {sid} _{6}&= (\text {``RMS''},&~\texttt {CH} , \texttt {CKS} , \texttt {SH} , \texttt {SKS} , \texttt {EE} , \texttt {CR} ^*, \texttt {SCRT} , \texttt {SCV} , \texttt {SF} , \texttt {CCRT} ^*, \texttt {CCV} ^*, \texttt {CF} ). \end{aligned}$$

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.

Match Security

We are now ready to give our formal security results for the TLS 1.3 full 1-RTT handshake, beginning with $\textsf {Match}$ security.

Theorem 5.1

($\textsf {Match}$ security of TLS1.3 -full- 1RTT). The TLS 1.3 full 1-RTT 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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{\textsf {Match} } \le n_{s}^2 \cdot \frac{1}{q} \cdot 2^{-|\text {nonce}|}, \end{aligned}$$

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.3-full-1RTT, The security bound arises as the birthday bound for two honest sessions choosing the same nonce and group element; this not happening ensures at most two partners share the same session identifier.

We need to show the seven properties of $\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 1-RTT handshake). Furthermore, for each stage, the session identifier includes all handshake messages that enter the key derivation: for stages 1 and 2 messages up to $\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 wrong-role 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 1-RTT handshake.

• 3. Sessions with the same session identifier for some stage agree on that stage’s authentication level.

  By definition, the authentication for stages 1–2 and 3–5 are fixed to $\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 1-RTT 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 non-replayable stage.

  Recall that all session identifiers held by some session include that session’s random nonce and Diffie–Hellman share. Therefore, for a threefold collision among session identifiers of honest parties, some session would need to pick the same group element and nonce as one other session (which then may be partnered through a regular protocol run to some third session). The probability for such collision to happen can be bounded from above by the birthday bound $n_{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$

Multi-Stage Security

We now come to the core multi-stage security result for the TLS 1.3 full 1-RTT handshake.

Theorem 5.2

($\textsf {Multi} \text {-}\textsf {Stage}$ security of TLS1.3-full-1RTT). The TLS 1.3 full 1-RTT 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

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} \\&\quad \le 6 n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} } + n_{u}\cdot \textsf {Adv} ^{\textsf {EUF} \text { -}\textsf {CMA} }_{\textsf {SIG} ,\mathcal {B}_{2}}\\ +\, n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{3}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{7}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \end{array} \right) \end{aligned}$$

where $n_{s}$ is the maximum number of sessions and $n_{u}$ is the maximum number of users.

For the TLS 1.3 full 1-RTT handshake, $\textsf {Multi} \text {-}\textsf {Stage}$ security essentially follows from two lines of reasoning. First, the (unforgeable) signatures covering (a collision-resistant 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 complexity-theoretic 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.,

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{0}}. \end{aligned}$$

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 multi-query 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 multi-query attacker are gradually substituted by carefully crafted $\textsf {Reveal}$ queries, where the single-query 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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{0}} \le 6 n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{1}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{1}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{2}} + \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} }. \end{aligned}$$

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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{2},\text { test w/o partner}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.0}}. \end{aligned}$$

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}$:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.0}} \le n_{u}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.1}}. \end{aligned}$$

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 EUF-CMA 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 long-term 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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.1}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.1}} + \textsf {Adv} _{\textsf {SIG} ,\mathcal {B}_{2}}^{\textsf {EUF} \text { -}\textsf {CMA} } \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{A.2}}=0. \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{2},\text { test w/ partner}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.0}}. \end{aligned}$$

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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.0}} \le n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.1}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.1}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.2}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{3}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.2}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.3}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

At this point, $\widetilde{\mathrm {CHTS}}$ and $\widetilde{\mathrm {SHTS}}$ are independent of any values computed in any session non-partnered (in stage 1 or 2) with the tested session: distinct session identifiers and no hash collisions (as of Game $G_{2}$) ensure that the PRF label inputs for deriving $\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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.3}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.4}} + 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.4}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.5}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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 non-partnered 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 non-partnered 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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.5}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.6}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{7}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

We note that in this game we have now replaced all stages’ keys in the tested session with uniformly random values which, in the protocol execution, are independent of values in any non-partnered session to the tested session. Thus:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{B.6}} = 0. \end{aligned}$$

Combining the given single bounds yields the security statement below:

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}}^{G_{2},\text { test w/ partner}} \\&\quad \le n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{3}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} } + 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{7}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \end{aligned}$$

$\square$

Security Analysis of the TLS 1.3 PSK/PSK-(EC)DHE (with Optional 0-RTT) Handshakes

We now turn to analyzing the TLS 1.3 pre-shared key handshakes, with and without Diffie–Hellman key exchange (PSK-(EC)DHE, resp. PSK) and with optional 0-RTT keys, in the pre-shared–secret multi-stage key exchange (sMSKE) model.

Protocol Properties The PSK/PSK-(EC)DHE (0-RTT) handshakes targets the following protocol-specific properties $(\textsf {M} ,\textsf {AUTH} ,\textsf {FS} ,\textsf {USE} ,\textsf {REPLAY} )$:

• $\textsf {M} = 8$: The PSK handshakes with optional 0-RTT consist of eight stages deriving, in order: the early traffic secret $\mathrm {ETS}$ and early exporter master secret $\mathrm {EEMS}$ (both only in 0-RTT 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 (0-RTT) handshakes:

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

  • – for PSK-(EC)DHE (0-RTT), $\textsf {AUTH} = \big \{ ((1,1),(2,2),(5,8),(5,8),(5,8),(6,8),(7,8),(8,8)) \big \}$: The 0-RTT 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 non-0-RTT keys reach unilateral authentication with stage 5 and mutual authentication with stage 8. (It is not straightforward to see why some PSK-(EC)DHE keys are not considered to be immediately mutually authenticated, in contrast to keys from the PSK-only handshake. Consider the handshake traffic keys in the PSK-(EC)DHE handshake: in the model, the adversary $\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 PSK-only, $\textsf {FS} = \infty$: The PSK-only 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–0-RTT 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 0-RTT keys $\mathrm {ETS}$ and $\mathrm {EEMS}$ are replayable, all other stages’ keys are not.

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

$$\begin{aligned} \textsf {sid} _{1}&= (\text {``ETS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} ),\\ \textsf {sid} _{2}&= (\text {``EEMS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} ),\\ \textsf {sid} _{3}&= (\text {``CHTS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} ),\\ \textsf {sid} _{4}&= (\text {``SHTS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} ),\\ \textsf {sid} _{5}&= (\text {``CATS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} , \texttt {EE} , \texttt {SF} ),\\ \textsf {sid} _{6}&= (\text {``SATS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} , \texttt {EE} , \texttt {SF} ),\\ \textsf {sid} _{7}&= (\text {``EMS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} , \texttt {EE} , \texttt {SF} ),\\ \textsf {sid} _{8}&= (\text {``RMS''},&~\texttt {CH} , \texttt {CKS} ^\dagger , \texttt {CPSK} , \texttt {SH} , \texttt {SKS} ^\dagger , \texttt {SPSK} , \texttt {EE} , \texttt {SF} , \texttt {CF} ). \end{aligned}$$

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.

TLS 1.3 PSK-only (0-RTT optional)

We can begin to give our security results for the TLS 1.3 PSK-only $\text {0-RTT}$ handshake. We start with $\textsf {Match}$ security.

Match Security

Theorem 6.1

($\textsf {Match}$ security of TLS1.3-PSK-0RTT). The TLS 1.3 PSK-only 0-RTT 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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Match} } \le \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}}^{\textsf {COLL} } + \frac{n_{p}^2}{|\mathcal {P}|} + n_{s}^2 \cdot 2^{-|\textit{nonce}|}, \end{aligned}$$

where $n_{s}$ is the maximum number of sessions, $n_{p}$ is the maximum number of pre-shared secrets, $|\mathcal {P}|$ is the size of the pre-shared 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.3-full-1RTT, the security bound arises as the birthday bound for two honest sessions choosing the same nonce; this not happening ensures at most two partners share the same session identifier.

Proof

We need to show the seven properties of $\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 pre-shared 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 PSK-only 0-RTT handshake). Furthermore, for each stage, the session identifier includes all handshake messages that enter the key derivation: for stages 1 and  2 messages up to $\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 wrong-role 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-only 0-RTT handshake.

• 3. Sessions with the same session identifier for some stage agree on that stage’s authentication level.

  All stages in the TLS 1.3 PSK-only 0-RTT handshake are mutually authenticated, so this is trivially true.

• 4. Sessions with the same session identifier for some stage share the same contributive identifier.

  This holds due to, for each stage i, the contributive identifier $\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 collision-resistant 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 pre-shared 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 pre-shared secret space and $n_{p}$ the maximum number of pre-shared 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 non-replayable 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$

Multi-Stage Security

Theorem 6.2

($\textsf {Multi} \text {-}\textsf {Stage}$ security of TLS1.3-PSK-0RTT). The TLS 1.3 PSK 0-RTT 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

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} \\&\quad \le 8n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} } + n_{p}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{2}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{3}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, 2\cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{7}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{8}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \end{array} \right) \end{aligned}$$

where $n_{s}$ is the maximum number of sessions, $n_{u}$ is the maximum number of users, and $n_{p}$ is the maximum number of pre-shared secrets.

For the TLS 1.3 PSK 0-RTT handshake, $\textsf {Multi} \text {-}\textsf {Stage}$ security follows from the security of the pre-shared key: all keys are derived from a pre-shared 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.,

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{0}}. \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{0}} \le 8 n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{1}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{1}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2}} + \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} }. \end{aligned}$$

Game 3. In this game, the challenger guesses the pre-shared 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 pre-shared secrets, thus:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2}} \le n_{p}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{3}}. \end{aligned}$$

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 pre-shared 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 pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{3}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{4}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{2}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{4}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{5}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{3}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{5}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{6}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{6}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{7}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{7}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{8}} + 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{8}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{9}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{7}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{9}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{10}} + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{8}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{10}} = 0. \end{aligned}$$

Combining the given single bounds yields the overall security statement. $\square$

TLS 1.3 PSK-(EC)DHE (0-RTT optional)

We can now turn to the security results for the TLS 1.3 PSK-(EC)DHE $\text {0-RTT}$ handshake, starting again with $\textsf {Match}$ security.

Match Security

Theorem 6.3

($\textsf {Match}$ security of TLS1.3-PSK-(EC)DHE-0RTT). The TLS 1.3 PSK-(EC)DHE 0-RTT 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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Match} } \le \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}}^{\textsf {COLL} } + \frac{n_{p}^2}{|\mathcal {P}|} + n_{s}^2 \cdot \frac{1}{q} \cdot 2^{-|\textit{nonce}|}, \end{aligned}$$

where $n_{s}$ is the maximum number of sessions, q is the group order, $n_{p}$ is the maximum number of pre-shared secrets, $|\mathcal {P}|$ is the size of the pre-shared 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 pre-shared 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 pre-shared 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 wrong-role 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 0-RTT 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 pre-shared 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 collision-resistant 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 pre-shared 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 pre-shared secret space and $n_{p}$ the maximum number of pre-shared 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 non-replayable 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$

Multi-Stage Security

Theorem 6.4

($\textsf {Multi} \text {-}\textsf {Stage}$ security of TLS1.3-PSK-(EC)DHE-0RTT). The TLS 1.3 PSK-(EC)DHE 0-RTT 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

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} \\&\quad \le 8 n_{s}\left( \begin{array}{r} \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} } + n_{p}n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{2}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{3}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{7}}^{\textsf {EUF} \text { -}\textsf {CMA} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{8}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{9}}^{\textsf {EUF} \text { -}\textsf {CMA} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{10}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{11}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \\ + n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{12}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{13}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, 2\cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{14}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{15}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{16}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \end{array} \right) \end{aligned}$$

where $n_{s}$ is the maximum number of sessions, $n_{p}$ the maximum number of pre-shared secrets established between any two parties, and $n_{u}$ is the maximum number of users.

For the TLS 1.3 PSK-(EC)DHE 0-RTT handshake, $\textsf {Multi} \text {-}\textsf {Stage}$ security essentially follows from two lines of reasoning. First, the (unforgeable) MAC tags covering (a collision-resistant 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 forward-secret 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 dual-PRF-sec/${\textsf {PRF} \text {-}\textsf {sec} }$ assumptions on the $\textsf {HKDF} .\textsf {Extract}$ and $\textsf {HKDF} .\textsf {Expand}$ steps), and for non-forward-secret stages the keys are derived from a pre-shared 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.,

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{0}}. \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{0}} \le 8 n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{1}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{1}} \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2}} + \textsf {Adv} _{\textsf {H} ,\mathcal {B}_{1}}^{\textsf {COLL} }. \end{aligned}$$

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 non-forward-secret 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 forward-secret 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”):

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2}} \\&\quad \le \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},~\text {test w/o partner}} + \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},~\text {NFS test w/ partner}} \\&\qquad + \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},~\text {FS test w/ partner}}. \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},\text { test w/o partner}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.0}}. \end{aligned}$$

Game A.1. In this game, the challenger guesses the pre-shared 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 pre-shared secrets), thus:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.0}} \le n_{p}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.1}}. \end{aligned}$$

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:

$$\begin{aligned} \Big |\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.1}} - \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.2}}\Big | \le \Pr [\textsf {abort} ^{G_{A.2}, \mathcal {A}}_{acc}] \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{A.2}} = 0. \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.2}, \mathcal {A}}_{acc}] \le n_{s}\cdot \Pr [\textsf {abort} ^{G_{A.3}, \mathcal {A}}_{acc}]. \end{aligned}$$

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 pre-shared 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 pre-shared 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 pre-shared 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 pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.3}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.4}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{2}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.4}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.5}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{3}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.5}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.6}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.6}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.7}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.7}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.8}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{6}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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 stage-8 accepting responder session without a stage-3 contributive partner by:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.8}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{7}}^{{\textsf {EUF} \text {-}\textsf {CMA} }} \end{aligned}$$

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:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.9}, \mathcal {A}}_{acc}] \le \Pr [\textsf {abort} ^{G_{A.10}, \mathcal {A}}_{acc}] + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{8}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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 stage-5 accepting initiator session without a stage-3 contributive identifier by:

$$\begin{aligned} \Pr [\textsf {abort} ^{G_{A.11}, \mathcal {A}}_{acc}] \le \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{9}}^{\textsf {EUF} \text { -}\textsf {CMA} } \end{aligned}$$

Combining the given single bounds yield the security statement below:

$$\begin{aligned}&\textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},\text { test. w/o partner}}\\&\quad \le n_{p}n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{2}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{3}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{4}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{5}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{6}}^{{\textsf {PRF} \text {-}\textsf {sec} }} + \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{7}}^{\textsf {EUF} \text { -}\textsf {CMA} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{8}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HMAC} ,\mathcal {B}_{9}}^{\textsf {EUF} \text { -}\textsf {CMA} } \end{array} \right) \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{2},\text {NFS test with partner}} = \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.0}}. \end{aligned}$$

Game B.1. In this game, we guess the pre-shared 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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.0}} \le n_{p}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.1}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.1}} \le n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.2}}. \end{aligned}$$

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 pre-shared 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 pre-shared secret is an unknown and uniformly random value, and the simulation is sound. Thus:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.2}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.3}}\\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{10}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.3}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {PSK} \text { -}\texttt {(EC)DHE} \text { -}\texttt {0RTT} ,\mathcal {A}}^{G_{B.4}}\\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{11}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{B.4}} = 0. \end{aligned}$$

Combining the given single bounds yields the security statement below:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{2},\text {NFS test with partner}} \le n_{s}n_{p}\big ( \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{10}}^{\textsf {dual} \text { -}\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{11}}^{\textsf {PRF} \text { -}\textsf {sec} }\big ) \end{aligned}$$

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.

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{2},\text {FS test with partner}} = \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.0}}. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.0}} \le n_{s}\cdot \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.1}}. \end{aligned}$$

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 Diffie-Hellman 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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.1}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.2}} \\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{12}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.2}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.3}} \\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{13}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

At this point, $\widetilde{\mathrm {CHTS}}$ and $\widetilde{\mathrm {SHTS}}$ are independent of any values computed in any session non-partnered (in stage 1 or 2) with the tested session: distinct session identifiers and no hash collisions (as of Game $G_{2}$) ensure that the PRF label inputs for deriving $\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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RTT} ,\mathcal {A}}^{G_{C.3}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RTT} ,\mathcal {A}}^{G_{C.4}} \\&+ 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{14}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.4}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.5}} \\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{15}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

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:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.5}}\le & {} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.6}} \\&+ \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{16}}^{\textsf {PRF} \text { -}\textsf {sec} }. \end{aligned}$$

We note that in this game we have now replaced all stages’ keys (with the restriction that the tested stage is from stages 3-8) in the tested session with uniformly random values independent of the protocol execution and thus

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{C.6}} = 0. \end{aligned}$$

Combining the given single bounds yields the security statement below:

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text {-}\texttt {PSK} \text {-}\texttt {(EC)DHE} \text {-}\texttt {0RT} ,\mathcal {A}}^{G_{2},\text {FS test with partner}} \le n_{s}\left( \begin{array}{l} \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathbb {G},\mathcal {B}_{12}}^{\textsf {dual} \text { -}\textsf {snPRF} \text { -}\textsf {ODH} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{13}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, 2 \cdot \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{14}}^{\textsf {PRF} \text { -}\textsf {sec} } + \textsf {Adv} _{\textsf {HKDF} .\textsf {Extract} ,\mathcal {B}_{15}}^{\textsf {PRF} \text { -}\textsf {sec} } \\ +\, \textsf {Adv} _{\textsf {HKDF} .\textsf {Expand} ,\mathcal {B}_{16}}^{\textsf {PRF} \text { -}\textsf {sec} } \end{array} \right) \end{aligned}$$

$\square$

Discussion and Conclusions

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

Technical Differences from Our Earlier Work

As noted in the introduction, this paper is a successor to earlier versions of our work [38, 39, 47, 53, 61]. Here we briefly comment on the technical differences of the analyses of draft-05 in [38], draft-10 and draft-dh in [39], and draft-14 in [53], compared to the final version of TLS 1.3 analyzed in this paper. We focus on three main aspects: the stages identified for the multi-stage analysis, the session identifiers of those stages, and the assumptions used in the security proofs. For the stages and session identifiers, the changes across our series of works are directly related to how the protocol flows and key schedule evolved.

Stages—Main Handshake $\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}$. draft-dh 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}$, draft-dh, $\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 draft-05, 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 symmetric-key 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 multi-stage 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.

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–Rogaway-style key indistinguishability security [25] as noted in [56, 63, 86], which motivated the combined handshake+record layer analysis in the authenticated and confidential channel establishment model of [64]. We confirm that the change in keys for encryption of handshake messages allows keys established during the TLS 1.3 handshake to achieve standard key indistinguishability security.

Key Independence All forms of the TLS 1.3 handshake achieve key independence for all stage keys: one can reveal one stage’s session key without endangering the security of later-stage keys. This follows from the fact that every key exported or used for encryption is a leaf node in the directed graph representing the key schedule in Fig. 2. Beyond making it amenable to generic composition, key independence safeguards the usage of derived keys against inter-protocol effects of security breakdowns. (Some early drafts had less key independence: for example, in draft-05, each exported key was derived directly from the master secret $\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 second-level secrets derived from the main (early/handshake/master) secrets are used solely to derive traffic encryption keys (in case of traffic secrets) or further purposes (resumption and exporting), except for the handshake traffic secrets $\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 multi-stage key exchange sense, while requiring to descend one level further to capture the handshake traffic keys.

A more uniform key schedule could have derived the finished keys in a separate branch from the handshake secret $\mathrm {HS}$, enabling $\mathrm {CHTS}$/$\mathrm {SHTS}$ to become first-order session keys on the same level as all others. This in turn would allow a more uniform interface for composition with arbitrary symmetric-key protocol and possibly better support the treatment of key updates (cf. [60]). While this is only a minor issue for the TLS 1.3 analysis, it turned out to complicate a modular analysis of the TLS 1.3 handshake integration into the QUIC protocol [94] as remarked by Delignat-Lavaud et al. [41].

Including the Session Hash in Signatures and Key Derivation In the TLS 1.3 full handshake, authenticating parties (the server, and sometimes the client) sign (the hash of) all handshake messages up to when the signature is issued (the “session hash”). This is different from TLS 1.2 and earlier, where the server’s signature is only over the client and server random nonces and the server’s ephemeral public key.

As for key derivation, every stage key is derived using a PRF application that includes the hash of all messages exchange up to the point when the stage key is derived.

In our analysis, the session identifier for each stage is set to be the transcript of messages up to that point. Thus, assuming collision resistance of the hash function, different session identifiers result in different keys. (This was the goal of the session hash which was introduced in response to the triple handshake attack [13] on TLS 1.2 and earlier.) The server signing the transcript also facilitates our proofs of the authentication properties in the full handshake.

Furthermore, if output keys are meant to be used as a channel identifier or for channel binding (with the purpose of leveraging the session protection and authentication properties established by TLS in an application-layer protocol), including the session hash is appropriate. While the standardized tls-unique [8] and proposed tls-unique-prf [65] TLS channel binding methods do not use keys directly for binding, the low cost of including the session hash seems worth it in case an application developer decides to use keying material directly for binding.

In the PSK handshake without (EC)DHE, there is no ephemeral shared secret and the master secret is computed as a series of $\textsf {HKDF} .\textsf {Extract}$ computations over a 0-string using the pre-shared key as the key. All sessions sharing the same pre-shared secret then compute the same master secret. However, since derivation of output keys still uses the session hash as context, output keys are unique assuming uniqueness of protocol messages (which is assured for example by unique nonces).

Encryption of Handshake Messages A major design goal of TLS 1.3 was to enhance privacy (against passive adversaries) by encrypting the second part of the handshake (which contains identity certificates) using the initial handshake traffic keys $\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 PSK-only handshake, in the sense that the key exchange would achieve the same security notion without these messages. This is mainly because, in the full handshake, the signatures already authenticate the transcripts, and, in the PSK-only handshake, all keys are derived from the PSK which provides implicit authentication. While $\texttt {Finished}$ messages are not needed to provide implicit authentication in PSK-only handshakes, they would play a role in providing explicit authentication, but our model does not include an explicit authentication property. In the PSK-(EC)DHE handshake, the $\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. MAC-ing) the transcript for authentication as well as in deriving keys via HKDF, TLS 1.3 uses the hash of the current transcript as input; if, e.g., the signature algorithm is a hash-then-sign algorithm, it will then perform an additional hash. From a cryptographic point of view, it would be preferable to insert the full (unhashed) transcript and let the respective signature, MAC, or KDF algorithms opaquely take care of processing this message. For engineering purposes, however, it may be desirable to hash the transcript iteratively, only storing the intermediate values instead of the entire transcript. In our security proof, this upstream hashing introduces the collision-resistant assumption for the hash function (and hence a potential additional source of weaknesses, cf. [15]), which would otherwise be taken care of by the signature, MAC, resp. KDF scheme.

0-RTT Replays and Forward Secrecy Through our analysis, we capture the effects of replays in the cryptographic security sense, most importantly confirming that the replayability of 0-RTT keys has no negative effects on the cryptographic security of subsequently derived keys. From a practical, application-layer perspective, the potential for 0-RTT replays, however, remains a critical design choice in TLS 1.3 and has been subject of controversial discussion (see, e.g., [83]). The TLS 1.3 standard [90, Sect. 8] acknowledges that “TLS does not provide inherent replay protections for 0-RTT data,” and at the same time urges implementations to at least implement a certain basic level of anti-replay protection (like single-use session tickets, $\texttt {ClientHello}$ recording, or freshness checks). The 0-RTT modes of Google’s QUIC protocol and TLS 1.3 spawned a series of academic treatments of 0-RTT key exchange [52, 62, 78] and new designs of forward-secure encryption [30, 59] to achieve forward-secret and non-replayable 0-RTT key exchange [46, 57] and TLS session resumption [6].

Also, from a cryptographic perspective, the Diffie–Hellman-based 0-RTT mode variant offered a higher level of (forward) security as it did not require the client to keep secret state for resumption and hence only server compromises would affect the secrecy of 0-RTT communication [53, 74]. This handshake variant was abandoned with draft-13 in favor of performance and structural simplification.

Open Research Questions

Composition Key exchange protocols would be of limited use if applied in isolation; generally, the derived keys are meant to be deployed in a follow-up (or overall) protocol. Encryption (and authentication) of application data via a (cryptographic) channel protocol is of course a common approach, with the TLS record protocol being a prime example, but other usage in the TLS setting includes exporting of key material or resumption handshakes (via the exporter resp. resumption master secret).

Key exchange protocols secure in the sense of Bellare–Rogaway [25] are indeed amenable to generic secure composition with arbitrary follow-up symmetric protocols as shown by Brzuska et al. [22, 26]. Earlier versions of our work [38, 61] included adaptations of these composition results to the multi-stage setting, demonstrating that stage keys could be safely used in symmetric key protocols. Those results still apply to our current model, when restricted to stage keys that are marked for external use, are non-replayable, and when treating the authentication characteristic as fixed at acceptance time, not upgradable. However, it is not obvious how to translate the notions of upgradable authentication or replayability generically to a symmetric key protocol. Given that our focus is on the TLS 1.3 handshake protocol as an authenticated key exchange protocol, we leave a composition result translating replayability and upgradable authentication to future work.

As part of a composed treatment of the overall TLS 1.3 protocol (i.e., handshake and record layer), a conceptual alternative to our treatment of the handshake could be to consider all keys—including handshake traffic keys—to be external (from the handshake’s perspective), and rely on the record protocol for handshake encryption. This viewpoint is taken especially in analyses based on verified implementations [40] and would, in the computational setting, require an appropriate amalgamation of channel models capturing the bidirectional, multi-key, multiplexed, and streaming nature of the TLS 1.3 record protocol [23, 54, 60, 85, 88].

Post-Quantum Key Exchange While our theorems are mostly generic in terms of cryptographic assumptions, they do directly rely on a Diffie–Hellman assumption in a group. Post-quantum key exchange, however, is usually formulated generically as a key encapsulation mechanism (KEM). If TLS 1.3 is to be extended to support post-quantum or hybrid (i.e., traditional plus post-quantum) key exchange [36], our results on the full 1-RTT and PSK-(EC)DHE modes will need to be revisited in the context of specific post-quantum KEMs or generic properties of KEMs. As we rely on the $\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 IND-CCA KEM. Brendel et al. [16] discuss challenges arising when moving Diffie–Hellman-style key exchanges to the post-quantum setting and Schwabe et al. [93] present a KEM-based alternative to the TLS 1.3 handshake with modified message flow.

Conclusions

In this work, we have updated our prior analyses of the cryptographic security of several draft TLS 1.3 handshakes to the final, standardized version of TLS 1.3 in RFC 8446 [90]. We analyzed the full 1-RTT handshake mode as well as the PSK-based resumption handshake modes, with optional 0-RTT keys, in the reductionist framework of an enhanced multi-stage key exchange security model that captures the various security properties of the several keys derived in TLS 1.3. Our analysis confirmed that the TLS 1.3 handshake follows sound cryptographic design principles and establishes session keys with their desired security properties under standard cryptographic assumptions.

The IETF TLS working group developed TLS 1.3 through a novel, proactively transparent standardization process (cf. [89]) that actively solicited industry and academia alike. In our opinion, this has led to an unprecedented success in having wide-ranging security analyses for a major Internet security protocol prior to its standardization and deployment. While security models or formal method tools can never capture the entirety of real-world threats to such protocols, we believe that, through this process, the boundaries of formal understanding have been pushed to an extent that significantly strengthens confidence in the soundness of TLS 1.3’s design. As such, the TLS 1.3 standardization process exemplifies a commendable paradigm which rightfully is being adopted for standardization processes of other major Internet security protocols, and which we encourage other standards bodies to adopt.

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 multi-query 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 $n-1$ 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 multi-stage 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 1-RTT 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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}_{\mathrm{multi}}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} \le n_{\textsf {Test} }\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}_{\mathrm{single}}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}}. \end{aligned}$$

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 black-box 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 re-encrypt 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 re-encrypt 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 re-encryption 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 stage-2 key), then decrypt m with key $\textsf {simKey} _{2}[\textsf {label} ]$ and re-encrypt 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 stage-1 key), then decrypt m with key $\textsf {simKey} _{1}[\textsf {label} ]$ and re-encrypt 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 re-encrypt 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 re-encrypt 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 t-th $\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 i-th 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 multi-query 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 t-th 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 re-encryption. 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,

$$\begin{aligned} \text {Pr}\left[ b=b_{\textsf {test} }\right]&= \sum _{n_{0}=1}^{n_{\textsf {Test} }} \text {Pr}\left[ b=b_{\textsf {test} }\wedge n=n_{0}\right] \\&= \tfrac{1}{n_{\textsf {Test} }}\cdot \sum _{n_{0}=1}^{n_{\textsf {Test} }} \text {Pr}\left[ b=b_{\textsf {test} }\,|\,n=n_{0}\right] \\&= \tfrac{1}{n_{\textsf {Test} }}\cdot \sum _{n_{0}=1}^{n_{\textsf {Test} }} \Big (\tfrac{1}{2}\cdot \text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=0\wedge n=n_{0}\right] \\&\quad + \tfrac{1}{2}\cdot \big (1-\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=1\wedge n=n_{0}\right] \big )\Big )\\&= \tfrac{1}{2} + \tfrac{1}{n_{\textsf {Test} }}\cdot \sum _{n_{0}=1}^{n_{\textsf {Test} }} \tfrac{1}{2}\cdot \big (\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=0\wedge n=n_{0}\right] \\&\quad -\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=1\wedge n=n_{0}\right] \big ) \end{aligned}$$

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

$$\begin{aligned}&= \tfrac{1}{2} + \tfrac{1}{n_{\textsf {Test} }}\cdot \tfrac{1}{2}\big (\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=0\wedge n=1\right] -\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=1\wedge n=n_{\textsf {Test} }\right] \big )\\&= \tfrac{1}{2} + \tfrac{1}{n_{\textsf {Test} }}\cdot \tfrac{1}{2}\big (\text {Pr}\left[ b=0\,|\,b_{\textsf {test} }=0\wedge n=1\right] -1+\text {Pr}\left[ b=1\,|\,b_{\textsf {test} }=1\wedge n=n_{\textsf {Test} }\right] \big )\\&\ge \tfrac{1}{2}+\tfrac{1}{n_{\textsf {Test} }}\cdot \big ( \text {Pr}\left[ b'=b_{\textsf {test} }'\right] -\tfrac{1}{2}\big ) \end{aligned}$$

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

$$\begin{aligned} \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}_{\mathrm{multi}}'}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}} \le n_{\textsf {Test} }\cdot \textsf {Adv} _{\texttt {TLS1.3} \text { -}\texttt {full} \text { -}\texttt {1RTT} ,\mathcal {A}_{\mathrm{single}}}^{\textsf {Multi} \text {-}\textsf {Stage} ,\mathcal {D}}, \end{aligned}$$

proving the claim of the lemma. $\square$