On the Tight Security of TLS 1.3: Theoretically Sound Cryptographic Parameters for Real-World Deployments

We consider the theoretically sound selection of cryptographic parameters, such as the size of algebraic groups or RSA keys, for TLS 1.3 in practice. While prior works gave security proofs for TLS 1.3, their security loss is quadratic in the total number of sessions across all users, which due to the pervasive use of TLS is huge. Therefore, in order to deploy TLS 1.3 in a theoretically sound way, it would be necessary to compensate this loss with unreasonably large parameters that would be infeasible for practical use at large scale. Hence, while these previous works show that in principle the design of TLS 1.3 is secure in an asymptotic sense, they do not yet provide any useful concrete security guarantees for real-world parameters used in practice. In this work, we provide a new security proof for the cryptographic core of TLS 1.3 in the random oracle model, which reduces the security of TLS 1.3 tightly (that is, with constant security loss) to the (multi-user) security of its building blocks. For some building blocks, such as the symmetric record layer encryption scheme, we can then rely on prior work to establish tight security. For others, such as the RSA-PSS digital signature scheme currently used in TLS 1.3, we obtain at least a linear loss in the number of users, independent of the number of sessions, which is much easier to compensate with reasonable parameters. Our work also shows that by replacing the RSA-PSS scheme with a tightly secure scheme (e.g., in a future TLS version), one can obtain the first fully tightly secure TLS protocol. Our results enable a theoretically sound selection of parameters for TLS 1.3, even in large-scale settings with many users and sessions per user.


Introduction
Provable security and tightness In modern cryptography, a formal security proof is often considered a minimal requirement for newly proposed cryptographic constructions. This holds in particular for rather complex primitives, such as authenticated key exchange protocols like TLS. The most recent version of this protocol, TLS 1.3, is the first to be developed according to this approach.
A security proof for a cryptographic protocol usually shows that an adversary A on the protocol can be efficiently converted into an adversary B solving some conjectured-to-behard computational problem. More precisely, the proof would show that any adversary A running in time t A and having advantage A in breaking the protocol implies an adversary B with running time t B and advantage B in breaking the considered computational problem, such that where is bounded. 1 Following the approach of Bellare and Ristenpart [9,10] to measure concrete security, the terms A /t A and B /t B are called the "work factors" 2 of adversaries A and B, respectively, and the factor is called the "security loss" of the reduction. We say that a security proof is "tight", if is small (e.g., constant).
Concrete security In classical complexity-theoretic cryptography, it is considered sufficient if is asymptotically bounded by a polynomial in the security parameter. However, the concrete security guarantees that we obtain from the proof depend on the concrete loss of the reduction and (conjectured) concrete bounds on B /t B . Thus, in order to obtain meaningful results for the concrete security of cryptosystems, we need to be more precise and make these quantities explicit.
If for a given protocol we have an concrete upper bound A /t A on the work factor of any adversary A, then we can say that the protocol provides "security equivalent to − log 2 ( A /t A ) bits". However, note that these security guarantees depend on the loss of the reduction and a bound on B /t B . More concretely, suppose that we aim for a security level of, say, "128-bit security". That is, we want to achieve − log 2 ( A /t A ) ≥ 128. A security proof providing (1) with some concrete security loss would allow us to achieve this via To this end, we have to make sure that it is reasonable to assume that B /t B is small enough, such that − log 2 ( · B /t B ) ≥ 128. Indeed, we can achieve this by choosing 1 The exact bound on depends on the setting. For instance, in the asymptotic setting, as described below, is bounded by a polynomial. 2 Opposed to Bellare and Ristenpart, we consider the inverse of their work factor just to avoid dividing by 0 in the somewhat artificial case in which = 0. We may assume that t > 0 as the adversary at least needs to read its input. This does not change anything other than we need to consider the negative logarithm for the bit security level.
cryptographic parameters (such as Diffie-Hellman groups or RSA keys) such that indeed it is reasonable to assume that B /t B is sufficiently small. Hence, by making the quantities and B /t B explicit, the concrete security approach enables us to choose cryptographic parameters in a theoretically sound way, such that B /t B is sufficiently small and thus we provably achieve our desired security level.
However, note that if the security loss is "large", then we need to compensate this with a "smaller" B /t B . Of course, we can easily achieve this by simply choosing the cryptographic parameters large enough, but this might significantly impact the computational efficiency of the protocol. In contrast, if the security proof is "tight", then is "small" and we can accordingly use smaller parameters, while still being able to instantiate and deploy our protocol in a theoretically sound way.
Since our focus is on the proof technique for TLS 1.3, we chose to consider this simple view on bit security. Alternatively, Micciancio and Walter [58] recently proposed a formal notion for bit security. They try to overcome paradoxical situations occurring with a simple notion of bit security as discussed above. The paradox there is that sometimes the best possible advantage is actually higher than the advantage against an idealized primitive, which is usually considered for bit security. As an example, they mention pseudorandom generators (PRG) for which it was shown that the best possible attack in distinguishing the PRG from random using an n-bit seed value has advantage 2 −n/2 [30] (i.e., n/2 bits of security), even though the best seed recovery attack (with advantage 2 −n ) does not contradict n-bit security. However, these paradoxical situations mostly occur in the non-uniform setting, in which the adversary receives additional information and thus allows the adversary to gain higher advantages. As the discussion above should serve only for motivation and we do not consider non-uniform adversaries, we believe that the simple, intuitive view on bit security we chose here is sufficient.
Theoretically sound deployment of TLS Due to the lack of tight security proofs for TLS 1.3, we are currently not able to deploy TLS 1.3 in a theoretically sound way with reasonable cryptographic parameters. All current security proofs for different draft versions of TLS 1.3 [31][32][33]37,40] have a loss ≥ n 2 s which is at least quadratic in the total number n s of sessions.
Let us illustrate the practical impact of this security loss. Suppose we want to choose parameters in a theoretically sound way, based on a security proof with this quadratic loss in the total number of sessions. Given that TLS will potentially be used by billions of systems, each running thousands of TLS sessions over time, it seems reasonable to assume at least 2 30 users and 2 15 sessions per user. In this case, we would have n s ≥ 2 45 sessions over the life time of TLS 1.3. This yields a security loss of ≥ n 2 s = 2 90 , i.e., we lose "90 bits of security".
Choosing practical parameters If we now instantiate TLS with parameters that provide "128-bit security" (more precisely, such that it is reasonable to assume that − log 2 ( B /t B ) = 128 for the best possible adversary B on the underlying computational problem), then the existing security proofs guarantee only 128 − 90 = 38 "bits of security" for TLS 1.3, which is very significantly below the desired 128 bits.
The former setting is commonly considered in cryptographic research, but the latter is much more frequently used in practice. Our proof reduces the security of TLS to appropriate multi-user security definitions for the underlying building blocks of TLS 1.3, such as the digital signature scheme, the HMAC and HKDF functions, and the symmetric encryption scheme of the record layer. Further, the proof is under the strong Diffie-Hellman (SDH) [1] assumption in the random oracle model. In contrast, standard-model proofs often require a PRF-ODH-like assumption [43]. However, these assumptions are closely related. Namely, as shown by Brendel et al. [21], PRF-ODH is implied by SDH in the random oracle model (see also [21] for an analysis of various variants of the PRF-ODH assumption). One technical contribution of our work is the observation that using the same two assumptions explicitly in the security proof in combination with modeling the key derivation of TLS 1.3 as multiple random oracles [11], we obtain leverage for a tight security proof. For details on how we use this see below.
Another technical contribution of our work is to identify and define reasonable multiuser definitions for these building blocks, and to show that these are sufficient to yield a tight security proof. These new definitions make it possible to independently analyze the multi-user security of the building blocks of TLS 1.3.
These building blocks can be instantiated as follows.
Symmetric encryption Regarding the symmetric encryption scheme used in TLS 1.3, we can rely on previous work by [13] and [41], who gave tight security proofs for the AES-GCM scheme and also considered the nonce-randomization mechanism adopted in TLS 1.3. HMAC and HKDF For the HMAC and HKDF functions, which are used in TLS 1.3 to perform message authentication and key derivation, we give new proofs of tight multi-user security in the random oracle model. Signature schemes TLS 1.3 specifies four signature schemes, RSA-PSS [26,59], RSA-PKCS #1 v1.5 [48,59], ECDSA [45], and EdDSA [14,46]. Due to the fact that RSA-based public keys are most common in practice, the RSA-based schemes currently have the greatest practical relevance in the context of TLS 1.3. Like previous works on tightly secure authenticated key exchange [4,38], we require existential unforgeability in the multi-user setting with adaptive corruptions. Here, two dimensions are relevant for tightness: (i) the number of signatures issued per user, and (ii) the number of users.
-RSA-PSS is the recommended signature scheme in TLS 1.3. It has a tight security proof in the number of signatures per user [26,47], but not in the number of users. -RSA-PKCS #1 v1.5 also has a tight security proof [42] in the number of signatures per user, but not in the number of users. However, we note that this proof requires to double the size of the modulus, and also that it requires a hash function with "long" output (about half of the size of the modulus), and therefore does not immediately apply to TLS 1.3. -For ECDSA there exists a security proof [35] that considers a weaker "one-signatureper-message" security experiment. While this would be sufficient for our result (because the signatures are computed over random nonces which most likely are unique), their security proof is not tight.
We discuss the issue of non-tightness in the number of users below. In contrast to previously published security proofs, which considered preliminary drafts of TLS 1.3, we consider the final version of TLS 1.3, as specified in RFC 8446. However, the differences are minor, and we believe that the published proofs for TLS 1.3 drafts also apply to the final version without any significant changes. We first focus on giving a tight security proof for the TLS 1.3 handshake. Then, following [40] we show how to generically compose the handshake with a symmetric encryption scheme to obtain security of the full protocol. Since we focus on efficiency of practical deployments, our security proof of TLS 1.3 is in the random oracle model [11].
Features of TLS omitted in the security analysis As common in previous cryptographic security analyses of the TLS protocol [31,33,40,43,55], we consider the "cryptographic core" of TLS 1.3. That is, our analysis only focuses on the TLS 1.3 Full 1-RTT (EC)DHE Handshake and its composition with an arbitrary symmetric key protocol. The full TLS 1.3 standard allows the negotiation of different ciphersuites (i.e., AEAD algorithm and hash algorithm), DH groups, and signature algorithms, but this negotiation is out of scope of our work and we focus on a fixed selection of algorithms. Similarly, we do not consider version negotiation and backward compatibility as, e.g., considered in [17,34]. Instead, we only focus on clients and servers that negotiate TLS 1.3. We also do not consider advanced, optional protocol features, such as abbreviated session resumption based on pre-shared keys (PSK) (with optional (EC)DHE key exchange and 0-RTT, as in e.g., [31,33]). That is, we consider neither PSKs established using TLS nor PSKs established using some out-of-band mechanism. Further, we ignore the TLS 1.3 record layer protocol, which performs transmission of cryptographic messages (handshake messages and encrypted data) on top of the TCP protocol and below the cryptographic protocols used in TLS. Additionally, we omit the alert protocol [65,Sect. 6] and the considerations of extensions, such as post-handshake client authentication [54]. Furthermore, we do not consider ciphersuite downgrade or protocol version rollback attacks as discussed in [44,57,69]. Hence, we abstract the cryptographic core of TLS in essentially the same way as in [31,33,40,43,55]. See for instance [19,28] for a different approach, which analyses a concrete reference implementation of TLS (miTLS) with automated verification tools.
However, as mentioned earlier, we discuss the composition of the TLS 1.3 Full (EC)DHE Handshake with the nonce randomization mechanism of AES-GCM, which could be proven to be tightly secure by Hoang et al. [41] and is a first step toward a tight composition with the actual record protocol.
Achieving tightness using the random oracle model Conceptually, we adopt a technique of Cohn-Gordon et al. [25] to TLS 1.3. The basic idea of the approach is that the random oracle and random self-reducibility of SDH allow us to embed a single SDH challenge into every protocol session simultaneously. The DDH oracle provided by the SDH experiment allows us to guarantee that we are able to recognize a random oracle query that corresponds to a solution of the given SDH instance without tightness loss. A remarkable difference to [25] is that they achieve only a linear tightness loss in the number of users, and show to be optimal for the class of high-efficiency protocols considered there. Previous proofs for different TLS versions suffered from the general difficulty of proving tight security of AKE protocols, such as the "commitment problem" described in [38]. We show that the design of TLS 1.3 allows a tightly secure proof with constant security loss.
Relation to previous non-tight security proofs in the standard model We stress that our result is not a strict improvement over previous security proofs for TLS 1.3 [31,33,40,43,55], in particular not to standard model proofs without random oracles. Rather, our objective is to understand under which exact assumptions a tight security proof, and thus a theoretically sound instantiation with optimal parameters such as group sizes is possible. We show that the random oracle model allows this. Hence, if one is willing to accept the random oracle model as a reasonable heuristic, then one can use optimal parameters. Otherwise, either no theoretically sound deployment is (currently) possible, or larger parameters must be used to overcome the loss.
Tight security of signature schemes in the number of users All signature schemes in TLS have in common that they currently do not have a tight security proof in the number of users. Since all these schemes have unique secret keys in the sense of [5], Bader et al. even showed that they cannot have a tight security proof, at least not with respect to what they called a "simple" reduction.
There are several ways around this issue: 1. We can compensate the loss by choosing larger RSA keys. Note that the security loss is only linear in the number of users. For instance, considering 2 30 users as above, we would lose only "30 bits of security". This might be compensated already with a 4096-bit RSA key, which is already quite common today. Most importantly, due to our modular security proof, this security loss impacts only the signature keys. In contrast, for previous security proofs one would have to increase all cryptographic parameters accordingly (or require a new proof). 2. Alternatively, since the RSA moduli in the public keys of RSA-based signature schemes are independently generated, they do not share any common parameters, such as a common algebraic group as for many tightly secure Diffie-Hellmanbased schemes. On the one hand, this makes a tight security proof very difficult, because there is no common algebraic structure that would allow for, e.g., random self-reducibility. The latter is often used to prove tight security for Diffie-Hellmanbased schemes. On the other hand, one can also view this as a security advantage. The same reason that makes it difficult for us to give a tight security proof in the number of users, namely that there is no common algebraic structure, seems also to make it difficult for an adversary to leverage the availability of more users to perform a more efficient attack than on a single user. Hence, it seems reasonable to assume that tightness in the number of users is not particularly relevant for RSAbased schemes, and therefore we do not have to compensate any security loss. This is an additional assumption, but it would even make it possible to choose optimal parameters, independent of the number of users. 3. Finally, in future revisions of TLS one could include another signature scheme which is tightly secure in both dimensions, such as the efficient scheme recently constructed by [38].
Further related work The design of TLS 1.3 is based on the OPTLS protocol by [56], which, however, does not have a tight security proof. Constructing tightly secure authenticated key exchange protocols has turned out to be a difficult task. The first tightly secure AKE protocols were proposed by [4]. Their constructions do not have practical efficiency and are therefore rather theoretical. Notably, they achieve proofs in the standard model, that is, without random oracles or similar idealizations.
Recently, [38] published the first practical and tightly secure AKE protocol. Their protocol is a three-round variant of the signed Diffie-Hellman protocol, where the additional message is necessary to avoid what is called the "commitment problem" in [38]. Our result also shows implicitly that TLS is "out-of-the-box" able to avoid the commitment problem, without requiring an additional message. Furthermore, [38] describe an efficient digital signature scheme with tight security in the multi-user setting with adaptive corruptions. As already mentioned above, this scheme could also be used in TLS 1.3 in order to achieve a fully tight construction.
[25] constructed extremely efficient AKE protocols, but with security loss that is linear in the number of users. They also showed that this linear loss is unavoidable for many types of protocols.

Concurrent and independent work
In concurrent and independent work, Davis and Günther [27] studied the tight security of the SIGMA protocol [51] and the main TLS 1.3 handshake protocol. Similar to our proof (see Theorem 6) they reduce the security of the TLS 1.3 handshake in the random oracle to the hardness of strong DH assumption (SDH), the collision resistance of the hash function, and the multi-user security of the signature scheme and the PRFs. However, we would like to point out that there are some notable differences between their work and ours: -We use the multi-stage key exchange model from [36], which allows us to show security for all intermediate, internal keys and further secrets derived during the handshake. They use a code-based authenticated key exchange model, which considers mutual authentication and the negotiation of a single key, namely the final session key that is used in the TLS 1.3 record layer. -Our work makes slightly more extensive use of the random oracle model. Concretely, both security proofs need to deal with the fact that the TLS 1.3 key derivation does not bind the DH key to the context used to derive a key in a single function. We resolve this by modeling several functions as random oracles, while Davis and Günther [27] model the functions HKDF.Extract and HKDF.Expand of the HKDF directly as random oracles and are able to circumvent the above problem by using efficient book-keeping in the proof. -Since the multi-stage key exchange model [36] provides a tightly secure composition theorem, we were able to make a first step toward a tight security proof for the composition of the TLS handshake with the TLS record layer by leveraging known security proofs for AES-GCM by [13] and [41].
-Davis and Günther [27] focused only on the tight security of the handshake protocol of TLS 1.3, but provide an extensive evaluation of the concrete security implications of their bounds when instantiated with various amounts of resources. Furthermore, they even give a bound for the strong DH assumption in the generic group model (GGM) and were able to show that SDH is as hard as the discrete logarithm problem in the GGM.
Hence, neither of these two independent works covers the other, both papers make complementary contributions toward understanding the theoretically sound deployment of TLS in practice.
Future work and open problems A notable innovative feature of TLS 1.3 is its 0-RTT mode for low-latency key exchange, which we do not consider in this work. We believe it is an interesting open question to analyze whether tight security can also achieved for the 0-RTT mode. Probably along with full forward security, as considered in [2]. Furthermore, we consider TLS 1.3 "in isolation", that is, independent of other protocol versions that may be provided by a server in parallel in order to maximize compatibility. It is known that this might yields cross-protocol attacks, such as those described in [3,18,44,57]. It would be interesting to see whether (tight) security can also be proven in a model that considers such backwards compatibility issues as, e.g., in [17,34], and which exact impact on tightness this would have, if any. A major challenge in this context is to tame the complexity of the security model and the security proof.

Preliminaries
In this section, we introduce notation used in this paper and recall definitions of fundamental building blocks as well as their corresponding security models.

Notation
We denote the empty string, i.e., the string of length 0, by ε. For strings a and b, we denote the concatenation of these strings by a b. For an integer n ∈ N, we denote the set of integers ranging from 1 to n by [n] := {1, . . . , n}. For a set X = {x 1 , x 2 , . . . }, we use (v i ) i∈X as a shorthand for the tuple (v x 1 , v x 2 , . . . ). We denote the operation of assigning a value y to a variable x by x := y. If S is a finite set, we denote by x $ ← S the operation of sampling a value uniformly at random from set S and assigning it to variable x. If A is an algorithm, we write x := A(y 1 , y 2 , . . . ), in case A is deterministic, to denote that A on inputs y 1 , y 2 , . . . outputs x. In case A is probabilistic, we overload notation and write x $ ← A(y 1 , y 2 , . . . ) to denote that random variable x takes on the value of algorithm A ran on inputs y 1 , y 2 , . . . with fresh random coins. Sometimes we also denote this random variable simply by A(y 1 , y 2 , . . . ).

Advantage Definitions Versus Security Definitions
Due to the real-world focus of this paper, we follow the human-ignorance approach proposed by Rogaway [66,67] for our security definitions and statements. As a consequence, we drop security parameters in all of our syntactical definitions. This way we reflect the algorithms as they are used in practice more appropriately. The humanignorance approach also allows us, e.g., to consider a fixed group opposed to the widely used approach of employing a group generator in the asymptotic security setting. We believe that doing so brings us closer to the actual real-world deployment of the schemes. In terms of wording, we can never refer to any scheme as being "secure" in a formal context. Formally, we only talk about advantages and success probabilities of adversaries.

Definition 1. (Computational Diffie-Hellman Assumption)
Let G be a cyclic group of prime order q, and let g be a generator of G. We denote the advantage of an adversary A against the computational Diffie-Hellman (CDH) assumption by

Definition 2. (Decisional Diffie-Hellman Assumption)
Let G be a cyclic group of prime order q and let g be a generator of G. We denote the advantage of an adversary A against the decisional Diffie-Hellman (DDH) assumption by Following [1], we also consider the strong Diffie-Hellman (SDH) assumption. The SDH problem is essentially the CDH problem except that the adversary has additionally access to a DDH oracle. The DDH oracle outputs 1 on input (g a , g b , g c ) if and only if c = ab mod q. However, we restrict the DDH oracle in the SDH experiment by fixing the first component. Without this restriction, we would consider the gap Diffie-Hellman [63] problem.

Definition 3. (Strong Diffie-Hellman Assumption)
Let G be a cyclic group of prime order q and let g be a generator of G. Further, let DDH(·, ·, ·) denote the oracle that on input g a , g b , g c ∈ G outputs 1 if c = ab mod q and 0 otherwise. We denote the advantage of an adversary A against the strong Diffie-Hellman (SDH) assumption by

Pseudorandom Functions
Informally, a pseudorandom function (PRF) is a keyed function that is indistinguishable from a truly random function. The standard definition only covers the case of a single key (resp. a single user). Bellare et al. introduced the related notion of multi-oracle families [8], which essentially formalizes multi-user security of a PRF. In contrast to the standard definition, the challenger now implements N oracles instead of a single one. The adversary may ask queries of the form (i, x), which translates to a request of an image of x under the ith oracle. Hence, the adversary essentially plays N "standard PRF experiments" in parallel, except that the oracles all answer either uniformly at random or with the actual PRF.
otherwise . where Exp MU−PRF PRF,N (A) is defined above.

Collision-Resistant Hash Functions
A (keyless) hash function H is a deterministic algorithm implementing a function H : D → R such that usually |D| is large (possibly infinite) and |R| is small (finite). Recall the standard notion of collision resistance of a hash function.

Digital Signature Schemes
We recall the standard definition of a digital signature scheme by [39]. 1. SIG.Gen is the randomized key generation algorithm generating a public (verification) key pk and a secret (signing) key sk and takes no input. 2. SIG.Sign(sk, m) is the randomized signing algorithm outputting a signature σ on input message m ∈ M and signing key sk. 3. SIG.Vrfy(pk, m, σ ) is the deterministic verification algorithm outputting either 0 or 1. Correctness We say that a digital signature scheme SIG is correct if for any m ∈ M, and for any (pk, sk) that can be output by SIG.Gen, it holds SIG.Vrfy ( pk, m, SIG.Sign(sk, m)) = 1.

Existential Unforgeability of Signatures
The standard notion of security for digital signature schemes is called existential unforgeability under an adaptive chosen-message attack (EUF-CMA). We recall the standard definition [39] next. where Exp EUF−CMA SIG (A) is defined as before.

Existential Unforgeability of Signatures in a Multi-user Setting
In a "real-world" scenario, the adversary is more likely faced a different challenge than described in Definition 7. Namely, a real-world adversary presumably plays against multiple users at the same time and might even be able to get the secret keys of a subset of these users. In this setting, its challenge is to forge a signature for any of the users that it has no control of (to exclude trivial attacks). To capture this intuition, we additionally consider the multi-user EUF-CMA notion with adaptive corruptions as proposed by [4].
To that end, the single-user notion given in Definition 7 can naturally be upgraded to a multi-user notion with adaptive corruptions as follows. adaptively. The challenger adds i to Q corr and replies sk i to the adversary. We call each user i ∈ Q corr corrupted. 3. Finally, the adversary outputs a tuple (i * , m * , σ * ). The challenger checks whether SIG.Vrfy( pk i * , m * , σ * ) = 1, i * ∈ Q corr and (m * , ·) ∈ Q i * . If all of these conditions hold, the experiment outputs 1 and 0 otherwise. Remark 1. This notion can also be weakened by excluding adaptive corruptions. The resulting experiment is analogous except that queries to the corruption oracle are forbidden.

We denote the advantage of an adversary
The corresponding notions are denoted by MU−EUF−CMA instead of MU−EUF−CMA corr .

HMAC
A prominent deterministic example of a message authentication code (MAC) is HMAC [7,49]. The construction is based on a cryptographic hash function (Sect. 2.5). As we will model HMAC in the remainder mainly as a PRF (e.g., Sect. 5), we do not formally introduce MACs.
Construction Let H be a cryptographic hash function with output length μ and let be κ be the key-length.
where opad and ipad are according to RFC 2104 [49] the bytes 0x5c and 0x36 repeated B-times, respectively, where B is the block size (in bytes) of the underlying hash function. k is padded with 0's to match the block size B. If k should be larger, then it is hashed down to less and then padded to the right length as before.

HKDF Scheme
The core of the TLS 1.3 key derivation [65, Sect. 7.1] is the key derivation function (KDF) HKDF proposed by [52,53] and standardized in RFC 5869 [50]. It follows the extractand-expand [53] paradigm and is based on HMAC (Sect. 2.7). The algorithm consists of two subroutines HKDF.Extract and HKDF.Expand. The function HKDF.Extract is a randomness extractor [61,62] that on input a (non-secret and possibly fixed) extractor salt xts and a (not necessarily uniformly distributed) source key material skm outputs a pseudorandom key prk. The function HKDF.Expand is a variable output length PRF that on input prk, (potentially empty) context information ctx and length parameter L outputs a pseudorandom key km of length L.
Construction Intuitively, HKDF derives a pseudorandom key (i.e., indistinguishable from a uniformly sampled key) from some source key material and then stretches this pseudorandom key to the desired length. Formally, we have the following construction. K (ω) is simply truncated to the first (L mod μ) bits to fit the length of L.
We overload notation to denote by HKDF.Expand(prk, ctx) the function described above for a fixed length parameter L that is clear from the context. The function HKDF then is just a shorthand for the execution of HKDF.Extract and HKDF.Expand in sequence. That is, on input (xts, skm, ctx, L) it computes prk := HKDF.Extract(xts, skm) and outputs km with km := HKDF.Expand(prk, ctx, L).

Multi-stage Key Exchange
In this section, we recall the security model of multi-stage key exchange (MSKE) protocols. The model was introduced by [36] and extended in subsequent work [31,33,37,40]. In this paper, we adapt the version presented in [40] almost verbatim apart from the changes discussed in the paragraph below.
Following [40], we describe the MSKE model by specifying protocol-specific (Sect. 3.1) and session-specific (Sect. 3.2) properties of MSKE protocols as well as the adversary model (Sect. 3.3). However, before we start giving the actual model, let us discuss the choice in favor of this model followed by our adaptations to the model.
On the choice of MSKE The most commonly used game-based model for authenticated key exchange goes back to Bellare and Rogaway (BR) [12]. In the context of TLS, it has served as the foundation for the Authenticated and Confidential Channel Establishment (ACCE) model introduced by Jager et al. [43] used for the analyses of TLS 1.2 [43,55], and also the MSKE model initially introduced for analyzing QUIC [36] and later adapted for analyses for TLS 1.3 [31,33,37]. The ACCE model was tailored specifically for the application to TLS 1.2 as it does not allow for a modular analysis due to interleaving of the handshake protocol and record layer. This is because of the established record layer key being already used in the handshake protocol. In TLS 1.3, this was solved by using a dedicated handshake traffic key for the encryption of handshake messages (see Fig. 1) and thus a monolithic model as ACCE is no longer necessary. However, this change introduces another issue. Namely, we now have not only a single key that the communicating parties agree on after the execution of the AKE protocol, but multiple keys being used outside or inside of the protocol. Protocols structured like this motivated Fischlin and Günther (FG) to upgrade the BR model to the MSKE model. Besides the MSKE model, Chen et al. [24] recently proposed a similar ACCE-style model taking into account multiple stages.
We prefer the FG model for an analysis of TLS 1.3 as it is the state-of-the-art security model for TLS 1.3 that is well studied and is already widely used. Most importantly, the model played a major role in the analysis of the Handshake candidates in the standardization process of TLS 1.3. Therefore, using the model in this paper provides the best comparability to previous results on the TLS 1.3 Handshake Protocol. Furthermore, it allows for a modular analysis, i.e., considering the security of the Handshake Protocol and Record Layer in separation. Fischlin and Günther also provide a composition theorem for MSKE protocols (see Sect. 7) allowing for a more general combination with other protocols compared to an ACCE-style model, which only captures secure combination with a encryption protocol.
Indeed, this theorem is very powerful as it allows to argue secure composition with various symmetric key protocol instances. For instance, in the case of the TLS 1.3 Full Handshake the parties exchange an application traffic key to be used in the TLS 1.3 Record Layer, a resumption master secret to be used for deriving a pre-shared key for later session resumption and an exporter master secret to be used as generic keying material exporters [64]. Therefore, the composition theorem allows us to guarantee secure use of all of these keys in their respective symmetric protocols (provided the protocols are secure on their own with respect to some well-defined security notion). In particular, this means that we even have security for a cascading execution of a TLS 1.3 Full Handshake followed by abbreviated PSK Handshakes. For details on the protocol and the composition theorem, see Sects. 4 and 7, respectively.
Changes to the model compared to [40] We only consider the public-key variant of this model, i.e., we exclude pre-shared keys entirely in our model. Since this paper considers TLS 1.3, which does not use semi-static keys in its final version, we also remove these from the original model for simplicity. Further, in the full (EC)DHE TLS 1.3 handshake (Sect. 4) considered in this paper, every stage is non-replayable. To that end, we remove the property REPLAY from the protocol-specific properties defined in Sect. 3.1. Moreover, TLS 1.3 provides key independence. Therefore, we also remove key-dependent security from the model. Finally, we fix the key distribution D to be the uniform distribution on {0, 1} ν for some key length ν ∈ N.

Protocol-Specific Properties
The protocol-specific properties of a MSKE protocol are described by a vector (M, AUTH, USE) described next. In this section, we consider the properties of the model in general and discuss their concrete instantiation for TLS 1.3 in Sect. 4.3.
-M ∈ N is the number of stages the protocol is divided in. This also defines the number of keys derived during the protocol run. -AUTH ⊆ {unauth, unilateral, mutual} M is the set of supported authentication types of the MSKE protocol. An element auth ∈ AUTH describes the mode of authentication for each stage of the key exchange protocol. A stage (resp. the key derived in that stage) is unauthenticated if it provides no authentication of either communication partner, unilaterally authenticated if it only requires authentication by the responder (server), and mutually authenticated if both communication partners are authenticated during the stage. -USE ∈ {internal, external} M is the vector describing how derived keys are used in the protocol such that an element USE i indicates how the key derived in stage i is used. An internal key is used within the key exchange protocol and might also be used outside of it. In contrast, an external key must not be used within the protocol, which makes them amenable to the usage in a protocol used in combination with the key exchange protocol (e.g., symmetric key encryption; see also Sect. 7).

Session-Specific Properties
We consider a set of users U representing the participants in the system and each user is identified by some U ∈ U. Each user maintains a number of (local) sessions of the protocol, which are identified (in the model) by a unique label lbl ∈ U × U × N, where lbl = (U, V, k) indicates the k-th session of user U (session owner) with intended communication partner V . Each user U ∈ U has a long-term key pair (pk U , sk U ), where pk U is certified. Also, we maintain a state for each session. Each state is an entry of the session list SList and contains the following information: is the identity of the intended communication partner, where the value pid = * (wildcard) stands for "unknown identity" and can be set to an identity once during the protocol. -role ∈ {initiator, responder} is the session owner's role in this session.
auth ∈ AUTH is the intended authentication type for the stages, which is an element of the protocol-specific supported authentication types AUTH.
With the aid of this variable, the experiment keeps track whether a session can be tested. Namely, a session can only be tested when it just accepted a key and has not used it in the following stage (see Sect. 3.3, Test). Therefore, we set it to one of the following three states: It is set to accepted i as soon as a session accepts the i-th key (i.e., it can be tested), to rejected i after rejecting the i-th key, 5  tested ∈ {true, false} M is the indicator for tested keys. An element tested i indicates whether key i was already tested by the adversary. The default value is false.
Shorthands We use shorthands, like lbl.sid, to denote, e.g., the list of session identifiers sid of the entry of SList, which is uniquely defined by label lbl. Further, we write lbl ∈ SList if there is a (unique) tuple (lbl, . . . ) ∈ SList.
Partnering Following [40], we say that two distinct sessions lbl and lbl are partnered if both sessions hold the same session identifier, i.e., lbl.sid = lbl .sid = ⊥. For correctness, we require that two sessions having a non-tampered joint execution are partnered upon acceptance. This means, we consider a MSKE protocol to be correct if, in the absence of an adversary (resp. an adversary that faithfully forwards every message), two sessions running a protocol instance hold the same session identifiers, i.e., they are partnered, upon acceptance.

Adversary Model
We consider an adversary A that has control over the whole communication network. In particular, that is able to intercept, inject, and drop messages sent between sessions.
To model these functionalities, we allow the adversary (as in [40]) to interact with the protocol via the following oracles: -NewSession(U, V, role, auth): Create a new session with a unique new label lbl for session owner id = U with role role, intended partner pid = V (might be V = * for "partner unknown"), preferring authentication type auth ∈ AUTH. Add (lbl, U, V, role, auth) (remaining state information set to default values) to SList and return lbl. Whenever the state of execution changes to accepted i for some stage i in response to a Send-query, the protocol execution is immediately suspended. This enables the adversary to test the computed key of that stage before it is used in the computation of the response. Using the special Send(lbl, continue)query the adversary can resume a suspended session. If in response to such a query the state of execution changes to lbl.st exec = accepted i for some stage i and there is an entry for a partnered session lbl ∈ SList with lbl = lbl such that lbl .st key,i = revealed, then we set lbl.st key,i := revealed as well. 6 If in response to such a query the state of execution changes to lbl.st exec = accepted i for some stage i and there is an entry for a partnered session lbl ∈ SList with lbl = lbl such that lbl .tested i = true, then set lbl. For stagej forward secrecy, we set st key,i := revealed for each session lbl with lbl.id = U or lbl.pid = U and for all i < j or i > lbl.stage. Intuitively, after corruption of user U , we cannot be sure anymore that keys of any stage before stage j as well as keys established in future stages have not been disclosed to the adversary. Therefore, these are considered revealed and we cannot guarantee security for these anymore. In case lbl ∈ SList or lbl.st exec = accepted i or lbl.tested i = true, return ⊥. To make sure that key i has not been used until this query occurs, we set lost := true if there is a partnered session lbl of lbl in SList such that lbl .st exec = accepted i . This also implies that a key can only be tested once (after reaching an accepting state and before resumption of the execution). We shall only allow the adversary to test a responder session in absence of mutual authentication if this session has an honest (i.e., controlled by the experiment) contributive partner. Otherwise, we would allow the adversary to trivially win the test challenge. Formally, if lbl.auth i = unauth, or lbl.auth i = unilateral and lbl.role = responder, but there is no session lbl ∈ SList with lbl = lbl and lbl.cid = lbl .cid, then set lost := true. If the adversary made a valid Test-query, set lbl.tested i := true. In case b Test = 0, sample a key K $ ← {0, 1} ν uniformly at random from the session key distribution. 7 In case b Test = 1, set K := lbl.key i to be the real session key. If the tested key is an internal key, i.e., USE i = internal, set lbl.key i := K . This means, if the adversary gets a random key in response, we substitute the established key by this random key for consistency within the protocol. Finally, we need to handle partnered session. If there is a partnered session lbl in SList such that lbl.st exec = lbl .st exec = accepted i , i.e., which also just accepted the i-th key, we also set lbl .tested i := true. We also need to update the state of lbl in case the established key in stage i is internal. Formally, if USE i = internal then set lbl .key i := lbl.key i . Therefore, we ensured consistent behavior in the further execution of the protocol. Return K to the adversary.

Security Definition
The security definition of multi-stage key exchange as proposed in [37,40] is twofold. On the one hand, we consider an experiment for session matching already used by [23]. In essence, this captures that the specified session identifiers (sid in the model) match in partnered sessions. This is necessary to ensure soundness of the protocol. On the other hand, we consider an experiment to capture classical key indistinguishability transferred into the multi-stage setting. This includes the goals of key independence, stagej forward secrecy and different modes of authentication.

Session Matching
The notion of Match-security according to [40] captures the following properties: 1. Same session identifier for some stage ⇒ Same key at that stage. 2. Same session identifier for some stage ⇒ Agreement on that stage's authentication level. 3. Same session identifier for some stage ⇒ Same contributive identifier at that stage. 4. Sessions are partnered with the indented (authenticated) participant. 5. Session identifiers do not match across different stages. 6. At most two session have the same session identifier at any (non-replayable) stage. where Exp Match KE (A) denotes the experiment described above.

Multi-Stage Key Secrecy
Now, to capture the actual key secrecy, we describe the multi-stage key exchange security experiment. Again, this is adapted from [40].  where Exp MSKE KE (A) denotes the experiment described above.
Remark 2. Note that the winning condition is independent of the required security goals. Key independence, stagej forward secrecy and authentication properties are defined by the oracles described in Sect. 3.3.

TLS 1.3 Full (EC)DHE Handshake
In this section, we describe the cryptographic core of the final version of TLS 1.3 standardized as RFC 8446 [65]. In our view, we do not consider any negotiation of cryptographic parameters. Instead, we consider the cipher suite (AEAD and hash algorithm), the DH group and the signature scheme to be fixed once and for all. In the following, we denote the AEAD scheme by AEAD, the hash algorithm by H, the DH group by G and the signature scheme by SIG. The output length of the hash function H is denoted by μ ∈ N and the prime order of the group G by p. The functions HKDF.Extract and HKDF.Expand used in the TLS 1.3 handshake are as defined in Sect. 2.8. 8 Further, we do not consider the session resumption or 0-RTT modes of TLS 1.3.

Protocol Description
The full TLS 1.3 (EC)DHE Handshake Protocol is depicted in Fig. 1.
In the following, we describe the messages exchanged during the handshake in detail. We use the terminology used in the specification RFC 8446 [65]. For further detail we also refer to this specification. Subsequently, we discuss our abstraction of the TLS 1.3 key schedule.
ClientHello (CH): The ClientHello message is the first message of the TLS 1.3 Handshake and is used by a client to initiate the protocol with a server. The message itself consists of five fields. For our analysis the only important one is random, which is the random nonce chosen by the client, consisting of a 32-byte value r C . The remaining values are mostly for backwards compatibility, which is irrelevant for our analysis as we only consider the negotiation of TLS 1.3. There also is a value for the supported ciphersuites of the client, which we omit since we consider the ciphersuite to be fixed once and for all. 8 The context information ctx, i.e., the second parameter of HKDF.Expand is also represented differently in the specification. It just adds constant overhead to the labels which does not harm security and including them would make our view even more complicated. For details, we refer the reader to the TLS 1.3 specification [65]. There are various extensions added to this message. For our view only the key_share extension is important. We denote this as a separate message called ClientKeyShare described next. ClientKeyShare (CKS): The key_share extension of the ClientHello message consists of the public DHE value X chosen by the client. It is defined as ← Z p is the client's private DHE exponent and g the generator of the considered group G. It only contains a single key share as we only consider a single group, which is fixed once and for all before the execution of the protocol. ServerHello (SH): In response to the ClientHello the server sends the ServerHello. This message is structured similarly to the ClientHello message. Again, in our view only the random field is of importance. Here, we denote the 32-byte random value chosen by the server by r S . Similar to the ClientHello message there are various extensions added to this message. We only consider the key_share extension, which we denote as a separate message ServerKeyShare described next. ServerKeyShare (SKS) This message consists of the server's public DHE value Y chosen by the server. It is defined as Y := g y , where y $ ← Z p is the server's private DHE exponent and g the generator of G.
After this message is computed, the server is ready to compute the handshake traffic key htk. To that end, the server first computes the exchanged DHE key Z := X y , where X is the client's public DHE value sent in the ClientKeyShare message. Using Z and the handshake messages computed and received so far, i.e., CH, CKS, SH, SKS, it computes the handshake secret hs, the client handshake traffic secret hts C and the server handshake traffic secret hts S . In our abstraction this is done by evaluating the function F 1 defined in Fig. 2, where hs is only computed internally. Formally, hts C hts S := F 1 (Z , CH CKS SH SKS).
Based on the handshake traffic secrets hts C and htk S the server derives the handshake traffic key htk := KDF(hts C hts S , ε).
The definition of KDF is given in Fig. 3. In essence, it summarizes the traffic key derivation in the way that encryption key and initialization vector (IV) are now abstracted into a single key and also combines the derivation for both parties into a single function call.
The function KDF is not described in the specification [65]. We introduce this function to tame the complexity of our security proof. 9 We discuss the security of KDF in Sect. 5.3.
Upon receiving (SH, SKS), the client performs the same computations to derive htk except that it computes the DHE key as Z := Y x .  All following messages sent from now on are encrypted under the handshake traffic key htk using AEAD. For the direction "server → client", we use the server handshake traffic key htk S and for the opposite direction, we use the client handshake traffic key htk C .
EncryptedExtensions (EE): This message contains all extensions that are not required to determine the cryptographic parameters. In previous versions, these extensions were sent in the plain. In TLS 1.3, these extensions are encrypted under the server handshake traffic key htk S . CertificateRequest (CR): The CertificateRequest message is a contextdependent message that may be sent by the server. The server sends this message when it desires client authentication via a certificate. ServerCertificate (SCRT): This context dependent message consists of the actual certificate of the server used for authentication against the client. Since we do not consider any PKI, we view this message as some certificate 10 that contains some server identity S and a public key pk S appropriate for the signature scheme. ServerCertificateVerify (SCV): To provide a "proof" that the server sending the ServerCertificate message really is in possession of the private key sk S corresponding to the announced public key pk S , it sends a signature σ S $ ← SIG.Sign(sk S , SCV H 1 ) over the hash H 1 of the messages sent and received so far, i.e., This message is only sent when the ServerCertificate message was sent. Recall that every message marked with * is an optional or context-dependent message. Upon receiving (and after decryption) of (EE, CR * , SCRT * , SCV * ), the client first checks whether the signature and MAC contained in the ServerCertificateVerify message and ServerFinished message, respectively, are valid. To that end, it retrieves the server's public key from the ServerCertificate message (if present), derives the server finished key based on hts S , and recomputes the hashes H 1 and H 2 with the messages it has computed and received. The client aborts the protocol if either of the message are not sound. Provided the client does not abort, it prepares the following messages.

ClientCertificate (CCRT):
This message is context-dependent and is only sent by the client in response to a CertificateRequest message, i.e., if the server demands client authentication. The message is structured analogously to the ServerCertificate message except that it contains a client identity C and an appropriate public key pk C . Upon receiving (and after decryption) of (CCRT * , CCV * , CF), the server first checks whether the signature and MAC contained in the ClientCertificateVerify message and ClientFinished message, respectively, are valid. To that end, it retrieves the client's public key from the ClientCertificate message (if present), derives the client finished key based on hts C , and recomputes the hashes H 3 and H 4 with the messages it received. If one of the checks fails, the server aborts. Otherwise, client and server are ready to derive the application traffic key atk, which is used in the TLS Record Protocol. They first derive the master secret ms from the handshake secret hs derived earlier. Based on ms and the handshake transcript up to the ServerFinished message, client and server derive the client application traffic secret ats C and server application traffic secret ats S , respectively. In our abstraction, ats C and ats S are computed by evaluating the function F 2 defined in Fig. 2, i.e., ats C ats S := F 2 (Z , CH · · · SF) where ms again is computed internally. Using ats C and ats S , they finally can derive the application traffic key atk := KDF(ats C ats S , ε), where KDF (Fig. 3) is the same function used in the derivation of htk.
After having derived atk, they derive the exporter master secret ems from the master secret derived earlier and the handshake transcript up to the ServerFinished message. In our abstraction, they evaluate the function F 3 defined in Fig. 2, i.e., ems := F 3 (Z , CH · · · SF).
Finally, they derive resumption master secret rms from the master secret derived earlier and the handshake transcript up to the ClientFinished message. In our abstraction, they evaluate the function F 4 defined in Fig. 2, i.e., rms := F 4 (Z , CH · · · CF).

On Our Abstraction of the TLS 1.3 Key Schedule
In our presentation of the TLS 1.3 Handshake Protocol, we decompose the TLS 1.3 Key Schedule [65, Sect. 7.1] into independent key derivation steps. The main reason for this abstraction is a technical detail of the proof presented in Sect. 6, but also the nature of the MSKE security model requires a key derivation in stages to enable testing the stage keys before possible internal usage of them. Therefore, we introduce a dedicated function for every stage key derivation. These functions are F 1 , F 2 , F 3 and F 4 defined in Fig. 2. Considering the definition of these functions, they seem quite redundant as values, like the handshake secret hs, are computed multiple times. We stress that this is only conceptual and does not change the implementation of the original TLS 1.3 Handshake Protocol. When running the protocol, these values of course can be cached and reused in following computations. We need this modularized key derivation as we will model each of these derivation steps as a random oracle in our proof. For completeness, we give the TLS 1.3 Key Schedule as it is defined in the standard in Fig. 4. Our decomposition essentially consists of viewing the derivations of hts C /hts S , ats C /ats S , ems and rms as separate functions based on the DHE key Z and the transcript. The hash values are defined as H hts = H(CH · · · SKS), H ats = H ems = H(CH · · · SF), and H rms = H(CH · · · CF). In this picture, we use the notation v 1 /v 2 to denote alternative usage of v 1 and v 2 in analogous computations .

TLS 1.3 Handshake Protocol as a Multi-stage Key Exchange Protocol
In this section, we model the TLS 1.3 Handshake as presented before as a multi-stage key exchange protocol. In particular, this means to define the protocol-specific properties as given in Sect. 3.1 and to describe how, e.g., session and contributive identifiers, are defined. We follow [40] and adapt it to the current version of TLS 1.3 given in [65]. The handshake traffic key derived in stage 1 is always unauthenticated. The keys derived in stages 2-4 can all either be unauthenticated, server-only, or mutually authenticated. Note that our result given in Theorem 6 covers all of these authentication types. 3. USE = (internal, external, external, external): The handshake traffic key is used internally during the handshake, whereas all the other keys derived are only used outside the full handshake.

Protocol-Specific Properties
We define the session identifiers for each stage (analogously to [40]) as follows: Note that each message marked with * is context dependent and might not be present, e.g., depending on the used authentication types. Further, we set cid 1 := (CH, CKS) after the client sends (resp. the server receives) these messages. After the server sent its ServerHello message (resp. the client receives it), we extend cid 1 := (CH, CKS, SH, SKS) = sid 1 . The contributive identifiers for stage 2-4 are set by each party after sending its respective finished message to cid i := sid 1 .

Match-Security of TLS 1.3 Handshake
The proof of Match-security of the TLS 1.3 Handshake Protocol as described above basically follows along the lines of the proof given by [ where n s is the maximum number of sessions, p is the order of G used in the handshake and λ = 256 is the bit-length of the nonces.
Intuitively, this bound is the probability that there are two sessions that choose the same nonce and the same key share.
Proof. In order to prove this statement, we need to show each of the properties stated in Definition 9.
1. Same session identifier for some stage ⇒ same key at that stage: For stage 1, we have that the session identifier sid 1 uniquely defines the ephemeral DH key Z , as it contains the public DH values contained in CKS and SKS, respectively. Further, Z and all messages contained in sid 1 , i.e., (CH, CKS, SH, SKS), uniquely define the values hs, hts C and hts S . The values hts C and hts S , in turn, uniquely define the stage-1 key htk. For the remaining stage, first note that sid 2 completely contains sid 1 . As sid 2 is completely contained in sid 3 and sid 4 , sid 1 is also contained in sid 3 and sid 4 . The key derivation in stages 2-4 (i.e., the derivation of atk, ems and rms) solely depends on ms and the messages contained in sid 2 . As sid 2 contains sid 1 , the parties compute the same hs, hts C and hts S (see above). The handshake secret hs uniquely defines the value ms. Then, hts C and hts S define the server's and client's finished keys. Using these keys and the messages contained in sid 2 the (valid) messages SF and CF (depending on SF) are uniquely defined. Finally, taking all this together the computations of atk, ems and rms are uniquely defined by sid 2 . 2. Same session identifier for some stage ⇒ agreement on that stage's authentication level: The first stage is always authenticated. Therefore, auth i = unauth for all sessions. For stages 2-4, recall that sid 2 is contained completely in sid 3 and sid 4 . Moreover, recall that sid 2 contains each handshake message exchanged apart from the finished messages, which are defined by the messages contained in sid 2 . Therefore, sid 2 reflects the used authentication types by the presence of the context-dependent messages. That is, if sid 2 = (CH, CKS, SH, SKS, EE) then auth 2 = unauth. If in addition the message SCRT * , SCV * are present in sid 2 , we have auth 2 = unilateral. While we have auth 2 = mutual if the messages CR * , SCRT * , SCV * , CCRT * , CCV * are in addition present. Finally, observe that auth 2 = auth 3 = auth 4 holds for every session. 3. Same session identifier for some stage ⇒ same contributive identifier at that stage: This is given by definition of the contributive identifier. First, note that sid 1 is contained in the session identifier of every stage. The contributive identifier, for each stage, is set to sid 1 once it is set and never changed.

Sessions are partnered with the indented (authenticated) participant: This can
only be achieved in unilaterally or mutually authenticated stages. This means, this can only be given for stages 2-4. The sessions will obtain the partner identity in a certificate message. That is, in case of unilateral and mutual authentication the client will get the server's identity in the SCRT message. While the server will get the client's identity in the CCRT message in case of mutual authentication.
Certificates always belong to a party that are considered honest and honest parties never send certificates that belong to another identity. As sid 2 (contained in sid 3 and sid 4 ) contains both certificate message (if present), agreement on sid 2 implies partner agreement as well. 5. Session identifiers do not match across different stages: This holds trivially. sid 2 contains strictly less values than sid 1 and both sid 3 and sid 4 contain a dedicated unique label. 6. At most two session have the same session identifier at any stage: We analyze the probability that there are three sessions sharing the same identifier. To that end, assume there is a client (initiator) session and a server (responder) session holding the same session identifier for each stage. Due to the certificates included, there only can exist a session of either the client's or the server's party. Note that the sid 1 is contained in every other stages' session identifier and sid 1 defines the other messages contained in the other identifiers (apart from the unique labels and the certificates). The third session therefore needs to sample the same group element and the same nonce as one of the other two sessions. The probability that this happens is bounded from above by which is the probability that both group element and nonces collide for any two sessions out of n s , where n s is the maximum number of sessions.

Tight Security of TLS 1.3 PRFs
In this section, we consider the tight security of the PRFs used in TLS 1.3. However, the proof can simply be extended by the case κ > B by adding another step.

Tight Security of HMAC
Proof. We prove this statement in a sequence of games [68]. Let break δ denote the event that A wins in Game δ, i.e., Game δ outputs 1, and let Adv δ := Pr[break δ ] − 1/2.  Hence, Adv 0 ≤ Adv 1 + N 2 /2 κ . Note that if the game is not aborted due to this rule, we have that the strings k i ⊕ ipad and k i ⊕ opad are distinct for every i ∈ [N ]. Thus, in case the challenge bit is b = 0, i.e., the oracle is the real PRF, there are no two queries (i, x) and ( j, x) with i = j to oracle O b such that the challenger uses the same prefix k i ⊕ opad = k j ⊕ opad in the computation of the respective oracle responses The same applies to the prefix of the internal random oracle call.
Game 2 This game is identical to Game 1, except that we add another abort rule. If during the execution of the security experiment the random oracle is ever queried with h = h such that H(h) = H(h ), we raise the event abort coll . Since Game 1 and Game 2 are identical until abort coll occurs, we have Due to the birthday bound, the probability that a collision in the random oracle occurs is upper bounded by q 2 H · 2 −μ , where q H is the number of queries to the random oracle and μ is the output length of the random oracle. Therefore, This modification ensures that, in case b = 0, there are no two queries (i, x) and (i, x ) with x = x to oracle O b such that the responses are computed using i.e., the inner evaluation of the random oracle collide. Otherwise, the responses would also collide as the random oracle needs to ensure consistency.
Game 3 This game is identical to Game 2, except that we add another abort rule. Namely, we want to ensure that the adversary for any i ∈ [N ] never queries the random oracle for the string pre y such that pre = k i ⊕opad or pre = k i ⊕ipad, and y ∈ {0, 1} * . To that end, we raise the event abort guess if the adversary makes such a query. Since Game 2 and Game 3 are identical until abort guess occurs, we have To analyze abort guess , let abort guess;i be the same event as abort guess except that we only consider user i. Hence, The main consequence of this modification is that the adversary is not able to query the random oracle with a bit string that at some point may be queried by the challenger in case b = 0 to compute a response to any query O b (i, x) as otherwise the game would be aborted. However, Games 2 and 3 also remove the side channel of the adversary to successfully guess a key for some user i ∈ [N ] and compare the outputs of the random oracle and the oracle O b to win the game.
If Game 3 is not aborted due to abort guess , we claim that Adv 3 = 0. To show this, we argue that the answer of the oracle O b adversary A is provided with in Exp MU−PRF HMAC,N (A) is distributed uniformly at random on {0, 1} μ independent of the challenge bit b. To that end, it suffices to argue that this holds in case b = 0. In case b = 1, this is true by definition.
Games 1, 2 and 3 make sure that every computation of the oracle O 0 is done by a fresh random oracle query, i.e., the query was neither issued by the adversary nor by the challenger at any point in time before this query. Consequently, every response of O 0 is a bit string sampled uniformly and independently at random for any query (i, x). Hence, the answer of the oracle is a uniform and independent bit string in case b = 0 and b = 1, respectively. Formally, the advantage of the adversary in breaking the MU−PRF-security of HMAC is 0 in this setting.

Tight Security of HKDF
By definition of HKDF.Extract (Sect. 2.8), we get the following result.  Proof. (Sketch) The proof of Theorem 4 is straightforward. The adversary B can perfectly simulate the experiment Exp MU−PRF HKDF.Expand,N (A) by computing every query issued by A using its oracle. For every query of A, it computes the HKDF.Expand function except that it used its oracle instead of the HMAC function. To that end, for every query of A, B needs to make L/μ queries to its oracle. In case B is provided with the real HMAC function, it is easy to see that it perfectly simulates HKDF.Expand. Otherwise, if it is provided with a random function, each of the query answers is distributed uniformly and independently at random. Therefore, the string A is provided with in response to a query is also a uniformly random string. Hence, if A wins its experiment, B also wins.
Summary. Taking these results together with Theorem 2, we get that both HKDF.Extract and HKDF.Extract are tightly MU−PRF-secure (Definition 4) in the random oracle model. Sect. 2.8 and let H (i.e., the internal hash function)

Corollary 1. Let HKDF.Extract (with fixed output length L) be the function as defined in
where κ is the key length of the HKDF.Expand function and q H is the number of queries issued to the random oracle H.

Security of KDF
In Sect. 4, we introduced the function KDF (Fig. 3), which combines several computation steps of the TLS 1.3 Handshake Protocol into a single function call. It remains to argue about its security guarantees. KDF uses HKDF.Expand (Sect. 2.8) as a subroutine. In the following, we give a bound for KDF in Theorem 5.  N (B 4 ) where B 1 and B 3 play against HKDF.Expand for fixed output length l, and B 2 and B 4 play against HKDF.Expand for fixed output length d.
This can be seen by a straightforward sequence of four games. The main insight of this statement is that the bound is tight. Taking this together with the result of Corollary 2, we get that KDF is tightly secure if the underlying hash function of HKDF.Expand is modeled as the random oracle. Corollary 3. Let KDF be as defined in Fig. 3 and let H (i.e., the internal hash function used in HKDF.Expand (Sect. 2.8)) be modeled as a random oracle with output length μ. Then, for any adversary A where κ = μ is the key length of the HKDF.Expand function used internally and q H is the number of queries issued to the random oracle H.

Remark 3.
Note that the result on HKDF.Expand is independent of its outputs length. Also, although we use different output length HKDF.Expand instantiations in KDF, they still can share the same random oracle. This is due to the reason that the output length is determined by the number of rounds.

Tight MSKE-Security of the
where q H is the number of queries to the random oracle H.
Proof. Let break δ be the event that the adversary A wins the Test-challenge in Game δ. Further, we write Adv δ := Pr[break δ ] − 1 2 .
Game 0 The initial game of the sequence is exactly the MSKE security experiment as given in Definition 10, i.e., Game 1 In this game, we want to make sure that there are no two honest sessions that sample the same nonce r C , resp. r S , in their *Hello message. Therefore, we raise the event abort nnc if session lbl samples nonce r that was sampled by a session lbl = lbl before.
The probability that such a collision among (at most) n s independent samples from a set of size 2 λ occurs, is given by the birthday bound: Therefore, where n s is the maximum number of sessions involved in the protocol.

Game 2
In this game, we abort if there are two honest sessions that compute the same hash for different inputs in any evaluation of the hash function. We denote the corresponding event by abort hash . Observe that if the challenger aborts the game due to this reason, we have found a hash collision in the hash function H. In order to bound Pr[abort hash ], we therefore construct an adversary B 2 against the collision resistance (Definition 5) of H.
Construction of collision-finder B 2 . The reduction B 2 simulates Game 1 for A. If the challenger would raise the event abort hash , B 2 has found a collision and outputs the two (distinct) inputs to the hash function that resulted in the same hash as a collision.
Therefore, B 2 wins if abort hash is raised in Game 2, i.e., Pr[abort hash ] ≤ Adv Coll−Res H (B 2 ). Thus, Game 3 In this game, we make sure that the adversary can only test sessions that have an honest (contributive) partner in the first stage, i.e., they agree on cid 1 . To achieve this, we add another abort rule to the experiment. We raise the event abort SIG if the adversary tests a session that receives a signature valid under the public key pk U of some party U ∈ U within a ServerCertificateVerify or ClientCertificateVerify message such that there is no honest and uncorrupted party that issued this signature. Here, we assume that the tested session in particular expects a signature, i.e., peer authentication is intended.
Let us analyze Pr[abort SIG ] first and then discuss the implications of this crucial step in detail afterward. Observe that if the challenger of the experiment aborts the game due to this rule, we found a forgery for the underlying signature scheme SIG.
To that end, we can bound Pr[abort SIG ] by constructing an adversary B 3 against the MU−EUF−CMA corr -security of SIG for |U| users, where U is the set of users, running A as a subroutine.
Construction of forger B 3 According to Exp MU−EUF−CMA corr SIG, |U | (B 3 ) (Definition 8), adversary B 3 receives |U| public keys (pk U ) U ∈U 12 as input. Further, it has access to a signing oracle, access to a corruption oracle and outputs a forgery (U, m * , σ ). The forger B 3 now simulates Game 3 for A except that it uses the public keys received by its challenger and the signing oracle to compute signatures of the respective user sessions. To be precise, a signature for user U is computed by issuing a signature query (U, ·) to the signing oracle. Whenever, the adversary queries Corrupt(U ), B 3 relays the corruption query to its corruption oracle and sends the answer to the adversary. Now, if the challenger in Game 3 would raise the event abort SIG , the forger has found a forgery. Namely, let m * = SCV H 1 (resp. m * = CCV H 3 ) (see Sect. 4), let σ be the signature involved in the event abort SIG , which was received in the ServerCertificateVerify (resp. ClientCertificateVerify) message and let U be the party such that σ is valid under pk U for message m * , but no honest session output σ . The forger outputs (U, m  *  , σ ).
First, observe that B 3 can use its oracles to perfectly simulate Game 3 for A. Further, note that abort SIG only includes uncorrupted parties, which implies that U was never corrupted by both A and

This gives us
Next, we discuss the implications of this step. Suppose there is a tested session lbl that has no contributive first-stage partner, i.e., there is no lbl = lbl such that lbl.cid 1 = lbl .cid 1 . Due to the definition of the identifiers, we have that cid 1 is contained in sid 1 and thus lbl also has no session partner lbl such that lbl.sid 1 = lbl .sid 1 . This in turn implies that lbl cannot have an honest (contributive) partner in any stage since sid 1 = cid 2 = cid 3 = cid 4 as described in Sect. 4.3. Recall that the model requires that keys can only be tested in unauthenticated stages if the tested session has a contributive partner (see Sect. 3.3, Test). Therefore, an adversary can only test a session in the absence of a contributive first-stage partner in stages 2-4 (stage 1 is always unauthenticated). Additionally, the adversary can only win in case of a client being tested if the key is responder-authenticated (i.e., lbl.auth i ∈ {unilateral, mutual}) and in case of a server the key is initiator-authenticated. This means whenever the adversary wants to test a session without a first-stage partner the messages ServerCertificateVerify or ClientCertificateVerify are sent. Recall that the expected signature is computed over H 1 = H(CH, CKS, SH, SKS, EE, CR * , SCRT) for ServerCertificate Verify resp. H 3 = H(CH, CKS, SH, SKS, EE, CR * , SCRT, SF, CCRT) for Client CertificateVerify. In particular, both contain sid 1 = CH, CKS, SH, SKS of the tested session lbl. However, as already mentioned above if the tested session has no contributive first-stage partner, it also has no session partner. Therefore, no honest session will seek to compute the expected signature. The only way to be able to test a session without a contributive partner therefore is to forge a signature. Due to the modifications of Game 2, we also made sure that the adversary cannot use collisions in the hash function. Observe that if a session accepts a *CertificateVerfify message it agrees on sid 1 , and therefore cid 1 , with the issuer of the respective signature. Hence, if the game does not abort due to the rule introduced in Game 3, the adversary is no longer able to issue a test query for a session that has no honest first-stage partner.

Game 4
In the previous game, we ensured that the adversary is only able to test a session when it has an honest (contributive) first-stage partner session added via a NewSessionquery. This in particular implies that the adversary in this game is potentially allowed to issue Test-queries in each stage. In the following games, we make sure that from the view of the adversary the derived keys in each stage are uniformly distributed bit strings for every session. This game prepares these steps.
Intuitively, we embed randomizations of a DH tuple in the client and server sessions. In order to do that, we change the behavior of the challenger as follows: In the beginning of game the challenger chooses a, b $ ← Z p and computes the tuple (A, B, C) := (g a , g b , g ab ). Additionally, we change the implementation of the clients and servers.
-Implementation of client sessions Consider an arbitrary client session identified by lbl in SList. The challenger proceeds exactly as in Game 3 until the session chooses its key share. Instead of choosing a fresh exponent x as described in Sect. 4, it chooses a value τ lbl $ ← Z p uniformly at random and outputs X := A · g τ lbl = g a+τ lbl as its key share in the ClientKeyShare message. Then, it proceeds as in Game 3 until it receives ServerHello and ServerKeyShare, and thus is able to compute the DHE key. If the value Y = g b+τ lbl received in ServerKeyShare was output by any honest server lbl ∈ SList, we look up the used randomness τ lbl and compute the DHE key as Note that after a server session, which received lbl's ClientKeyShare, has sent (SH, SKS) it might not necessarily be received by lbl as it was sent. This is due to the fact that the signature is only sent after the first stage. Therefore, if lbl receives a SKS message that was not output by any honest server session, we do not know the corresponding value τ lbl used in Y . Here, we cannot apply the above formula and use that we know the exponent a instead. In this case, we compute The rest is exactly as in Game 3. -Implementation of server sessions Consider an arbitrary server session identified by lbl in SList. The challenger proceeds exactly as in Game 3 until the session chooses its key share. If lbl receives (CH, CKS) output by an corrupted client lbl, then it continues proceeding as in Game 3. In particular, it chooses a fresh exponent y for its key share Y . However, if lbl is not corrupted, it chooses a value τ lbl $ ← Z p uniformly at random and outputs Y := B · g τ lbl = g b+τ lbl . If the value X = g a+τ lbl received in CKS was output by any client lbl, we look up the used randomness τ lbl and compute the DHE key as The rest is exactly as in Game 3 Although, we changed the way the sessions choose their key share values, we do not change their distribution. The key shares X , resp. Y , for all sessions still are distributed uniformly and independently at random in G. Further, observe that the computation of Z yields valid DHE key based on the DH values sent by the respective parties. Thus, we have Game 5 Using the preparations done in Game 4, we now argue that the adversary cannot learn anything about the values hts C and hts S unless it is able to break a variant of the CDH problem. To that end, we abort the game whenever the adversary queries the random oracle F 1 for (Z , CH CKS SH SKS), where (CH, CKS) and (SH, SKS) were output by honest sessions, respectively, and Z = g xy such that CKS contains g x and SKS contains g y . We denote the corresponding event by abort hts . Observe that the challenger can efficiently check whether Z = g xy because it knows the exponents x and y for every honest session. Note that if the challenger aborts the game due to this rule, the adversary was able to compute Z by only observing ClientKeyShare and ServerKeyShare. Thus, we can use A to break a computational DH problem. To be precise, we break the SDH problem in this case. This is due to the reason that the reduction needs the DDH oracle provided in SDH experiment given in Definition 3 to recognize a valid solution Z .
Construction of a SDH-adversary B 5 . The reduction B 5 receives as input group elements (A, B) = (g a , g b ) ∈ G 2 and outputs a group element C ∈ G. Moreover, it has access to a DDH oracle DDH(A, ·, ·). B 5 simulates Game 4 for adversary A, but instead of choosing fresh exponents in the beginning of the experiment, it uses (A, B) received as input. Further, the reduction does not know the exponents a and b. Therefore, it cannot compute Z for any session as described in Game 4. In these cases, we use that Z is input to the random oracle and the random oracle is under the control of the reduction. Whenever an honest session lbl would evaluate the random oracle F 1 to compute hts C hts S := F 1 (Z , CH CKS SH SKS), into the random oracle F 1 . If lbl has a contributively partnered session lbl , we need to make sure that lbl uses the same value v for its computations to ensure consistency.
Using the value hts C hts S = v, B 5 can proceed with the computations without knowing a or b at all. Then, if the adversary queries the random oracle F 1 for (Z , CH CKS SH SKS), where (CH, CKS) was output by some honest client session lbl and (SH, SKS) was output by some honest server session lbl , B 5 needs to check whether the adversary was able to break CDH, or whether it only made a random query. Therefore, it first needs to de-randomize Z . To that end, it looks up the randomnesses used by session lbl output (CH, CKS) and session lbl output (SH, SKS), respectively. Note that due to the modifications of Game 1 these sessions are unique. We denote the respective randomnesses by τ lbl and τ lbl , and compute Then, if DDH(B, Z ) = 1 it outputs Z and halts. Otherwise, it continues to simulate the game for A.
If the challenger aborts the game due to abort hts , B 5 would win with certainty. Thus, we have This modification has an important implication. When the challenger never aborts due to abort hts , we get that the adversary never gets hold of hts C hts S computed by any honest sessions not under its control. In particular, this means that from the view of the adversary hts C hts S is a uniformly and independently (from the rest of the transcript) distributed bit string. Clearly, this also means that hts C and hts S considered individually are distributed uniformly and independently (also from each other!) at random.
The main technical step of our proof is the usage of function F 1 . Using function F 1 , we achieve that the DHE key Z and the messages ClientHello and ServerHello are bound together in a single function call (similar to the key derivation in TLS 1.2). If this would not be the case the reduction in this step would need to iterate over every pair of random values (τ lbl , τ lbl ), compute the value Z for each of these pairs and check the DDH oracle for validity. This is rather inefficient (i.e., losing tightness) and is solved by the function F 1 in combination with Game 1 in an elegant way. Furthermore, we need F 1 to be a programmable random oracle to solve the "commitment problem" discussed by [38] to achieve tightness. The programming of the random oracle in combination with the SDH assumption is an alternative solution to the widely used PRF-ODH assumption used in TLS proofs.

Game 6
Observe that due to Game 3, the adversary is only able to issue Test-queries to sessions that have a first stage partner. In particular, this first stage partner is unique due to the modification given in Game 1. Since client and server sessions agree on cid 1 and thus on sid 1 = (CH, CKS, SH, SKS), where CH and SH are unique among the sessions, we also have a unique matching. In this game, we replace htk by a uniformly random value htk $ ← {0, 1} ν in all sessions that have a contributive first stage partner, i.e., in every session that can possibly be tested by the adversary. Note that this is already determined when the sessions compute htk. Clearly, we need to use the same value htk in the contributively partnered session. This modification should be unrecognizable unless the adversary is able to distinguish KDF from a truly random function. We analyze the difference in A's advantage introduced by this modification by constructing a reduction against the multi-user pseudorandomness (Definition 4) of KDF for n s users, where n s is the maximum number of sessions.
Construction of a MU-PRF-distinguisher B 6 . The reduction B 6 has access to an oracle O b (·, ·) and outputs a bit b ∈ {0, 1}. For convenience, we assume that the users in experiment Exp MU−PRF KDF,n s B 6 are identified by the same value as the unique session labels used in the MSKE experiment Exp MSKE KE (A). B 6 simulates Game 5 for A. Whenever the challenger in Game 5 would compute htk, B 6 first checks whether the session at hand, say lbl, has a contributive partner and if this is the case, it uses its oracle O b (lbl, ε) to compute htk. Then, it sets htk to the same value for the partnered session. For the non-partnered session as well as the rest of the simulation it proceeds exactly as in Game 5. Finally, if B 6 outputs whatever A outputs.
If O b is the KDF, then B 6 perfectly simulates Game 5. Otherwise, if O b is a truly random function it perfectly simulates Game 6. Thus, Adv 5 ≤ Adv 6 + Adv MU−PRF KDF,n s (B 6 ). Now we have that the handshake traffic key htk, i.e., htk C and htk S , used to encrypt the handshake messages is distributed uniformly and independently at random in all sessions that can be tested. Hence, the probability to guess the challenge bit correctly after any Test(lbl, 1)-query is 1/2. This is because the adversary is given a truly random key, independent of the test bit.
Game 7 Similar to Game 5, we next argue that the adversary does not learn anything about the values ats C and ats S unless it is able to break the SDH problem. We add a similar abort rule as before and abort the game whenever the adversary queries the random oracle F 2 for (Z , CH CKS SH SKS · · · SF), where (CH, CKS) and (SH, SKS) were output by honest sessions, respectively, and Z = g xy such that CKS contains g x and SKS contains g y . We denote the corresponding event by abort ats . To analyze the probability of abort ats , we construct an adversary B 7 against the SDH assumption. The construction of B 7 follows along the lines of B 5 except that we replace the considered random oracle by F 2 and the considered random oracle query by (Z , CH CKS SH SKS · · · SF).
Following the same argumentation as in Game 5, we get Game 8 In this game, we replace atk by a uniformly random value atk $ ← {0, 1} ν in all sessions that have a contributive first stage partner, i.e., in every session that possibly can be tested by the adversary. Note that this is already determined when the sessions compute atk. Clearly, we need to use the same value atk in the contributively partnered session. This step is analogous to Game 6, and thus supplies Adv 7 ≤ Adv 8 + Adv MU−PRF KDF,n s (B 8 ).

Game 9
In this game, we argue that the adversary does not learn anything about the stage-3 key ems. To that end, we employ the same argumentation already given in Games 5 and 7 that this is the case unless the adversary is not able to break the SDH assumption. Formally, we abort the game whenever the adversary queries the random oracle F 3 for (Z , CH CKS SH SKS · · · SF), where (CH, CKS) and (SH, SKS) were output by honest sessions, respectively, and Z = g xy such that CKS contains g x and SKS contains g y . We denote the corresponding event by abort ems . To analyze the probability of abort ems , we construct an adversary B 9 against the SDH assumption. The construction of B 9 follows along the lines of B 5 except that we replace the considered random oracle by F 3 and the considered random oracle query by (Z , CH CKS SH SKS · · · SF). Following the same argumentation as in Games 5 and 7, we get Adv 8 ≤ Adv 9 + Pr[abort ems ] ≤ Adv 9 + Adv SDH G, g (B 9 ).
Game 10 In this game, we argue that the adversary does not learn anything about the stage-4 key rms. To that end, we employ the same argumentation already given in Games 5, 7 and 9 that this is the case unless the adversary is not able to break the SDH assumption. Formally, we abort the game whenever the adversary queries the random oracle F 4 for (Z , CH CKS SH SKS · · · CF), where (CH, CKS) and (SH, SKS) were output by honest sessions, respectively, and Z = g xy such that CKS contains g x and SKS contains g y . We denote the corresponding event by abort rms . To analyze the probability of abort rms , we construct an adversary B 10 against the SDH assumption. The construction of B 10 follows along the lines of B 5 except that we replace the considered random oracle by F 4 and the considered random oracle query by (Z , CH CKS SH SKS · · · CF). Following the same argumentation as in Games 5, 7 and 9, we get Adv 9 ≤ Adv 10 + Pr[abort rms ] ≤ Adv 10 + Adv SDH G, g (B 10 ).
Closing remarks Finally, we have the case that in Game 10 the keys of either stage, i.e., htk, atk, ems and rms, are from the view of the adversary uniformly and independently distributed bit strings. This implies that for each Test-query, the distribution of the received key is independent of the test bit b Test . Therefore, the probability that the adversary guesses the test bit correctly is 1/2. Hence, the advantage in guessing the test bit correctly in Game 10 is Overall, we get

Tight Compositional Security of MSKE Protocols
In this section, we revisit the latest version of the composition theorem of MSKEprotocols stated by [40,Thm. 4.4]. The original theorem suffers from a linear loss in the number of sessions involved in the protocol. However, Günther already conjectures that the hybrid argument inducing the linear loss in the proof of the composition theorem might be removed by making use of the multiple Test-queries allowed in MSKE model (Sect. 3). Currently, each hybrid step only uses a single Test-query in the reduction to the MSKE-security (see [40,Lem. 4.5]). Using as many Test-queries in the reduction to the MSKE experiment as number of sessions removes the necessity of a hybrid argument.
In the following, we recall necessary preliminaries from [40], state the improved (in terms of tightness) composition theorem, prove it and finally discuss the implications on TLS 1.3.

Compositional Security of MSKE Protocols
In general, key exchange protocols are only reasonable when used in combination with another protocol using the derived keys. However, it is not trivially clear that the composition of a key exchange protocol with a "partner protocol" still remains secure. To tame complexity of the security analysis it is always desirable to be as modular as possible. Therefore, the appealing option is to prove the two protocols secure on their own and apply some generic composition theorem to show that the composition remains secure. In case of the standard Bellare-Rogaway key exchange model [12], [23] were able to show that a protocol that is secure in the Bellare-Rogaway model can be securely composed with an arbitrary symmetric key protocol.
Fischlin et al. [36] transferred this result into the multi-stage setting, which also evolved over time with the MSKE model (Sect. 3), see [31,33,37,40]. We refer to the most recent version presented in [40]. The result states that an MSKE-secure protocol providing key-independence, stagej forward secrecy and multi-stage session matching (see below), can be securely composed with an arbitrary symmetric key-protocol at a forward-secure, external and non-replayable stage.

Composed Security Experiment
Next, we describe the composed experiment. Let Exp MSKE KE be the MSKE security experiment involving protocol KE and let Exp GOAL be some security experiment for an arbitrary symmetric key protocol . As [40], we fix some stage i and consider only the keys of this stage to be used in .
We denote the composition of KE and , where only the stage-i keys are used in , by KE i ; . The composed security experiment is denoted by Exp MSKE;GOAL and is defined as follows for some adversary A: In essence, adversary A is challenged in the composed game to win the sub-experiment Exp GOAL (A) with the modification of keys being not chosen by the challenger but originate from KE. To that end, we start by simulating Exp MSKE KE (A). We introduce a special key registration query in Exp GOAL to allow using keys originating from KE. This query is only executed by the composed game. Upon acceptance of a session key key i in stage i of some session of KE such that the key was derived by either an authenticated session or a contributively partnered session, we register key i as a new key in the sub-experiment Exp GOAL (A) allowing the adversary to issue queries as defined in Exp GOAL involving this (and possibly previous registered) key (s). To be precise, we only register accepted keys key i of a session lbl such that either lbl has an authenticated communication partner, i.e., lbl.auth i = mutual or lbl.auth i = unilateral and lbl.role = initiator, or has an honest contributive partner, i.e., there is a session lbl in KE with lbl.cid i = lbl .cid i . This is important to make sure that adversary has no information about the registered keys. Otherwise, we cannot guarantee security in Exp GOAL (A). The composed game can be viewed as a concurrent execution of Exp MSKE KE (A) and Exp GOAL (A) by some challenger. The adversary is allowed to issue queries of both experiment, which the challenger essentially just relays to the suitable sub-experiment. In case of queries, we need to make the following restrictions: First, as mentioned above, the key registration query for Exp GOAL can only be asked by the composed experiment challenger. Also, this query is only allowed to be executed when a key is accepted in stage i. Second, Reveal-queries of Exp MSKE KE are not allowed for stage i keys. This is due to the reason that the corruption of stage i keys might only be captured by Exp GOAL . Third, the Test-query makes no sense in the composed experiment as we aim for the security goals of in the composed experiment. Finally, adversary A wins the composed experiment, if it is able to win the sub-experiment Exp GOAL (A) with access to the oracles discussed above.

Multi-stage Session Matching
We recall the definition of a multi-stage session matching algorithm stated by [40]. Here, the first list contains exactly those pairs of sessions that are partnered (i.e., they share the same session identifier sid i ). The second list contains exactly those pairs of sessions that are contributively partnered (i.e., they share the same contributive identifier cid i ).
We say KE allows for multi-stage session matching, if such an algorithm M exists for KE.
Note that the session matching algorithms can be run at any point of the execution of the key exchange protocol.

Improved Multi-stage Compositional Security
Next, we restate the composition theorem of [40] with improved tightness. Compared to [40], we reduced the factor of the MSKE advantage to 1. This was already conjectured in [40]. The proof of Theorem 7 basically follows along the lines of [40,Thm. 4.4].
Proof. The proof follows a sequence of games [68]. Let Adv δ denote the advantage of the adversary A in game δ.
2. SKEY : LABELS → {0, 1} ν , which stores the stage-i key that is registered in the symmetric key protocol.
For the oracles, we have the following: -NewSession, Reveal and Corrupt queries are simply forwarded to Exp MSKE KE (B 2 ) and responses directly forwarded to A. In addition, B 2 adds after every NewSession-query an entry to SDATA containing the issued label, the respective role and the respective authentication type for stage i. Let us argue why it is valid to just forward Reveal and Corrupt to the experiment B 2 is running in. In case of Reveal, note that we assume key independence for KE. This means that any query Reveal(·, i ) with i = i (Reveal(·, i) is forbidden in the composed experiment) does not affect the security of a stagei key (since they are independent). In case of Corrupt, the stagej ( j ≤ i) forward secrecy assumed for KE make sure that stage i keys are untouched by Corrupt queries. 13 -Send-queries are also forwarded to the experiment Exp MSKE KE (B 2 ) and answered relayed back to A. However, B 2 is doing the following. If some session lbl changes in Exp MSKE KE (B 2 ) to an accepting state for some stage j < i in response to a Send-query, adversary B 2 issues a Reveal(lbl, j)-query and stores the key key j it gets in response in the map SDATA. Due to the fact that KE is key independent by assumption, such a Reveal query does not affect any stage-i key. We need to get these keys to run the multi-stage session matching algorithm in next step. When any session lbl changes into an accepting state in stage i, B 2 runs the multi-stage session matching algorithm (Definition 11) for KE on input all queries and respective responses A issued to the sub-experiment Exp MSKE KE (A) of the composed experiment as well as all established stagej keys for j < i stored in SDATA. The algorithm outputs all sessions that are partnered and also those that are contributively partnered in stage i. If some session lbl is partnered with some other session lbl such that SKEY(lbl ) is set, B 2 sets SKEY(lbl) accordingly and provides A with an identifier for SKEY(lbl) of lbl in the sub-experiment Exp GOAL (A) to enable queries on the key. Due to Game 1, we have already ensured that these keys are always identical. If this is not the case, B 2 needs to check whether the key of lbl is supposed to be registered in the sub-experiment Exp GOAL (A). Therefore, it checks whether lbl either lbl has an authenticated communication partner, i.e., lbl.auth i = mutual or lbl.auth i = unilateral and lbl.role = initiator (obtained using SDATA), or has an honest contributive partner, i.e., there is a session lbl in KE with lbl.cid i = lbl .cid i . In case this is true, B 2 queries Test(lbl, i), stores the resulting key in SKEY(lbl) and registers SKEY(lbl) for lbl in the sub-experiment Exp GOAL (A). The adversary is given an identifier for SKEY(lbl) to query issues on that key. 13 Note that compared to [40], we do not mention the non-replayability of stage i at this point. This is due to the reason that we do not have RevealSemiStaticKey-queries in our model. However, non-replayability is important for a two-party symmetric key protocol to ensure that a key is shared only between two parties. for A. When A stops, B 3 simply outputs whatever A outputs. Recall that A in the composed security experiment essentially is challenged to win the experiment Exp GOAL (A) with keys originating from the key exchange protocol. Therefore, B 3 will provide a correctly formed output. Hence, we obtain the following relation as claimed before: Taking all steps together, we get the statement claimed in Theorem 7.

Tight Compositional Security of TLS 1.3
The results on Match-security (Theorem 1) and on MSKE-security (Theorem 6) show that the tight security of TLS 1.3 is in principle achievable given the TLS 1.3 Record Protocol provides tight security as well. [13] and [41] investigated the multi-user security of AES-GCM as used in TLS 1.3. In particular, Hoang et al. were able to give a tight bound for the nonce-randomization mechanism ([41,Thm. 4.2]) that is adopted in TLS 1.3 ([65, Sect. 5.3]).

Using the Bound of Hoang et al. for the TLS 1.3 Record Protocol
To formally apply the result of [41] in Theorem 7, we need to introduce a trivial intermediate step. TLS 1.3 as defined in Sect. 4 derives every traffic (i.e., handshake and application traffic key) as a pair of client and server key. To reflect this in the symmetric key protocol, we define an intermediate experiment that takes a key that can be split up into two separate keys and uses these keys for an authenticated encryption experiment. The adversary then can issue queries for both client and server individually.

Implications of Theorem 8
We stress that the tight bound given for the nonce-randomization of AES-GCM given in [41] is independent of the number of users. Thus, Theorem 8 shows that the given tight bound still applies to the experiment Exp COMP−MU−AE
Using the composition theorem stated in Theorem 7 we obtain that given a MSKE protocol KE that provides a tight bound on both Match-security (Definition 9) and MSKE-security (Definition 10) and a symmetric key protocol that provides a tight bound in its respective security model, we result in a tightly secure composed protocol. For TLS 1.3, we were able to show in Theorem 6 when instantiated with suitable, tightly secure primitives that the TLS 1.3 Handshake protocol is tightly MSKE-secure in the random oracle model. The results of Sect. 5 on the tight security of the PRFs used in the TLS 1.3 Handshake protocol supplies in Corollary 4 that we are indeed able to instantiate TLS 1.3 tightly secure in the random oracle model with the exception of the signature scheme SIG. For the TLS 1.3 Record Layer, we can use Theorem 8 and the intermediate experiment defined in Definition 12 to incorporate the tight bound of [41] for AES-GCM's nonce randomization mechanism. Hence, we have that the composition of the TLS 1.3 Handshake protocol when using the keys derived in stage 2, i.e., the application traffic key, in the experiment Definition 12 enables an almost tight instantiation of TLS 1.3 for every TLS_AES_*_GCM_* ciphersuites.
Also, security for the Record Protocol in a stronger security model in a tightly secure manner remains an open question. The result of [41] is stateless, however as attacks in the past have shown, security against reordering attacks is an important property for TLS. We note at this point that the in the way we did it in Definition 12, one can transfer every multi-user notion into a similar experiment. Therefore, stronger results easily can be incorporated by a generalization of the experiment given in Definition 12.