Session Resumption Protocols and Efficient Forward Security for TLS 1.3 0-RTT

The TLS 1.3 0-RTT mode enables a client reconnecting to a server to send encrypted application-layer data in “0-RTT” (“zero round-trip time”), without the need for a prior interactive handshake. This fundamentally requires the server to reconstruct the previous session’s encryption secrets upon receipt of the client’s first message. The standard techniques to achieve this are session caches or, alternatively, session tickets. The former provides forward security and resistance against replay attacks, but requires a large amount of server-side storage. The latter requires negligible storage, but provides no forward security and is known to be vulnerable to replay attacks. In this paper, we first formally define session resumption protocols as an abstract perspective on mechanisms like session caches and session tickets. We give a new generic construction that provably provides forward security and replay resilience, based on puncturable pseudorandom functions (PPRFs). We show that our construction can immediately be used in TLS 1.3 0-RTT and deployed unilaterally by servers, without requiring any changes to clients or the protocol. To this end, we present a generic composition of our new construction with TLS 1.3 and prove its security. This yields the first construction that achieves forward security for all messages, including the 0-RTT data. We then describe two new constructions of PPRFs, which are particularly suitable for use for forward-secure and replay-resilient session resumption in TLS 1.3. The first construction is based on the strong RSA assumption. Compared to standard session caches, for “128-bit security” it reduces the required server storage by a factor of almost 20, when instantiated in a way such that key derivation and puncturing together are cheaper on average than one full exponentiation in an RSA group. Hence, a 1 GB session cache can be replaced with only about 51 MBs of storage, which significantly reduces the amount of secure memory required. For larger security parameters or in exchange for more expensive computations, even larger storage reductions are achieved. The second construction combines a standard binary tree PPRF with a new “domain extension” technique. For a reasonable choice of parameters, this reduces the required storage by a factor of up to 5 compared to a standard session cache. It employs only symmetric cryptography, is suitable for high-traffic scenarios, and can serve thousands of tickets per second.


0-RTT Protocols
A major innovation of TLS 1.3 [51] is its 0-RTT (zero round-trip time) mode, which enables the resumption of sessions with minimal latency and without the need for an interactive handshake. A 0-RTT protocol allows the establishment of a secure connection in "one-shot", that is, with a single message sent from a client to a server, such that cryptographically protected payload data can be sent immediately ("in 0-RTT") along with the key establishment message, without the need for a latencyincurring prior handshake protocol. This significant speedup of connection establishment yields a smoother Web browsing experience and, more generally, better performance for applications with low-latency requirements. This is particularly noticeable in networks with relatively high latency, such as mobile networks.
The huge practical demand for 0-RTT is exemplified by the fact that many large Internet companies have developed and experimented with such protocols in the recent past, for example Google's QUIC [16] and Facebook's Zero [35] protocols. The content distribution provider Cloudflare has deployed the 0-RTT mode of TLS 1.3 as early as March 2017 at large scale, long before the finalization of the standard [57]. Google and Facebook declared that the cryptography in QUIC and Zero will soon be replaced by TLS 1.3 0-RTT [5,35].
The TLS 1.3 0-RTT Handshake A full TLS 1.3 handshake (not 0-RTT) is always used in the very first connection between a client and a server. If the server supports 0-RTT, then both the client and server can derive a resumption secret from their shared key and session parameters. The client will simply store this secret. Naturally, the server then needs to retrieve the resumption secret during a subsequent handshake. There are two standard approaches for this, session caches and session tickets, which have different advantages and drawbacks. During the first handshake, the server sends to the client either a lookup key pointing to an entry in the session cache of the server, or a session ticket-depending on the configuration of the server. These approaches essentially work as follows: Session caches: The server stores all resumption secrets of recent sessions in a local database and issues each client a unique lookup key. When a client reconnects, it includes that lookup key in its 0-RTT messages, enabling the server to retrieve and use the matching resumption secret.

Session tickets:
The server uses a long-term symmetric encryption key, called the session ticket encryption key (STEK). Instead of storing the resumption secret in a local database, the server encrypts it with the STEK to create a session ticket. The session ticket is stored by the client. When a client reconnects, it includes that session ticket in its 0-RTT messages, which enables the server to decrypt it and recover the resumption secret. Note that the same STEK is used for many sessions and clients.
On a subsequent 0-RTT handshake, the client will include in its first message either the lookup key or the encrypted session ticket, in addition to a Diffie-Hellman key exchange message. The client can also send, in the same message, encrypted application-layer data, termed 0-RTT data. This data will be encrypted with a key derived from the resumption secret and a public client random value, without any input from the server.
In its reply, the server will typically include a Diffie-Hellman key exchange message, and further messages (in either direction) will be encrypted with a key derived also from the DH secret, not only the resumption secret. Hence, the only data protected by the resumption secret alone is the 0-RTT data. We note that the use of DH is not mandatory, and it is possible to rely only on the resumption secret for the security of the entire session; we expect most traffic will use DH as described above.
We stress that the use of session caches or session tickets is opaque to clients. That is, in either case the server sends a NewSessionTicket message containing an opaque sequence of bytes, which may be either a lookup key for the session cache, or an encrypted session ticket, without specifying which is the case. This property ensures that our proposed techniques are compatible with the final TLS 1.3 standard [51] and can be implemented on the server-side without requiring modifications to the protocol or to clients.
Confusingly, the message containing this opaque sequence of bytes is always termed a "NewSessionTicket message", for both session caches and encrypted self-contained session tickets. To our knowledge there is no standard nomenclature, in [51] or elsewhere, for these two different approaches when used in TLS 1.3; see e.g. [51, §8.1]. TLS 1.2 referred to "Session ID Resumption" and "Session Ticket Resumption", but these terms are not used in TLS 1.3.

Forward Security and Replay Resilience of 0-RTT Protocols
Forward security essentially means that the protocol provides security of sessions, even if an attacker is able to corrupt one party after the session has terminated (e.g., by breaking into a Web server and learning the long-term secret key). Resilience to replay attacks is a fundamental, classical design goal of cryptographic protocols, which prevents an attacker from replaying the same payload data to a server repeatedly.
Both forward security and replay resilience are standard design goals of modern security protocols. However, achieving these properties is well-known to be difficult for 0-RTT protocols. This is because classical ("non-0-RTT") protocols include fresh input from the server (e.g., a Diffie-Hellman message) generated using ephemeral randomness, which provides a leverage to achieve forward security. However, there is no such interactivity in 0-RTT protocols. Furthermore, an attacker is able to replay the 0-RTT key establishment message along with the 0-RTT payload data over and over again to a server, which is not detectable without additional server-side countermeasures.
For a more general treatment of the notion of "forward security" and "forward secrecy" in non-interactive contexts (such as 0-RTT protocols or instant messaging), we refer to a work by Boyd and Gellert [13].
Forward Security and Replay Resilience of TLS 1.3 0-RTT With session caches the server stores a "unique" resumption secret in a local database for each client. In most cases, it is able to delete the resumption secret immediately after retrieving it. This provides forward security, as an attacker obtaining the server state cannot decrypt past sessions. It also provides resilience against replay attacks, as the server is not able to decrypt replayed messages.
If session tickets are used, then an attacker that obtains access to the server can learn the STEK, and thus decrypt all tickets encrypted with this key to learn the resumption keys. Hence, servers using session tickets do not provide forward security. They are also generally vulnerable to replay attacks, as explained below. Since an attacker learning the STEK has catastrophic implications for security, large server operators usually rotate the STEK. Such deployments typically generate a new STEK roughly once per hour, and limit the STEK lifetime to roughly a day [46]. An attacker that learns one STEK can therefore decrypt approximately one hour's worth of traffic. However, most current TLS implementations do not provide out-of-the-box support for STEK rotation, and this (welcome) defensive measure is usually limited to large operators who can afford to modify TLS implementations [43,46]. Long-lived STEKs are unfortunately prevalent, and even among high-profile websites, some reuse the same STEK for many weeks, or even for many months [56].
STEK-based deployments are also generally vulnerable to replay attacks. When using resumption, the client must include in its first message the ticket's age, i.e. the time elapsed between receiving the ticket from the server in a previous session. The server expects this time interval to be precise up to a small window of error allowing for propagation delay, typically on the order of 10 seconds. An attacker can perform replay attacks within this time window (unless there is additional server-side logging of tickets that have already been used, which is rare).
To summarize, session caches are generally forward-secure and replay-resistant, while session tickets are not. Naïvely, it would therefore appear that session caches are the superior solution. However, session caches require the server to store the session state for each (recent) connection. This is often infeasible, in particular for high-traffic server operators. Such server operators often reluctantly use session tickets, knowingly forgoing forward secrecy. Additionally, even if forward security is not prioritized by a particular server operator and thus session tickets are used, the prevention of replay attacks may still require additional storage at the server, since the only way to prevent replay attacks in this case is to log used tickets.
In this context it is sometimes claimed that so-called idempotent requests, that is, requests that have the same effect on the server state whether they are served once or several times, are safe to use with TLS 1.3 0-RTT. However, it is well-known [48] and also discussed in the TLS 1.3 specification [51] that even replays of idempotent requests may give rise to attacks that, e.g., reveal the target URL of HTTP requests. See Appendix A for an example.
All of these issues are well-known to apply to TLS 1.3 0-RTT and have raised significant concerns about its secure deployability in practice [48]. Eric Rescorla, the main author of the TLS 1.3 RFC draft, acknowledges that this poses a "difficult application integration issue" [50]. However, due to the huge practical demand, 0-RTT is also considered "too big a win not to do" [50]. At EUROCRYPT 2017 [33] and 2018 [19,20], the first 0-RTT protocols that simultaneously achieve forward security and replay resilience were proposed, but these require relatively heavy cryptographic machinery, such as hierarchical or broadcast identity-based encryption, and thus are not yet suitable for large-scale deployment in TLS 1.3.

Our Contributions
We give the first formal definition for secure 0-RTT session resumption protocols, as an abstraction of the constructions currently used in practice in TLS 1.3. We propose new techniques to achieve forward security and replay resilience that are ready-to-use with TLS 1.3 as it is standardized, without any changes to the protocol. Our proposal is based on session tickets, and thus requires minimal storage at the server side, but we extend this approach with efficient puncturable pseudorandom functions (PPRFs) that enable us to achieve forward security and replay resilience for session tickets. We provide new constructions of PPRFs with short keys and formal security proofs based on standard hardness assumptions. We propose two variants: 1. The first variant is based on the strong RSA assumption. It reduces the server storage by a factor of at least 11 compared to a session cache, increases ticket size by a negligible length, and requires the server to perform two exponentiations (one per issuance and one per resumption). 2. The second variant reduces server storage by a factor of up to 5 compared to a session cache, while using tickets that are roughly 400 bytes longer than standard tickets. It extends a standard GGM-style [30] binary tree-based PPRF, as described in [12,14,38], with a new domain extension idea. It employs only symmetric cryptography, is suitable for very-high-traffic scenarios, and can serve thousands of tickets per second, at the cost of hundreds of megabytes in server storage.
Our Approach At the base of our approach is the concept of puncturing a pseudorandom function (PRF) to obtain a puncturable symmetric-key encryption scheme. Puncturable PRFs are a special case of constrained PRFs [12,14,38], which make it possible to derive constrained keys that allow computation of PRF output only for certain inputs. In our approach, a server initially maintains a STEK k that allows decryption of any session ticket; when receiving ticket t, the server uses k to decrypt t in order to recover the resumption secret. Using the puncturing feature of the PPRF, it then derives from k a new key, k , that can decrypt any ticket except for t. The server then discards k and stores only k . It repeats this process for every ticket received. This yields forward secrecy and replay-resistance: an attacker that compromises the server learns a key that is not capable of decrypting past tickets. Similarly, an attacker cannot successfully replay a message, since the server is only able to decrypt each ticket once.
The naïve way to employ this approach in TLS 1.3 0-RTT would be to use public-key puncturable encryption, as in [19,20,33]. However, this approach results in impractically long puncturing times or very long secret keys. Moreover, the most practical constructions require relatively expensive pairing-based cryptography by both the client and the server, thereby obviating the efficiency benefit of TLS 1.3 0-RTT. To be precise, since the puncturing times are in the order of hundreds of milliseconds, they introduce additional latency that is larger/comparable to the additional RTT they save. Rather than using public-key puncturable encryption, we observe that in TLS 1.3 0-RTT, the server itself generates the tickets it would later need to decrypt. It therefore suffices to use symmetric cryptography, and to maintain a key that allows decryption of only a limited set of ciphertexts, generated by the server itself. To achieve this, we use PPRFs to derive keys for standard TLS 1.3 tickets. Concretely, we describe two new PPRF constructions that are particularly suitable for our application: -The first builds a new PPRF from the Strong RSA Assumption. The PPRF has a polynomially-bounded input size, but this is sufficient for our application (and probably for certain other PPRF applications as well). Its main distinguishing feature is that its secret key size is independent of the number of puncturings. It consists of an RSA modulus N , a number g ∈ Z N , and a bitfield, indicating positions where the PPRF was punctured. Due to the short secret key, our construction may find other applications in applied and theoretical cryptography. Since our primary objective is to provide an as-efficient-as-possible solution for practical protocols such as TLS 1.3 0-RTT, we describe a construction with security proof in the random oracle model [7]. It seems likely that our construction can be lifted to the standard model in a straightforward way, via standard techniques like hardcore predicates [8,10,31], but this would yield less efficient constructions and is therefore outside the scope of this paper. -The second construction is based on a standard tree-based PPRF [12,14,38], instantiated with a cryptographic hash function, such as SHA-3. The size of punctured keys depends linearly on the depth of the tree, which in turn depends on the size of the domain of the PPRF. We describe a new domain extension technique that reduces the size of punctured keys by trading secret key size for ticket size, while preserving the puncturing functionality. Domain extension makes it possible to use a PPRF with a smaller domain (and thus smaller punctured keys). To save a factor of up to n in server-side storage, the ticket size rises roughly as (n − 1)!. Thus, this is only useful for small values of n, but choosing e.g. n = 5 can yield significant savings with a modest increase in ticket size on the wire. Concretely, for n = 5 and "128-bit security", ticket size is increased by 384 bytes. As discussed in Sect. 7.1, experiments done by Google estimate that this will impose only a small impact on latency [44].
Integration in TLS 1. 3 We show how to generically integrate any 0-RTT session resumption protocol in the TLS 1.3 resumption handshake. In particular, we can show that the security of the 0-RTT session resumption protocol allows achieving forward secrecy for all messages (including the 0-RTT data) of the resumption handshake without modifications to any client implementations. This yields the first variant of the TLS 1.3 resumption handshake with full forward secrecy, whereas current implementations are unable to provide this for the client's first flight of messages.
We note that our protocol is incompatible with ticket re-use. That is, a client reusing tickets may undesirably fail to resume its session, which is unavoidable if the server wants to provide forward secrecy for 0-RTT data. As forward secrecy of 0-RTT data is desirable, we hope that client implementations will not reuse tickets when sending 0-RTT data, minimizing failed session resumption attempts. We note that the TLS 1.3 standard explicitly discourages, but does not outright forbid, ticket reuse by clients [51, §C.4].
The security of the new TLS 1.3 resumption handshake variant is proven in the multistage key exchange model by Fischlin and Günther [27,28]. Their model was used in several proofs of key exchange protocols with similar levels of complexity, such as Google's QUIC protocol [27], and several drafts and handshake modes of the TLS 1.3 protocol [23,24,28]. We adopt and extend the proof of the TLS 1.3 draft-14 resumption handshake in [28]. Namely, we model the TLS 1.3 resumption handshake in its finalized version, which follows a different key derivation schedule as considered in previous works, and generically integrate a 0-RTT session resumption protocol to immediately achieve forward secrecy.

Large-Scale Server Clusters and Load Balancing
Large TLS server deployments typically consist of many servers that share the same public key. This complicates any logic that relies on the server storing some state, since these servers will typically not share a globally-consistent state. Such discussion is beyond the scope of this paper, and we will assume a single server with consistent storage throughout. When many servers share a session cache, the cache is likely to be distributed, and any logic relying on an atomic retrieve-and-delete operation becomes more complex. Therefore, distributed session caches are not necessarily replay-resistant nor forward-secure, as this requires synchronous deletion of resumption secrets at all servers, and thus synchronized state. When using session tickets, the same holds for mechanisms that store used tickets, which are likely to be distributed as well. See [51, §2.3, §8, §E.5], [48,49] for more in-depth discussion. However, in large-scale settings it is highly desirable to minimize the amount of memory that must be consistently synchronized across different servers. Our techniques are therefore useful to that end as well.
Further Applications to Devices with Restricted Resources Our techniques may also be useful for devices with very restricted resources, such as battery-powered IoT devices with a wireless network connection. For such devices, it is usually extremely expensive to send data, because each transmitted bit costs energy, which limits the battery lifetime and thus the range of possible applications. In order to maximize the battery lifetime, it is useful to avoid expensive interactive handshakes and use a 0-RTT protocol whenever data is sent to such devices. Note that here the main gain from using 0-RTT is not minimal latency, but rather that no key exchange messages must be sent by the receiver. Ideally, transmitted data should be forward-secure, but such devices have low storage capacity and we cannot use large amounts of storage to achieve forward security.
For such devices, it is reasonable to relax the requirement for very efficient computation, since adding unnecessary transmissions to even a fraction of connections is likely more costly than using moderately more expensive computations. By instantiating our session resumption protocol in a way that puncturing is more expensive (say, five full RSA exponentiations, which may still be reasonable for most IoT devices), we achieve reductions in storage by factors close to 100. Thus, our techniques make it possible to use forward-secure 0-RTT protocols even on such devices. Instead of requiring, say, 1 GB of memory for a session cache, we need only about 10 MBs of memory.
Related Work Puncturable encryption [32] was used to construct forward-secure instant messaging [32] and 0-RTT protocols [19,20,33,45], for instance. Green and Miers [32] first proposed puncturable encryption as a practical building block for the case of asynchronous messaging. They used pairing-based puncturable encryption, and as a result observed impractically long processing times for their construction. Günther et al. [33] proposed using puncturable encryption for 0-RTT protocols, again proposing concrete constructions based on pairings that are also impractical for high-traffic scenarios. Derler et al. [19,20] proposed trading off space in exchange for processing time, with the use of their proposed Bloom filter encryption. Their construction essentially precomputes many already-punctured keys, and these keys are used only once, so puncturing becomes simply key deletion. Bloom Filter Encryption may be considered practical for low-traffic scenarios, but supporting a large number of puncturings per key requires precomputation and storage of keys on the order of many gigabytes. A proof-of-concept 0-RTT key exchange based on Bloom filter encryption was implemented and analyzed by Dallmeier et al. [18]. However, their approach is incompatible with the standardized TLS protocol, which only allows a 0-RTT mode for session resumption.
Over the past years there have been several papers formally analyzing the security of TLS 1.2 [9,36,42] and TLS 1.3 [21][22][23]28]. Particularly noteworthy are the analyses of the 0-RTT mode of TLS 1.3 [28] and QUIC [27] by Fischlin and Günther, who analyze both protocols in a multi-stage key exchange model [27]. Lychev et al. [47] further formally analyzed QUIC in a security model that additionally captures the secure composition of authenticated encryption and key exchange. A security definition and construction for QUIC-like 0-RTT protocols were given in [34]. However, all these publications do not consider forward secrecy for the very first message in their security models. Hence, we believe that our techniques may also influence the design of protocols providing a 0-RTT key exchange, such as TLS 1.3 and QUIC, in order to achieve forward secrecy for all messages.
Differences to the Eurocrypt 2019 Version This work is the full version of a paper, which appeared in Advances in Cryptology-Eurocrypt 2019-38th Annual International Conference on the Theory and Applications of Cryptographic Techniques [1]. The full version discusses how our construction and its benefits can be composed with the TLS 1.3 protocol, without modifying client side implementations or the TLS 1.3 standard. In Sect. 4 we provide the composed protocol and prove its security in the multi-stage key exchange model by Fischlin and Günther [27,28]. In contrast to previous security proofs of TLS 1.3 resumption handshake drafts [23,24,28], we incorporate the finalized key derivation schedule of TLS 1.3, and are able to achieve forward secrecy for all messages by utilizing the techniques described in this work. This contribution resolves an open problem stated in a previous version of this work.
Outline The rest of this paper is organized as follows. In Sect. 2 we provide formal definitions for secure 0-RTT Session Resumption Protocols. In Sect. 3 we describe a generic construction, based on abstract PPRFs, and formally prove forward security and replay resilience. In Sect. 4 we show how our generic construction can be composed with TLS 1.3 and prove the composition's security. Section 5 describes the Strong-RSAbased PPRF and an analysis of the efficiency when used in the protocol construction in Sect. 3. Section 6 describes the tree-based PPRF and a novel "domain extension" technique for standard binary tree PPRFs, along with an efficiency analysis.
Notation We denote the security parameter as λ. For any n ∈ N let 1 n be the unary representation of n and let [n] = {1, . . . , n} be the set of numbers between 1 and n. Moreover, |x| denotes the length of a bitstring x, while |S| denotes the size of a set S. We write x $ ← − S to indicate that we choose element x uniformly at random from set S. For a probabilistic polynomial-time algorithm A we define y $ ← − A(a 1 , . . . , a n ) as the execution of A (with fresh random coins) on input a 1 , . . . , a n and assigning the output to y.

0-RTT Session Resumption Protocols and Their Security
In this section we provide formal definitions for secure 0-RTT session resumption protocols. These definitions capture both our new techniques and the existing solutions already standardized in TLS 1.3. We later show that the techniques used to formally analyze and verify TLS 1.3 0-RTT [17,24,28] can be extended to use our abstraction of a session resumption protocol within TLS 1.3. This leads us to believe that our definitions capture a reasonable abstraction of the cryptographic core of the TLS 1.3 0-RTT mode (and likely also of similar protocols that may be devised in the future).
For simplicity, in the following we will refer to pre-shared values as session keys, as they are either previously established session keys, or a resumption secret derived from a session key, as e.g. in TLS 1.3. The details of how to establish a shared secret and potentially derive a session key from it are left to the individual protocol and are outside the scope of our abstraction. Session keys are elements of a keyspace S.
-Setup(1 λ ) takes as input the security parameter λ and outputs the server's long-term key k. -TicketGen(k, s) takes as input a long-term key k and a session key s, and outputs a ticket t and a potentially modified long-term key k . -ServerRes(k, t) takes as input the server's long-term key k and the ticket t, and outputs a session key s and a potentially modified key k , or a tuple (⊥, k) where ⊥ is a failure symbol.
Using a Session Resumption Protocol A 0-RTT session resumption scheme is used by a set of clients C and a set of servers S. If a client and a server share a session key s, the session resumption is executed as follows (cf. Fig. 1). 1. The server uses its long-term key k and the session key s to generate a ticket t by running (t, k ) $ ← − TicketGen(k, s). The ticket is sent to the client. Additionally, the server replaces its long-term key k by k and deletes the session key s and ticket t, i.e. it is not required to keep any session state. 2. For session resumption at a later point in time, the client sends the ticket t to the server. 3. Upon receiving the ticket t, the server runs (s, k ) := ServerRes(k, t) to retrieve the session key s. Additionally, k is deleted and replaced by the updated key k .
Compatibility with TLS 1.3 As explained in Sect. 1, using either session tickets or session caches in TLS 1.3 is transparent to clients, i.e. clients are generally unaware of which is used. In either case, the client stores a sequence of bytes which is opaque from the client's point of view. Since all algorithms of a session resumption protocol are executed on the server, while a client just has to store the ticket t (encoded as a sequence of bytes), this generic approach of TLS 1.3 is immediately compatible with our notion of session resumption protocols. Thus, a session resumption protocol can be used immediately in TLS 1.3, without requiring changes to clients or to the protocol. Furthermore, session tickets and session caches are specific examples of such protocols.

Security in the Single-Server Setting
We define the security of a 0-RTT session resumption protocol Resumption by a security game G 0-RTT-SR A,Resumption (λ) between a challenger C and an adversary A. For simplicity, we will start with a single-server setting and argue below that security in the single-server setting implies security in a multi-server setting. Let μ be the number of sessions. . The sequence of tickets (t i ) i∈ [μ] is sent to A. 2. The adversary gets access to oracles it may query.
(a) O Dec (t) takes as input a ticket t. It computes (s, k ) := ServerRes(k, t) and outputs ⊥ if ServerRes failed. Otherwise, it returns the session key s and replaces k := k . Note that ticket t can either be a ticket of the initial sequence of tickets (t i ) i∈ [μ] or an arbitrary ticket chosen by the adversary.
and outputs ⊥ if the output of ServerRes was (⊥, k). Otherwise, it updates k := k . If b = 1, then it returns the session key s. Otherwise, a random r $ ← − S is returned. Note that ticket t can either be a ticket of the initial sequence of tickets (t i ) i∈ [μ] or an arbitrary ticket chosen by the adversary. The adversary is allowed to query O Test only once. (c) O Corr returns the current long-term key k of the server. The adversary must not query O Test after O Corr , as this would lead to a trivial attack.
3. Eventually, adversary A outputs a guess b * . Challenger C outputs 1 if b = b * and 0 otherwise.
Note that this security model reflects both forward secrecy and replay protection. Forward secrecy is ensured, as an adversary may corrupt the challenger after issuing the O Test -query. If the protocol did not ensure forward secrecy, an attacker could corrupt its long-term key and trivially decrypt the challenge ticket. Replay protection is ensured, as an adversary is allowed to issue O Dec (t i ) after already testing O Test (t i ) and vice versa (as both queries invoke the ServerRes algorithm). If the protocol did not ensure replay protection, an attacker could use the decryption oracle to distinguish a real or random session key of the O Test -query. Definition 2. We define the advantage of an adversary A in the above security game G 0-RTT-SR A,Resumption (λ) as We say a 0-RTT session resumption protocol is secure in a single-server environment if the advantage Adv 0-RTT-SR A,Resumption (λ) is a negligible function in λ for all probabilistic polynomial-time adversaries A.

Security in the Multi-server Setting
A 0-RTT session resumption protocol that is secure in our model, only guarantees security in a single-server setting. However, session resumption protocols are meant to be executed in a multi-server environment. In this section, we provide the respective security model and a proof that single-server security implies multi-server security with a standard polynomial loss in the number of servers, provided each server has a different long-term key.
We define the security of a 0-RTT session resumption protocol Resumption with multiple servers in the following security game between a challenger C and an adversary A. Let μ be the number of sessions and d be the number of servers.
The adversary gets access to oracles it may query.
(a) O Dec (t, j) takes as input a ticket t and an identifier j. It computes (s, k j ) := ServerRes(k j , t) and outputs ⊥ if ServerRes failed. Otherwise, it returns the session key s and replaces k j := k j . Note that ticket t can either be a ticket of the initial sequence of tickets (t i ) i∈ [μ] or an arbitrary ticket chosen by the adversary. (b) O Test (t, j) takes as input a ticket t and a server identifier j. It computes s := ServerRes(k j , t) and outputs ⊥ if the output of ServerRes was (⊥, k j ).
Otherwise it replaces k j := k j and returns either the session key s if b = 1 or a random r $ ← − S if b = 0. Note that ticket t can either be a ticket of the initial sequence of tickets (t i ) i∈ [μ] or an arbitrary ticket chosen by the adversary. The adversary is only allowed to query O Test once and only for tickets t which have not been queried using O Dec (t) before. (c) O Corr ( j) takes as input a server identity j ∈ [d]. It returns the server's longterm key k j . The adversary is not allowed to query O Test (t, j) after O Corr ( j), as this would lead to trivial attacks.
3. Eventually, A outputs a guess b * . Challenger C outputs 1 if b = b * and 0 otherwise.

Definition 3.
We define the advantage of an adversary A in the above security game G M0-RTT-SR A,Resumption (λ) as We say a 0-RTT session resumption protocol is secure in a multi-server environment if the advantage Adv M0-RTT-SR A,Resumption (λ) is a negligible function in λ for all probabilistic polynomial-time adversaries A. Proof. Let A be an adversary against the M0-RTT-SR security of Resumption. We will use this adversary to construct an adversary B against the 0-RTT-SR security of Resumption. The 0-RTT-SR challenger C starts its security game by sending a tuple of tickets (t i ) i∈ [μ] . In order to initialize A we need to prepare a tuple of tickets (t i, j ) ( We embed our challenge as We need to distinguish two possible cases. We can simulate all queries A can ask for server identities j ∈ δ by ourselves, as we know all secret values for those servers. In the case of j = ν we forward all queries to the challenger C and send the answers back to A. If A queries O Test (t i, j , j) we behave in the following way. If j = ν we continue the security game and forward the final bit output of A as our solution of the challenge to C. If j = ν we abort the security game and output a random bit to C.
In the case of j = ν we win the security game with the advantage Adv 0-RTT-SR A,Resumption (λ). This happens with a probability of 1/d as ν $ ← − [d] is drawn at random. If j = ν, we have no advantage compared to guessing. In conclusion, we have On Theoretically-Sound Instantiation Tight security in a multi-server setting is a major issue for classical AKE-like protocols. First tightly-secure protocols were described by Bader et al. [2], and by Gjøsteen-Jager [29]). Similar to classical AKE protocols, our extension to the multi-server setting is non-tight as we have a security loss in the number of protocol participants (which is the "standard security loss" for many AKE-like protocols). So, if parameters are chosen in a theoretically-sound way (which is currently rather uncommon in practice, but would be a desirable goal in our opinion), then this factor needs to be compensated with larger parameters.

Constructing Secure Session Resumption Protocols
In this section we will show how session resumption protocols providing full forward security and replay resilience can be constructed. We will start with a generic construction, based on authenticated encryption with associated data and any puncturable pseudorandom function that is invariant to puncturing. Later we describe new constructions of PPRFs, which are particularly suitable for use in session resumption protocols.

Building Blocks
We briefly recall the basic definition of puncturable pseudorandom functions and authenticated encryption with associated data.
Puncturable PRFs A puncturable pseudorandom function is a special case of a pseudorandom function (PRF), where it is possible to compute punctured keys which do not allow evaluation on inputs that have been punctured. We recall the definition of puncturable pseudorandom functions and its security from [54].

Definition 4.
A puncturable pseudorandom function (PPRF) with keyspace K, domain X and range Y consists of three probabilistic polynomial-time algorithms PPRF = (Setup, Eval, Punct), which are described as follows.
-Setup(1 λ ): This algorithm takes as input the security parameter λ and outputs an evaluation key k ∈ K. -Eval(k, x): This algorithm takes as input a key k ∈ K and a value x ∈ X , and outputs a value y ∈ Y, or a failure symbol ⊥. -Punct(k, x): This algorithm takes as input a key k ∈ K and a value x ∈ X , and returns a punctured key k ∈ K.
A new property of PPRFs that we will need is that puncturing be "commutative", i.e. the order of puncturing operations does not affect the resulting secret key. That is, for any x 0 , x 1 ∈ X , x 0 = x 1 , if we first puncture on input x 0 and then on x 1 , the resulting key is identical to the key obtained from first puncturing on x 1 and then on x 0 . This implies that puncturing by any set of inputs always gives the same result, regardless of the order of puncturing. Formally: We define two notions of PPRF security. The first notion represents the typical pseudorandomness security experiment with adaptive evaluation queries by an adversary. The second notion is a weaker, non-adaptive security experiment. We show that it suffices to prove security in the non-adaptive experiment if the PPRF is invariant to puncturing and has a polynomial-size domain. Definition 7. We define the advantage of an adversary A in the rand (resp. na-rand) Fig. 2 as We say a puncturable pseudorandom function PPRF is rand -secure (resp. na-rand -secure), if the advantage Adv rand A,PPRF (λ) (resp. Adv na-rand A,PPRF (λ)) is a negligible function in λ for all probabilistic polynomial-time adversaries A.
It is relatively easy to prove that na-rand-security and rand-security are equivalent, up to a linear security loss in the size of the domain of the PPRF if the PPRF is invariant to puncturing. In particular, if the PPRF has a polynomially-bounded domain size, then both are polynomially equivalent.
Proof. The proof is based on a straightforward reduction. We give a sketch. Let A be an adversary against the rand security of PPRF. We guess A's challenge value in advance by sampling ν $ ← − X uniformly at random. We initialize the na-rand challenger by sending it ν. In return we receive a challenge y (either computed via Eval or random) and a punctured key k that cannot be evaluated on input ν.
The punctured key k allows us to correctly answer all of A's O Eval queries, except for ν. When the adversary outputs its challenge x * we will abort if x * = ν. Otherwise, we forward y and a punctured key k that has been punctured on all values of the O Eval queries. Note that the key has a correct distribution, as we require that the PPRF is invariant to puncturing.
Eventually, A outputs a bit b * which we forward to the na-rand challenger. The simulation is perfect unless we abort it, which happens with polynomiallybounded probability 1/|X |, due to the fact that |X | is polynomially bounded.
Authenticated Encryption with Associated Data We will furthermore need authenticated encryption with associated data (AEAD) [52], along with the standard notions of confidentiality and integrity.

Definition 8.
An authenticated encryption scheme with associated data is a tuple AEAD = (KGen, Enc, Dec) of three probabilistic polynomial-time algorithms: -KGen(1 λ ) takes as input a security parameter λ and outputs a secret key k.
-Enc(k, m, ad) takes as input a key k, a message m, associated data ad and outputs a ciphertext c. -Dec(k, c, ad) takes as input a key k, a ciphertext c, associated data ad and outputs a message m or a failure symbol ⊥.

Definition 9. We define the advantage of an adversary
We say an AEAD scheme AEAD is indistinguishable under chosen-plaintext attacks is a negligible function in λ for all probabilistic polynomial-time adversaries A. Fig. 3 as

Definition 10. We define the advantage of an adversary
We say an AEAD scheme AEAD provides integrity of ciphertexts is a negligible function in λ for all probabilistic polynomial-time adversaries A.

Generic Construction
Now we are ready to describe our generic construction of a 0-RTT session resumption protocol, based on a PPRF and an AEAD scheme, and to prove its security. - Then it encrypts the ticket as t $ ← − AEAD.Enc(κ, s, n). Finally, it defines t = (t , n) and k := (k PPRF , n + 1), and outputs (t, k). Note that the associated data n is sent in plaintext when the client resumes the session, posing a potential privacy leak: Assume an attacker that observes all communication to and from the server. When the attacker observes a client resuming using a ticket with associated data n, the attacker learns that it is the same client that first connected when the server issued the n-th ticket. Newly-generated tickets are first sent encrypted from the server to the client, but it is feasible for the attacker to identify sessions where the server issued tickets by performing traffic analysis (and then identifying the n-th such session). In essence, using the above construction as-is, sessions are linkable. This can be circumvented by additionally encrypting n under a dedicated symmetric key. Compromise of this key would only allow an attacker to link sessions by the same returning client, not to decrypt past traffic, therefore this symmetric key needs not be punctured to achieve forward security.
We remark that the natural solution would be to encrypt n using public-key puncturable encryption, but this would be costly, and obviate most of the efficiency benefits described in this work. We are unfortunately unaware of a good solution that achieves session unlinkability in the event of server compromise. We further note that TLS 1.3 0-RTT includes a mechanism named "obfuscated ticket age" that solves a similar session linkability concern; that mechanism as well is not applicable here.

Theorem 3. If PPRF is invariant to puncturing, then from each probabilistic polynomialtime adversary A against the security of Resumption in a single-server environment with advantage Adv 0-RTT-SR
A,Resumption (λ), we can construct five adversaries where q Dec is the number of decryption queries and μ is the number of sessions.
Proof. We will conduct this proof in a sequence of games between a challenger C and an adversary A. We start with an adversary playing the 0-RTT-SR security game. Over a sequence of hybrid arguments, we will stepwise transform the security game to a game where the O Test -query is independent of the challenge bit b. The claim then follows from bounding the probability of distinguishing any two consecutive games. By Adv i we denote A's advantage in the i-th game.
Game 0. We define Game 0 to be the original 0-RTT-SR security game. By definition we have Game 1. In this game, we want to bound the probability that an adversary is able to forge a new ticket with n > μ. Formally, this game is identical to Game 0, but we change how O Dec and O Test queries are answered. That is, whenever the adversary queries O Dec or O Test for a ticket t = (t , n) with n > μ, we always reply with ⊥. This change is only detectable by the adversary if it forges a ticket t such that O Let X be the event that the adversary produces such a forgery t = (t , n) with n > μ. Hence, we have We bound the probability of X occurring by using the following lemma:

Lemma 1. Let q Dec be the number of decryption queries by the adversary. Then we have
Proof. Intuitively, in order to make even X happen, the adversary would have to break INT-CTXT security. But the reduction to show this is not completely straightforward, since we have to use both the security of the PPRF and the INT-CTXT security to show this. This is done by the short "branch sequence of games" considered in this lemma. For the sake of clarity, we emphasize that the lemma only claims a bound on the probability that the event X occurs. Therefore, we bound only the probability of this event, and not the probability that an adversary wins. That is, as soon as the event X has happened, the adversary does not require a consistent simulation anymore, as the occurrence of X cannot be reverted.
We prove the lemma by following a sequence of games. By Pr[X i ] we denote probability of X occurring in the i-th game. We define Game 0.0 to be Game 0 of the main proof. By definition we have Game 0.1 This game is identical to Game 0.0 but we guess which O Dec or O Test query the adversary uses for its where q Dec is the number of O Dec queries made by the adversary. Since the choice of j is oblivious to the adversary, we can bound the probability of guessing correctly by 1/(q Dec + 1). Let X 0.1 be the event that X 0 occurs and j was guessed correctly. We can then bound and subsequently assume that j was guessed correctly. Game 0.2 The difference between Games 0.1 and 0.2 is whether we use the "real" or a "random" PPRF key in the j-th query. If this changes the probability of event X 0.1 significantly, then we can construct a successful PPRF distinguisher B PPRF1 . Formally, this game is identical to Game 0.1 but we change how the j-th query in the sequence of O Dec and O Test queries is computed. Let ρ $ ← − Y be a value chosen by the experiment. Normally, the j-th query would need to compute PPRF.Eval(k, n * ) for some ticket t * = (t , n * ). However, we will now replace the result this computation with the independent and precomputed value ρ.
Everything else works exactly as before. We will show that any adversary that is able to distinguish Game 0.1 from Game 0.2, can be used to construct an adversary against the security of the underlying PPRF. Concretely, we have As soon as the adversary uses its j-th O Dec or O Test query with t = (t , n * ) and n * > μ, we relay n * as challenge to the PPRF challenger. Note that we have never used n * > μ as input to the Eval oracle, making n * an admissible challenge. The challenger responds with a punctured key k := PPRF.Punct(k, n * ) and a value γ , where either γ := ρ $ ← − Y or γ := PPRF.Eval(k, n * ). We use γ to check whether the ticket t is a valid AEAD ciphertext. That is, if AEAD.Dec(γ , t , n * ) = ⊥, the adversary forges for a real key and invokes event X 0.1 . In this case, we return 1 to the challenger. If, on the other hand, AEAD.Dec(γ , t , n * ) = ⊥, the adversary forges for a random key and invokes event X 0.2 . In this case, we return 0 to the challenger. This implies that any adversary that can distinguish Game 0.1 from Game 0.2, can be transformed into a successful adversary B PPRF1 breaking the security of the PPRF. Bounding Pr[X 0.2 ] We conclude the proof of the lemma by showing that any adversary invoking event X 0.2 in Game 0.2 breaks the INT-CTXT security of AEAD. To this end, consider the following adversary B AEAD1 . Construction of B AEAD1 B AEAD1 proceeds exactly like the challenger in Game 0.2 but we use the AEAD challenger as the encryption/decryption procedure with respect to the ticket associated to the j-th query. As soon as the adversary issues the j-th O Dec or O Test query for some ticket t, B AEAD1 outputs t to its AEAD challenger. Note that t is the first valid forgery with n > μ by A due to our changes in Game 0.1 and note that t is encrypted under a uniformly random key ρ (which is perfectly hidden from the adversary) due to our changes in Game 0.2. Hence the AEAD challenger accepts t as a valid forgery, and we have Summing up all probabilities proves the lemma.
Continuing with our proof, we now have that Now, after proving the above lemma, we return to our original sequence of games. Using Lemma 1, we can now assume that the adversary never forges a ticket t is oblivious to A until an abort occurs, we have Game 3. This game is identical to Game 2, except that at the beginning of the game we compute κ ν = PPRF.Eval(k, ν) and then k := PPRF.Punct(k, ν). Furthermore, we replace algorithm PPRF.Eval with the following algorithm F 3 : Everything else works exactly as before. Note that we have simply implemented algorithm PPRF.Eval in a slightly different way. Since PPRF is invariant to puncturing, the fact that κ ν was computed early, immediately followed by k := PPRF.Punct(k, ν), is invisible to A. Hence, Game 3 is perfectly indistinguishable from Game 2, and we have Game 4. This game is identical to Game 3, except that the challenger now additionally picks a random key ρ $ ← − Y from the range of the PPRF. Furthermore, we replace algorithm F 4 with the following algorithm F 4 : Everything else works exactly as before. We will now show that any adversary that is able to distinguish Game 3 from Game 4 can be used to construct an adversary B PPRF2 against the na-rand-security of the PPRF. Concretely, we have and outputs ν to its PPRFchallenger, which will respond with a punctured key k := PPRF.Punct(k, ν) and a value γ , where either γ = PPRF.Eval(k, ν) or γ $ ← − Y. Now B PPRF2 simulates Game 4, except that it uses the following function F in place of F 4 .
Eventually, A will output a guess b * . B PPRF2 forwards this bit to the PPRF-challenger.
This proves the claim.
Game 5. This game is identical to Game 4, except that we raise an event abort AEAD2 , abort the game, and output a random bit b * $ ← − {0, 1}, if the adversary A ever queries O Test (t) for a ticket t = (t , ν) = t ν (i.e., t differs from the ν-th ticket in the first position), but AEAD.Dec(ρ, t , ν) = ⊥, where ρ = F 4 (k, ν). We have and we claim that we can construct an adversary B AEAD2 on the INT-CTXT-security of the AEAD with advantage at least Pr[abort AEAD2 ]. Construction of B AEAD2 B AEAD2 proceeds exactly like the challenger in Game 5, except that it uses its challenger from the AEAD security experiment to create ticket t ν . To this end, it outputs the tuple (s ν , ν) for some s ν $ ← − S to the AEAD challenger. The AEAD challenger responds with t ν := AEAD.Enc(ρ, s ν , ν), computed with an independent AEAD key ρ. Finally, B AEAD2 defines the ticket as t ν = (t ν , ν). Apart from this, B AEAD2 proceeds exactly like the challenger in Game 5.
Whenever the adversary A makes a query O Test (t) with a ticket t = (t , i) with i = ν, then we abort, due to the changes introduced in Game 2. If it queries O Test (t) with t = (t , ν) such that t = t ν , then B AEAD1 responds with ⊥ and outputs the tuple (t , ν) to its AEAD challenger. With probability Pr[abort AEAD2 ] this ticket is valid, which yields Game 6. This game is identical to Game 5, except that when the adversary queries O Test (t ν ), then we will always answer with a random value, independent of the bit b.
More precisely, recall that we abort if the adversary queries O Test (t), t = (t , ν) such that t = t ν , due to the changes introduced in Game 5. If the adversary queries O Test (t ν ), then the challenger in Game 5 uses the bit b $ ← − {0, 1} sampled at the beginning of the experiment as follows. If b = 1, then it returns the session key s ν . Otherwise, a random r ν $ ← − S is returned. In Game 6, the challenger samples another random value s ν $ ← − S at the beginning of the game. When the adversary queries O Test (t ν ), then if b = 1 the challenger returns s ν . Otherwise, it returns a random r ν $ ← − S. Note that in either case the response of the O Test (t ν )-query is a random value, independent of b. Therefore, the view of A in Game 6 is independent of b. Obviously, we have We will now show that any adversary who is able to distinguish Game 5 from Game 6 can be used to construct an adversary B AEAD3 against the IND-CPA-security of AEAD. Construction of B AEAD3 Recall that the key used to generate ticket t ν is ρ = F 4 (k, ν). By definition of F 4 , ρ is an independent random string chosen at the beginning of the security experiment. This enables a straightforward reduction to the IND-CPA-security of the AEAD.
B AEAD3 proceeds exactly like the challenger in Game 6, except for the way the ticket t ν is created. B AEAD3 computes ρ ν = F 4 (k, ν). Then it outputs (s ν , s ν , ν) to its challenger, which returns where ρ is distributed identically to ρ ν and b is the hidden bit used by the challenger of the AEAD. Apart from this, B AEAD3 proceeds exactly like the challenger in Game 6. Eventually, A will output a guess b * . B AEAD3 forwards this bit to its challenger. Note that if b = 0, then the view of A is perfectly indistinguishable from Game 5, while if b = 1 then it is identical to Game 6. Thus, we have By summing up probabilities from Game 0 to Game 6, we obtain

Composition with the TLS 1.3 Resumption Handshake
In this section we show how to compose a 0-RTT session resumption protocol with the TLS 1.3 resumption handshake, also called pre-shared key (PSK) mode. We start with a brief section on building blocks used in TLS. Next we recap the multi-stage key exchange model, and finally we describe our protocol composition and prove its security.

Building Blocks and Security Assumptions
Before we can describe our construction, we need to introduce a few more primitives and their respective security notions. The first two notions cover collision resistant hash functions and pseudorandom functions. Unkeyed hash functions H : {0, 1} * → {0, 1} λ , as deployed in practice, always imply the existence of collisions, as the range of H is smaller than the domain. Instead of assuming that no efficient adversary is able to find collisions, we follow the approach by Rogaway [53] and assume that it is hard to efficiently construct an adversary that can efficiently find collisions.

Definition 11.
A hash function H : {0, 1} * → {0, 1} λ that maps arbitrary finite-length bit strings to strings of fixed length λ is called collision resistant if we cannot efficiently construct an efficient adversary A whose advantage

Adv collision
is non-negligible.  [40,41] which utilizes the HMAC construction [6,39] as a core building block. The HKDF follows the extract-then-expand paradigm, that is, it employs special functions to extract and expand keys. The extract function Ext(salt, src) takes a (potentially fixed) salt salt and a source key material src as input and computes a pseudorandom key as output. The expand function Exp(key, ctxt) takes a pseudorandom key key and a context ctxt as input and computes a new pseudorandom key. Formally, the expand function also takes an additional length parameter, determining the length of the computed key, as input. We omit this parameter for simplicity and assume that the length is equal to the security parameter λ unless stated otherwise.
For our security proof in Sect. 4.3, we rely on the assumption that both functions Ext and Exp are pseudorandom functions [41]. Additionally, we rely on the HMAC(0, $)-$ assumption introduced in [28]. This assumption states that is negligible in λ.

Multi-stage Key Exchange
The TLS 1.3 protocol establishes multiple keys during execution. Some of these keys are used to encrypt parts of the communication during protocol execution, while others are used for external (application layer) purposes only. To formally analyze such a multi-key protocol, we use an extension [28] of the multi-stage key exchange model introduced by Fischlin and Günther [27], which has been used to prove security of various drafts of the TLS 1.3 protocol. Their model allows dividing the key exchange protocols into so-called stages, where each stage yields a key that supports a certain level of security.
Since we only consider session resumption protocols in this work, we will only briefly describe the relevant parts of the model. See [28] for a more comprehensive description of the model. Changes to the Model The model is taken verbatim from [28], except for the following minor changes.
-We removed all model features that are unnecessary for proving TLS 1.3 in its preshared key mode, composed with our generic 0-RTT session resumption protocol. Namely, we removed key dependent aspects (TLS 1.3 supports key independence), authentication levels other than mutual authentication (our protocol provides mutual authentication), and replayable stages (our protocol is non-replayable across all stages). -We modified the corruption query. Instead of revealing the pre-shared keys of a server, we equip each server with a long-term key k which is used to issue and open tickets. Corruption of a server will leak the current state of the server's secret key k. Due to the nature of our 0-RTT session resumption protocol introduced earlier, the server's secret key will change with each protocol execution. Each session is associated with a key index d for the pre-shared secret pss and its unique identifier psid. The challenger maintains vectors pss U,V and psid U,V of created pre-shared secrets, where the d-th entry is the d-th pre-shared secret (resp. d-th identifier) shared between users U and V . We write pss U,V,d (resp. psid U,V,d ) as shorthand for the d-th entry of pss U,V (resp. psid U,V ).

Protocol-Specific and Session-Specific Properties
A session is represented by a tuple σ and comprises of the following information: label ∈ U × U × N: The unique session label.
id ∈ U: The identity of the session owner.
pid ∈ U: The identity of the intended communication partner.
role ∈ {initiator, responder}: The role of the session owner.
execstate ∈ {RUNNING ∪ ACCEPTED ∪ REJECTED}: The state of execution where The state is set to accepted i if the session accepts the i-th key. It is set to running i if the session proceeds with the protocol after accepting the i-th key. It is set to rejected i if the session rejects the i-th key (we assume that a session does not continue in this case). The default value is running 0 . Each session is stored and maintained in a session list SList. If an incomplete session tuple σ is added to the session list SList, we set all empty values to their defined default values. For a more convenient notation, we write label.sid to denote the entry sid in the tuple σ with the unique label label in SList.
Following Günther et al. [28], we define two distinct sessions label, label to be partnered if the session's session identifiers are equal (i.e., label.sid = label .sid = ⊥). Additionally, we require for correctness that two sessions are partnered if the sessions have a non-tampered joint execution and both parties have reached an acceptance state. This means that a protocol is correct if, in the absence of an adversary, any two sessions executing the protocol are partnered upon acceptance.

Adversary Model
We consider a probabilistic polynomial-time adversary A that controls the communication between all parties, and is capable of intercepting, injecting, and dropping messages. We capture adversarial behavior where the adversary trivially loses via a flag lost initialized to lost := false. The adversary has access to the following queries: -NewSecret(U, V, d, psid): This query generates a new pre-shared secret pss with identifier psid. The secret pss is the d-th secret shared between users U and V . If psid is a used identifier for an already registered secret or if the d-th secret between U and V has already been set, return ⊥. Otherwise, sample the secret pss uniformly at random from the pre-shared secret space and store pss in pss U,V and pss V,U (as well as psid in psid U,V and psid V,U ) as the d-th entry. If b test = 0, sample a random session key K $ ← − D. Else set K := label.key i to the real session key. If USE i = internal, set label.key i := K (i.e., we replace the internally used session key with the random and independent test key K ). Additionally, if a partnered session label exists, we set label .tested := true if the i-th key was accepted. Furthermore, we also set label .key i := label.key i if USE i = internal. Finally, return K .

Match Security
The notion of Match security ensures that session identifiers properly identify partnered sessions in the following sense: Multi-stage Security The notion of MultiStage security ensures that, for each stage, keys are indistinguishable from randomly sampled keys in the multi-stage setting. is negligible in λ.

Composition and Security
In this section we show how to generically compose a 0-RTT session resumption protocol with the TLS 1.3 resumption handshake and prove the composition's security in the multistage key exchange model, achieving a stage-1-forward-secret resumption handshake. In contrast, without such a session resumption protocol it is only possible to show that the TLS 1.3 resumption handshake only achieves stage-3 forward-secrecy via an additional execution of a Diffie-Hellman key exchange [28].
Integrating a 0-RTT Session Resumption Protocol into TLS 1.3 As explained in the Introduction, the TLS 1.3 standard allows the server to unilaterally choose a mechanism for issuing tickets and serving resumption handshakes. The only interoperability require-ment is correctness, i.e. when resuming a session, the server should correctly compute the relevant resumption secret and use it as prescribed by the key schedule. The client is generally not aware of the resumption mechanism in use by the server; the client merely receives an opaque ticket, and sends it to the server when resuming. In our construction, tickets are computed using a 0-RTT session resumption protocol. Let Resumption = (Setup, TicketGen, ServerRes) be a 0-RTT session resumption protocol. The server uses k $ ← − Setup(1 λ ) to compute its long-term key k for ticket encryption. Tickets are computed as ticket = TicketGen(k, RMS||N T ) and can be opened using the ServerRes algorithm.
Note that by computing (RMS||N T , k ) := ServerRes(k, ticket) a modified secret key of the server k is produced. Replacing k := k guarantees forward secrecy if Resumption is a 0-RTT-SR-secure protocol. That is, forward secrecy is invoked immediately after the ticket has been processed on the server side. Should k leak at a later point in time, the resumption master secret RMS (and all keys derived from it) will not be compromised. On Sending Multiple PSKs TLS 1.3 allows the client to send multiple pre-shared key identifiers in its first message if no 0-RTT data is sent. If, however, 0-RTT data is sent, the standard explicitly states that the handshake will be aborted unless the server picks the first pre-shared key identifier from the client's list [51, §4.2.10, §4.2.11]. This restriction exists to ensure that the early data only has to be encrypted under one pre-shared key chosen by the client. In this work we only allow the client to send one pre-shared key identifier, as we are specifically interested in the 0-RTT mode. Should a client choose not to send 0-RTT data, then previous analyses of the TLS 1.3 handshake protocol apply [28]. Hence, our change leads to a cleaner protocol and is purely cosmetic. Protocol Description In the following, we describe our modified version of the TLS 1.3 resumption handshake. We assume that client and server have performed a prior full handshake, allowing them to agree on a pre-shared secret. The pre-shared secret is denoted as resumption master secret RMS. The client stores RMS (and an associated nonce N T ) alongside a server-issued ticket ticket. The ticket ticket was computed by the server using its secret key k and holds RMS and N T as contents.
We provide an illustration of the protocol in Fig. 4. For readability, the figure slightly deviates from the message format in the TLS 1.3 specification. In the figure we separated the binder value Fin 0 and the ticket message from the ClientHello message, while in the standard both are included in the ClientHello message. Outside of the figure, we consider Fin 0 and ticket as a part of the ClientHello.
The following messages are exchanged during protocol execution: ClientHello: The ClientHello message is the first message sent by the client. It contains the protocol version, a random nonce N C chosen by the client, a list of supported cryptographic primitives and extensions, and a pre-shared key identifier. Additionally, it contains ticket which is an encryption of the resumption master secret RMS and the ticket nonce N T . Fin 0 : The binder value Fin 0 comprises of an HMAC over a (partial) ClientHello message to ensure integrity. ServerHello: The ServerHello message contains a server nonce N S , a selected protocol version, extensions, and supported cryptographic primitives.
Fin S : The Fin S message comprises of an HMAC over the protocol transcript up to this point and is encrypted under the server handshake traffic key. Fin C : The Fin C message comprises of an HMAC over the protocol transcript up to the Fin S message and is encrypted under the client handshake traffic key.
More information on the computation of the hashed finished messages is given in Appendix B. Security Analysis Preliminaries In the following, we will analyze the security of our modified TLS 1.3 protocol in the multi-stage key exchange model in its pre-shared secret mode. That is, we will show that our protocol satisfies both Match and MultiStage security. We start by discussing some preliminaries for both proofs. The vector of protocolspecific properties (M, USE) looks as follows: -M = 5: The number of stages is equal to five (cf. Fig. 4), deriving traffic keys tk ets , (tk chts , tk shts ), (tk cats , tk sats ), the exporter master secret EMS, and the resumption master secret RMS. -USE = (external, internal, internal, external, external): The handshake traffic keys (tk chts , tk shts ) are used to protect internal protocol messages, while all other keys are only used outside of the protocol.
We define session matching with the following session identifiers (implicitly) consisting of all messages sent in each stage: 3 , "ems") sid 5 = (sid 4 , "rms") Note that neither "ems," nor "rms" contributes to the established key and they are instead included to ensure distinct session identifiers across stages. We set the contributive identifier of Stage 2 to cid 2 = (ClientHello) after the client has sent (resp. after the server has received) the ClientHello message and set, on sending (resp. receiving) the ServerHello message the contributive identifier to cid 2 = sid 2 . The other contributive identifiers are set to cid i = sid i (for stages i ∈ {1, 3, 4, 5}) after the respective stage's session identifier was set.  where n s is the maximum number of sessions.
Proof. In order to prove the Match security of TLS13wRES we need to show that the five properties of Match security hold for TLS13wRES.
1. Sessions with the same session identifier for some stage hold the same key at that stage. This property holds, as all session identifiers contain the ClientHello message which fixes the ticket and thus the resumption master secret RMS. The RMS in turn determines all following keys, guaranteeing that sessions with the same identifier hold the same key at each stage. 2. Sessions with the same session identifier for some stage share the same contributive identifier at that stage. This property holds trivially for Stage 1 as sid 1 = cid 1 . For all other stages i ∈ {2, 3, 4, 5}, the contributive identifier is set to its final value cid i := sid 2 as soon as the sender and receiver set the session identifier.

Sessions are partnered with the intended participant, and share the same key index.
This property holds as honest senders only use a legitimate ticket ticket (included in the ClientHello message), which ensures that both parties agree on the same partner and key index. 4. Session identifiers do not match across different stages. This property holds trivially, as sid 1 , sid 2 , sid 3 include distinct non-optional messages and sid 4 , sid 5 include separating identifier strings. 5. At most two sessions have the same session identifier at any stage. Note that each session identifier includes the ClientHello message and hence the client nonce N C of bit length λ. The first session identifier is only set after the sever has processed the ClientHello (and thus the ticket ticket), implying that the server's secret key has been replaced before accepting the Stage 1 session key. Hence, replaying the ClientHello message to the server cannot lead to an accepting stage in a different session, but will incur protocol abortion. A collision can hence only occur if a third party picks the same random nonce N C . We can upper-bound the collision probability by n s · 2 −λ , where n s is the maximum number of sessions.
MultiStageSecurity We proceed with proving MultiStage security of our construction. Our proof follows the proof of TLS 1.

The resumption master secret is derived from a 0-RTT session resumption protocol
Resumption, requiring an additional reduction to the security of Resumption. This way we can achieve forward secrecy for all messages in the very first stage of the resumption handshake, by only modifying the key management on the server side and without any changes to clients or the standardized TLS 1.3 protocol flow.
where n s is the maximum number of sessions.
Proof. We will conduct this proof in a sequence of games between a challenger C and an adversary A. We start with an adversary playing the MultiStage security game. Over a sequence of hybrid arguments, we will stepwise transform the security game to a game where the Test-query is independent of the challenge bit b test . The claim then follows from bounding the probability of distinguishing any two consecutive games. By Adv i we denote A's advantage in the i-th game. Game 1. This game is identical to Game 0, except that we restrict the adversary to a single Test query. We can apply the hybrid argument by Dowling et al. [23,Appendix A] which reduces the adversary's advantage in a five stage protocol by a factor of at most 5n s , where n s is the number of sessions. The hybrid argument essentially consists of 5n s hybrids (n s possible Test queries in each of the five stages) where the first j ∈ [5n s ] tested keys are replaced with random keys. This allows implicitly guessing the session to be tested by the adversary. This argument also implicitly guesses which session label (which can be either a client or a server session) will be tested by the adversary, allowing us to identify it in advance. In conclusion, we now have Game 2. This game is identical to Game 1, except that we abort if during protocol execution the same hash value is computed for two distinct inputs. Should this happen, we can construct an adversary B 1 that breaks the collision resistance of the hash function H by outputting the two distinct input values to the challenger of the collision resistance game. We can thus bound the probability of aborting as Game 3. This game is identical to Game 2, except that we now guess the index of the pre-shared secret used within the tested session amongst the maximum number of pre-shared secrets. If the tested session uses a different pre-shared secret, we abort the game. As the guess is oblivious to the adversary until an abort occurs, we have where n p is the maximum number of pre-shared secrets. Note that a correct guess allows us to identify the pre-shared secret pss U,V,d in the tested session and hence the intended partner of the tested session. Without loss of generality let us assume that U is the client session and V is the server session.

Game 4.
In this game, we modify the output of the ServerRes function. To be precise, we proceed as in Game 3, but replace the output of ServerRes for both the owner of the tested session and its intended partner with a random value RMS||N T . We will now show that any adversary that is able to distinguish Game 3 from Game 4 can be used to construct an adversary against the 0-RTT-SR security of Resumption. Concretely, we have

Construction of B 2 against Resumption
The adversary behaves like the challenger in Game 3, except for all interactions involving the server V associated to the tested session, which we simulate as follows. At first, the adversary initializes the 0-RTT-SR challenger and receives a sequence of tickets t 1 , . . . , t μ . It tests the first ticket by invoking O Test (t 1 ) → γ ∈ {s 1 , r 1 } and immediately corrupts the challenger to receive the challenger's secret key k. Note that this secret key k has been modified by the challenger and thus cannot be used to open ticket t 1 .
As we are now in possession of the secret key k, we are able to simulate all sessions but the one using ticket t 1 . We utilize ticket t 1 as the ticket sent within the ClientHello message of the tested session between client U to server V . Note that we can perfectly simulate all queries of A, since it is not allowed to query Reveal for the tested session or its partner. Likewise, it can query Corrupt only after the keys have been accepted by U and V , implying replacement of the server's secret key k. If the adversary issues a corrupt query on the tested server, we are able to puncture the server's secret key in accordance with all queries issued in other sessions of the server. The invariance to puncturing of Resumption guarantees us, that this (possibly wrong order of) key replacements cannot be efficiently detected by the adversary.
Eventually, the adversary will output a guess b which we forward to the challenger. If the challenger bit b = 0, we perfectly simulate Game 3 (i.e., s 1 is the actual expected output) and if b = 1, we perfectly simulate Game 4 (i.e., r 1 is a uniformly random output). This proves the claim.
Note that the security of Resumption ensures that the adversary cannot learn the value RMS for the tested session or its partner, even when corrupting immediately after the ClientHello message and the ticket have been processed. This ensures the achievement of forward secrecy in Stage 1.
The next sequence of games aims to replace all traffic keys with random values. That is, we will step by step replace the outputs of the functions Ext and Exp with random values.
Game 5. This game is identical to Game 4, other than replacing Exp(RMS, ·) with a lazily-sampled random function, such that the pre-shared key PSK is replaced by a random value PSK in the tested session. Any adversary that is able to distinguish this replacement can be used to construct an adversary that breaks the pseudorandomness of the HKDF. We have

Construction of B 3 against Exp
The adversary B 3 behaves exactly like in Game 4, but evaluates Exp(RMS, ·) via the PRF evaluation oracle provided by the PRF challenger.
Since the adversary A is not able to learn the real resumption master secret RMS by corrupting the tested session (cf. Game 4), it is only known to be a uniformly random value. Hence, B 3 perfectly simulates Game 4 if the PRF oracle computes Exp and perfectly simulates Game 5 if the PRF oracle is a random function, which proves the claim.
Game 6. This game is identical to Game 5, other than replacing Ext(0, PSK) with a random value ES in the tested and partnered session. Recall that Ext(x, y) = HMAC(x, y). Any adversary that is able to distinguish this replacement can be used to break the HMAC(0, $)-$ assumption of Ext.

Construction of B 4 against Ext
The HMAC assumption states that no probabilistic polynomial-time adversary is able to distinguish HMAC(0, x) from y $ ← − {0, 1} λ , for uniformly chosen inputs x $ ← − {0, 1} λ . B 4 behaves exactly like the challenger in Game 5, but uses the value Ext(0, PSK) as challenge. If Ext(0, PSK) = HMAC(0, x) for x ∈ {0, 1} λ it perfectly simulates Game 5 and if Ext(0, PSK) = y for y ∈ {0, 1} λ , it perfectly simulates Game 6. In conclusion, we have Game 7. This game is identical to Game 6, except that we replace all evaluations Exp(ES, ·) by a lazily-sampled random function. In particular, this yields a random early traffic secret ets, a random binder key bk, and a random expanded early secret dES.
Note that the hash value for deriving the early traffic secret is dependent on the session identifier. The changes introduced in Game 2 guarantee that the hash value does not collide across non-partnered users. Furthermore, all three values for the second input of the Exp function are distinct labels, ensuring distinct outputs.
Any adversary that is able to recognize this change can be used to construct an adversary against the pseudorandomness of the HKDF in the same fashion as done in Game 5, leading to a bound |Adv 7 − Adv 6 | ≤ Adv rand B 5 ,Exp (λ).
Game 8. This game is identical to Game 7, other than replacing Exp(ets, ·) with a lazily-sampled random function, yielding a random value tk ets for the early traffic key in the tested and partnered session. Following the same arguments as in Game 5, we can bound Game 9. This game is identical to Game 8, other than replacing Exp(bk, ·) with a lazily-sampled random function, yielding a random value fk 0 for the early finished key in the tested and partnered session. Following the same arguments as in Game 5, we can bound Game 10. This game is identical to Game 9, other than replacing Ext(ES, 0) with a lazily-sampled random function, yielding a random HS in the tested and partnered session. Following the same arguments as in Game 5, we can bound |Adv 10 − Adv 9 | ≤ Adv rand B 8 ,Ext (λ).
Game 11. This game is identical to Game 10, except that we replace all evaluations Exp(HS, ·) by a lazily-sampled random function. In particular, this yields a random client handshake traffic secret chts (resp. server handshake traffic secret shts), and a random expanded handshake secret dHS. Note that the hash value for deriving the handshake traffic secrets is dependent on the session identifier. The changes introduced in Game 2 guarantee that the hash value does not collide across non-partnered users. Furthermore, all three values for the second input of the Exp function are distinct labels, ensuring distinct outputs.
Game 12. This game is identical to Game 11, other than replacing Exp(chts, ·) with a lazily-sampled random function, yielding a random client handshake traffic key tk chts and a random client finished key fk C in the tested and partnered session. Following the same arguments as in Game 5, we can bound |Adv 12 − Adv 11 | ≤ Adv rand B 10 ,Exp (λ).
Game 13. This game is identical to Game 12, other than replacing Exp(shts, ·) with a lazily-sampled random function, yielding a random server handshake traffic key tk shts and a random server finished key fk S in the tested and partnered session. Following the same arguments as in Game 5, we can bound |Adv 13 − Adv 12 | ≤ Adv rand B 11 ,Exp (λ).

Game 14.
This game is identical to Game 13, other than replacing Ext(MS, 0) with a lazily-sampled random function, yielding a random MS in the tested and partnered session. Following the same arguments as in Game 5, we can bound Game 15. This game is identical to Game 14, except that we replace all evaluations Exp(MS, ·) by a lazily-sampled random function. In particular, this yields a random client application traffic secret cats (resp. server application traffic secret sats), a random exporter master secret EMS, and a random new resumption master secret RMS . Note that the hash value for deriving the application traffic secrets is dependent on the session identifier. The changes introduced in Game 2 guarantee that the hash value does not collide across non-partnered users. Furthermore, all four values for the second input of the Exp function are distinct labels, ensuring distinct outputs.
Following the same arguments as in Game 5, we can bound Game 16. This game is identical to Game 15, other than replacing Exp(cats, ·) with a lazily-sampled random function, yielding a random client application traffic key tk cats in the tested and partnered session. Following the same arguments as in Game 5, we can bound Game 17. This game is identical to Game 16, other than replacing Exp(sats, ·) with a lazily-sampled random function, yielding a random server application traffic key tk sats in the tested and partnered session. Following the same arguments as in Game 5, we can bound In Game 17, all keys tk ets , tk chts , tk shts , tk cats , tk sats , EMS, and RMS derived in the tested session are chosen uniformly at random. Observe that (contrary to standard TLS session resumption) the security of the Resumption protocol ensures that replaying the ClientHello message to multiple server sessions does not cause multiple sessions to be partnered to the original client session. We hence achieve replay protection across all stages of the protocol. All sessions that are not partnered with the tested session derive different traffic keys as explained in Games 7, 11, and 15. Therefore, the view of A in Game 17 is independent of b test . Obviously, we have By summing up probabilities from Game 0 to Game 17, we conclude the proof.
Remark on the Optional Diffie-Hellman Key Exchange TLS 1.3 allows including an optional Diffie-Hellman Key Exchange (DHKE) in its resumption handshake. This additional key exchange has an important function in the TLS 1.3 Resumption Handshake. Namely, including the Diffie-Hellman key into the derivation of the handshake key, will achieve stage-3-forward-secrecy as shown by [28,Theorem 5.4]. We deliberately excluded this optional key exchange from our analysis, as the multi-stage key exchange model does not capture any property of the DHKE beyond the forward secrecy aspect, which we already obtain through other means. Hence, including the DHKE as computational step does not offer any security benefits (within this model). We stress that the optional DHKE can be added to the resumption handshake (as done in TLS 1.3) if wanted, without any loss of security.

A PPRF with Short Secret Keys from Strong RSA
In order to instantiate our generic construction of forward-secure and replay-resilient session resumption protocol with minimal storage requirements, which is the main objective of this paper, it remains to construct suitable PPRFs with minimal storage requirements and good computational efficiency. Note that a computationally expensive PPRF may void all efficiency gains obtained from the 0-RTT protocol. In this section we describe a PPRF based on the Strong RSA (sRSA) assumption with secret keys that only consist of three elements, even after an arbitrary number of puncturings. More precisely, a secret key consists of an RSA modulus N , an element g ∈ Z N and a bitfield r , indicating positions where the PPRF was punctured. The secret key size is linear in the size of the PPRF's domain, since the bitfield needs to be of the same size as the domain (which is determined at initialization, and does not change over time). Hence, the PPRF's secret key size is independent of the number of puncturings. Moreover, for any reasonable choice of parameters, the bitfield is only several hundred bits long, yielding a short key in practice. Servers can use many instances in parallel with the instances sharing a single modulus, so it is only necessary to generate (and store) the modulus once, at initialization.
Since our primary objective is to provide an efficient practical solution for protocols such as TLS 1.3 0-RTT, the PPRF construction described below is analyzed in the random oracle model [7]. However, we note that we use the random oracle only to turn a "search problem" (sRSA) into a "decisional problem" (as required for a pseudorandom function). Therefore, we believe that our construction can be lifted to the standard-model via standard techniques, such as hardcore predicates [8,10,31]. All of these approaches would yield less efficient constructions, and therefore are outside the scope of our work. Alternatively, one could formulate an appropriate "hashed sRSA" assumption, which would essentially boil down to assuming that our scheme is secure. Therefore, we consider a random oracle analysis based on the standard sRSA problem as the cleanest and most insightful approach to describe our ideas. Idea Behind the Construction The construction is inspired by the RSA accumulator of Camenisch and Lysyanskaya [15]. The main idea is the following. Given a modulus N = pq, a value g ∈ Z N , and a prime number P, it is easy to compute g → g P mod N , but hard to compute g P → g mod N without knowing the factorization of N .
In the following let p i be the i-th odd prime. That is, we have ( p 1 , p 2 , p 3 , p 4 , . . .) = (3, 5, 7, 11, . . .). Let n be the size of the domain of the PPRF. Our PPRF on input produces an output of the form H (g p 1 ·...· p n / p ), where H is a hash function that will be modeled as a random oracle in the security proof. Note that g is raised to a sequence of prime numbers except for the -th prime number. As long as we have access to g, this is easy to compute. However, if we only have access to g p instead of g, we are unable to compute the PPRF output without knowledge of the factorization of N . This implies that by raising the generator to certain powers, we prevent the computation of specific outputs. We will use this property to puncture values of the PPRF's domain.

Formal Description of the Construction
Definition 16. Let p, q be two random safe primes of bitlength λ/2 and let N = pq. Let y $ ← − Z N . We define the advantage of algorithm B against the Strong RSA Assumption [3] as The following lemma, which is due to Shamir [55], is useful for the security proof of our construction.

Lemma 2.
There exists an efficient algorithm that, on input Y, Z ∈ Z N and integers e, f ∈ Z such that gcd(e, f ) = 1 and Z e ≡ Y f mod N , computes X ∈ Z N satisfying X e = Y mod N .  N , g, r ). The primes p, q are discarded. Output is k.
It is straightforward to verify the correctness of Construction 2 and that it is invariant to puncturing in the sense of Definition 6.

Security Analysis
In the following we will prove that Construction 2 is pseudorandom at punctured points, if H is modeled as a random oracle [7] and the Strong RSA assumption holds. to be the product of the first n odd primes, except for those contained in X . B defines r = (r 1 , . . . , r n ) as , and then sets k := (N , y, r ). Let P * := i∈X p i be the product of the first n odd primes contained in X . To show that this is a properly distributed punctured key, we have to show that there exists g ∈ Z N such that g P * = y mod N , and that y is distributed as if g was uniform over Z N . To this end, note that N = pq is a product of two safe primes p = 2 p + 1 and q = 2q + 1 with p , q prime. Furthermore, we have p , q p n , because p n is the n-th odd prime for polynomially-bounded n, which implies gcd(ϕ(N ), g P * ) = 1, where ϕ is Euler's Phi-function. Hence, the map y → y 1/g P * is a permutation over Z N , and therefore there exists an element g ∈ Z N such that g = y 1/P mod N .
Since y is uniformly random, g is uniformly distributed, too. Hence, k := (N , y, r ) for all x i ∈ X , or whether the h i are uniformly random. Since H is a random oracle, this is perfectly indistinguishable for A, unless at some point it queries the random oracle on input a ∈ Z N such that there exists i ∈ [ ] with a = g P x i mod N . Since A has advantage Adv na-rand A,PPRF (λ), this must happen with probability at least Adv na-rand A,PPRF (λ) at some point throughout the security experiment.
Whenever A outputs a value a ∈ Z N in order to query for H (a) P , a, y).
The algorithm returns X such that X e = Y mod N . Thus, (X, e) = (X, p x i ) is a valid solution to the Strong RSA instance (N , y). Note that if A is efficient, then so is B, and that the reduction is tight.

Efficiency Analysis
Note that a server is able to create multiple instances of our construction to serve more tickets than one instance is able to. Using multiple instances allows using smaller exponents, but in return, the storage cost grows linearly in the number of instances.
Serving a ticket requires two exponentiations, one for computing the key and one for puncturing. Computing the key requires raising the state g to the power of p∈S p for some subset of primes S. Puncturing requires exponentiating by a single prime. Therefore, all exponentiations feature exponents smaller than n i=1 p i . We start by comparing to 2048-bit RSA, which according to the NIST key size recommendations [4] corresponds to "112-bit security", before comparing to larger RSA key sizes.

Worst-Case Analysis
We compare to standard exponentiation in the group, i.e. raising to the power of d ∈ N, where log d ≈ 2048. For puncturing to be comparable in the worstcase, we require log n i=1 p i ≤ 2048. Choosing p i to be the i-th odd prime yields n ≤ 232. An economic server may store only one 2048-bit group element for the current state, and a bitfield indicating which of the 232 primes have been punctured, requiring 2280 bits in total. This allows serving 232 tickets, resulting in a storage cost of 1.22 bytes per ticket. Alternatively, a standard session cache would require 112·232 = 25984 bits to serve those 232 tickets, assuming symmetric keys of 112 bits. Therefore, our construction decreases storage size compared to a Session Cache by a factor of 25984/2280 = 11.4.
Averaged Analysis Note that in the above worst-case analysis we consider an upper bound on the exponentiation cost. That is, we guarantee that a puncturing and key derivation operation is never more expensive than a full exponentiation. Indeed, the first key computation raises to the power of p 1 · . . . · p n / p , i.e. to the product of n − 1 primes. However, subsequent key calculations raise to smaller powers, i.e. to the product of n − 2 primes, then n − 3, and so on. Therefore, serving tickets arriving later is much cheaper than serving the first. In particular in settings where a server uses many PPRF instances in parallel, in order to deal with potentially thousands of simultaneously issued tickets, an alternative and more reasonable efficiency analysis considers the average cost of serving a ticket to be comparable to exponentiation in the group. In the worst-case, primes are punctured in order, so p n is included in the exponent in all key derivations, p n−1 in all derivations except the last, etc. Each prime is also used once for puncturing. Requiring n i=1 i · log( p i ) ≤ n · 2048 yields a maximum n = 387, and a savings factor of 112 · 387/(2048 + 387) = 17.8. The required storage is therefore 0.79 bytes per ticket.

Considering Other Security Parameters and Efficiency Requirements
Generalizing the above calculations, Table 1 gives concrete parameters for various security levels, following the NIST recommendations for key sizes [4]. Larger key sizes result in larger reductions in storage, especially when requiring average cost similar to exponentiation in the RSA group. We also show the improvement factor in storage when relaxing the above heuristic choice that serving a ticket must not cost more than one full RSAexponentiation, by considering the case where serving a ticket is cheaper on average than 5 group exponentiations. This demonstrates that the proposed PPRF can yield very significant storage savings in general cryptographic settings, while keeping computation costs on the same order of magnitude as common public key operations. In the context of TLS, however, we expect most server operators would prefer parameters that keep processing time comparable to a single exponentiation. We emphasize that the improvement factor in storage is determined at initialization time, and is deterministic rather than probabilistic. The largest prime used in exponentiations determines how many tickets  [4]. Both savings factors denote the reduction in server-side storage required when using Construction 3. Column 3 denotes the reduction in storage achieved under the requirement that serving a single ticket is always cheaper than an exponentiation in the RSA group of respective key size. Column 4 denotes the reduction in storage achieved under the requirement that the average cost for serving a ticket is cheaper than a single exponentiation. Column 5 denotes the reduction in storage achieved under the requirement that the average cost for serving a ticket is cheaper than 5 group exponentiations. are served using a single group element. The worst-case and average-case refer to the processing time, not to the savings in storage.
Additional Storage for the Primes The server will also need to store the first n primes, but this requires negligible additional storage. Storing the primes requires on the order of magnitude of ten kilobytes, where we expect typical caches to use many megabytes. For the minimal storage requirement, we consider 2048-bit RSA while requiring that the worst case puncturing time is cheaper than group exponentiation. In this case n = 232 and p n = 1471, therefore all primes fit in 32-bit integers. Storing all the primes would require at most 4 · 232 = 928 bytes. The largest value of n for the parameter choices presented in this work is n = 9704, for the "average cheaper than 5 exponentiations" case with 15360-bit RSA. p 9704 = 101341. The required additional storage is therefore 4 · 9704 = 38,816 bytes. To reiterate, we expect typical caches to use many megabytes.

Concrete Benchmarks
We now give concrete performance estimates for this construction, using OpenSSL [58]. OpenSSL is a well-known production-grade library that implements the TLS and SSL protocols, as well as low-level cryptographic primitives. For each key size, we measure the computation time of exponentiating by all primes n i=1 p i , by calling the OpenSSL "BigNum" exponentiating function. This is analogous to the computation required to serve the first ticket and then puncture the key: Serving requires exponentiating to the power of all primes except one, p i , and puncturing requires exponentiating to the power of p i . This is the worst-case, since serving later tickets is cheaper.
We measure the performance of this calculation for two of the above cases, which determine the value of n: (1) Worst-case is cheaper than exponentiation, and (2) The average case is cheaper than exponentiation. We note the latter case is slightly unintuitive: we measure the worst-case performance, under the requirement that the average case is comparable to one exponentiation in the group. Table 2 gives our results. We observe that performance is comparable to, but slower than, RSA decryption. In typical cases, it requires only a few additional milliseconds All times are measured in milliseconds. Measurements were performed on a standard workstation, with a 3.60GHz Intel i7 CPU. All measurements used code from OpenSSL 1.0.2q, released in November 2018. To benchmark our construction we used a short piece of custom code, based on [11], to repeatedly call the OpenSSL exponentiating function. For each parameter choice, we generated 100 random moduli, and performed 100 exponentiations of random group elements to the power of n i=1 p i . To benchmark RSA decryption, we used a built-in OpenSSL benchmarking command, "openssl speed" (after applying a small patch that adds support for 3072-bit RSA to the command [37]) compared to RSA decryption. We argue the additional latency and computation requirement are small enough to allow the construction to be deployed as-is, in current large scale TLS deployments. It is unsurprising that RSA decryption is faster than our construction, since OpenSSL performs RSA decryption using the Chinese Remainder Theorem.

Tree-Based PPRFs
This section will consider a different approach to instantiating Construction 1 based on PPRFs using trees. At first we will recap the idea behind tree-based PPRFs and explain how we utilize tree-based PPRFs as an instantiation of our session resumption protocol and highlight implications. Finally, we will describe our new "domain extension" technique for PPRFs and analyze its efficiency.

Tree-Based PPRFs
We will briefly recap the main idea behind tree-based PPRFs. It is well known that the GGM tree-based construction of pseudorandom functions (PRFs) from one-way functions [30] can be modified to construct a puncturable PRF, as noted in [12,14,38]. It works as follows.
Let G : {0, 1} λ → {0, 1} 2λ be a pseudorandom generator (PRG) and let G 0 (k), G 1 (k) be the first and second half of string G(k), where k is a random seed. The GGM construction defines a binary tree on the PRF's domain, where each leaf represents an evaluation of the PRF. We label each edge with 0 if it connects to a left child, and 1 if it connects to a right child. We label each node with the binary string determined by the path from the root to the node. The PRF value of x = x 1 . . . x n ∈ {0, 1} n is (G x n • . . . • G x 1 )(k) ∈ {0, 1} λ , i.e. we compose G according to the path from root to leaf x.
We briefly describe how this construction can be transformed into a PPRF. In order to puncture the PPRF at input x = x 1 . . . x n we compute a tuple of n intermediate node evaluations for prefixes x 1 , x 1 x 2 , . . . , x 1 x 2 . . . x n and discard the initial seed k. The PPRF is secure if an adversary is not able to distinguish between a punctured point and a truly random value, even when given the values of all computed "neighbor nodes". This holds as long as the underlying PRG is indistinguishable from random [12,14,38]. Furthermore, note that the PPRF is also invariant to puncturing as puncturing always deletes all nodes from a leaf up to the root without leaving any trace which leaf is "responsible" for the deletion. Hence, if an adversary is given a punctured key, it cannot deduce in which order it has been punctured.

Combining Tree-Based PPRFs with Tickets
In our session resumption scenario the tree-based PPRF will act as a puncturable STEK. That is, evaluating the PPRF returns a ticket encryption key. Upon resumption with a ticket we will retrieve the ticket encryption key from the PPRF by evaluating it and puncture the PPRF at that very value to ensure the ticket encryption key cannot be computed twice. Note that each ticket encryption key essentially corresponds to a leaf of the tree. Thus we will subsequently use the terms leaf and ticket (encryption key) interchangeably depending on the context. For simplicity, we consider tickets which consist of a ticket number i and a ticket lifetime t. Following Construction 1 we will issue the tickets one after another while incrementing the ticket number for each. Note that the ticket number i corresponds to the i-th leftmost leaf of the tree. The ticket lifetime t determines how long an issued ticket is valid for resumption. That is, if t > t time has passed, the server will reject the ticket.
We assume that the rate at which tickets are issued is roughly the same as the rate tickets are used for session resumption. This holds as for each session resumption we will issue a new ticket to again resume the session at a later point in time. Similarly, we argue that tickets are roughly used in the same order for resumption as we issued them. Again, if we consider multiple users, repeatedly requesting tickets and resuming sessions, we are able to average the time a user takes until a session is resumed (Cloudflare have suggested that these assumptions seem reasonable; unfortunately, they cannot provide data on returning clients' behavior yet). This yields an implicit window of tickets in usage. The window is bounded left by the ticket lifetime and bounded right by the last ticket the server issued. Within the lifetime of the tree-based PPRF this implicit window will shift from left to right over the tree's leaves. It immediately follows that tickets are also roughly used in that order.

Efficiency Analysis of the Tree-Based PPRF
We will now discuss how the performance of tree-based PPRFs depends on the ticket lifetime. We consider a scenario where the ticket lifetime t equals the number of leaves . It is also possible to consider a scenario where the ticket lifetime is smaller than the number of leaves. If both number of leaves and ticket lifetime t are powers of 2, we can divide the leaves in /t windows, which span a subtree each. The subtrees are all linked with the "upper part" of the tree. A different approach would be to instantiate a new tree when a tree runs out of tickets. We stress that this does not affect our analysis. As soon as one subtree runs out of tickets, the next subtree is used. If the rate at which we issue tickets stays the same, we are able to delete parts of the former tree when issuing tickets of the next one. Hence, for analysis, it is sufficient to consider a single tree.
If we were to puncture leaves strictly from left to right, we would need to store at most log( ) leaves (one leaf per layer). Note that if we puncture leaves at random, we would need to store at most p · log( ) nodes, where p is the number of punctures performed. We can also bound the number of nodes we need to store by p · log( ) ≤ /2. This is due to the tree being binary. Essentially each node (except for the lowest layer) represents at least two leaves. To be more precise, in a tree with L layers, storing a node on layer i allows evaluating its 2 L−i children. Thus it is preferable to store those nodes instead of storing leaves in order to save memory. In the worst-case only every second leaf is punctured. This results in precomputation of all other leaves without being able to save memory by only storing an intermediary node. Note that this would actually resemble a session cache, where all issued tickets are stored. However, note that a session cache needs to store each ticket when it has been issued, whereas our construction only needs to increase its storage if a ticket is used for resumption. Thus, our tree-based construction performs (memory-wise) at least as well as a session cache. In practice, where user behavior is much more random, our approach is always better than session caches.
The tree-based PPRF performs more computations compared to a session cache. When issuing tickets we need to compute all nodes from the closest computed node to a leaf. For puncturing we need to compute the same, plus computation of some additional sibling nodes. However, when instantiating the construction with a cryptographic hash function, such as SHA-3, evaluation and puncturing of the PPRF consists only of several hash function evaluations. This makes our construction especially suitable for high-traffic scenarios. Table 3 gives worst-case secret key sizes based on the above analysis. However, we expect the secret key size to be much smaller in practice. Unfortunately, we are not able to estimate the average key size as this would depend on the exact distribution of returning clients' arrival times.

Generic Domain Extension for PPRFs
Most forward-secure and replay-resilient 0-RTT schemes come with large secret keys (possibly several hundred megabytes) when instantiated in a real-world environment [19,20,33]. This is especially problematic if the secret key needs to be synchronized across multiple server instances. Therefore, it is often desirable to minimize the secret key size. In this section we will describe a generic domain extension. In the context of our work, the domain extension reduces the size of punctured keys by trading secret key size for ticket size, while preserving the puncturing functionality.
Idea Behind the Construction Our session resumption protocol uses the output of the PPRF as a ticket encryption key. Normally, a PPRF only allows one output per input as it is designed to be a function. Our protocol, however, does not rely on this property. Instead of only using one ticket encryption key we could generate multiple ticket encryption keys. Ticket issuing would work as follows. First, we generate an intermediary symmetric key to encrypt the resumption secret. The intermediary symmetric key is then encrypted under each of the ticket encryption keys. The ticket will consist of one encryption of the resumption secret and several (redundant) encryptions of the intermediary symmetric key. We note that typically a ticket contains not only the resumption secret but also the chosen cipher suite and other additional session parameters, and is thus larger than just the resumption secret. It is therefore desirable to encrypt this data only once, while encrypting the shorter intermediary symmetric key multiple times. This makes the ticket as short as possible.
As long as the PPRF is able to recompute at least one of those ticket encryption keys, the server will still be able to resume the session. This allows us to construct a wrapper around the PPRF that extends the PPRF's domain by relaxing the requirement that every input has only a single output.
Before formally describing our construction, we will provide an example to illustrate the idea. Let X be the PPRF's domain. We will extend the domain to X × [n] with a domain extension factor of n. That is, we will allow (x, i), i ∈ [n] for any x ∈ X as input. Let G : {0, 1} λ → {0, 1} nλ be a pseudorandom generator and let G j (x) be the j-th bitstring of size λ of G on input x. We define the evaluation of (x, i) as all possible compositions of G j which end with G i . That is, for any input (x, i) there will be (n − 1)! different outputs, as there are (n − 1)! ways to compose G j with j = i. The possible compositions of PRGs can be illustrated as a tree as shown in Fig. 5.
After puncturing the PPRF's key for a value (x, i), it must not be possible to evaluate the value anymore. This requires a mechanism to ensure that composing the PRGs which end with G i is no longer possible. We achieve this by forcing an evaluation of  puncturing (x, 3), the value y 3 is computed and stored and y is discarded. Thus, only the white nodes are computable, whereas the gray nodes cannot be computed without inverting G 3 .
where y is the evaluation of the underlying PPRF on input x. In order to render recomputation of y impossible, we additionally need to puncture the PPRF's key on value x and delete the computed y. Formally, the construction is defined as follows. Output is k = (k PPRF , L).

Efficiency Analysis of the Generic Domain Extension
Increased Ticket Size Note that a ticket is longer than a standard ticket by (n − 1)! encrypted blocks. Assuming 128-bit AES, and choosing n = 5, this translates to 4! · 16 = 384 additional bytes. This is likely to be insignificant on the modern Internet. For example, Google has pushed for increasing the maximum initial flight from 4 TCP packets to 10 [25], as most server responses span several packets already (a typical full packet is about 1500 bytes). A basic experiment performed by Google and Cloudflare in 2018 measured a similar scenario: It added 400 bytes for both the client's and server's first flights [44]. They observed relatively small additional latencies: 2-4 milliseconds in the median, and less than 20 milliseconds for the 95th percentile. However, choosing n = 6 or larger is likely to be not cost-effective. This would translate to 5! · 16 = 1920 additional bytes, larger than a standard TCP packet.
Storage Requirements Comparing the storage requirements of the tree-based construction to standard session caches depends on the specific distribution of returning clients. In the best case, tickets arrive in large contiguous blocks. In this case, a tree-based construction uses negligible storage (logarithmic in the number of tickets), making the savings factor in storage huge. However, this is unrealistic in practice. In the worst-case, tickets arrive in blocks of n − 1 tickets of the form (x PPRF , i) for i ∈ [n − 1], adversarially rendering the domain extension technique useless as each subtree is reduced to a single node. As before, this is unrealistic in practice. We have therefore resorted to simulations in order to assess the improvement in storage requirements. Our simulation constructs two trees: a standard binary tree with layers, and a domain-extended tree with n = 4. For the domain-extended tree, the first − 2 layers are constructed as a standard binary tree, and the last log(4) = 2 layers are represented by the domain extension.
We simulated the storage requirements for trees of 10,000 tickets. We note that results for trees of 10,000 tickets should closely follow results for larger tree sizes. Trees are quickly split into smaller sub-trees when puncturing, regardless of the initial tree size. In the first puncturing operation we delete the root and (implicitly) store smaller subtrees with at most half the nodes in each, and so forth. We focused on the relationship between ticket puncturing rate and savings in storage. The ticket puncturing rate denotes the percentage of tickets that are punctured, out of the 10,000 outstanding tickets. This can also be thought of as the percentage of returning clients. After fixing the puncturing rate to r , we simulate the arrival of r % of clients according to two distributions: Gaussian and uniform. With the uniform distribution, the next ticket to be punctured is sampled uniformly out of the outstanding tickets. With the Gaussian distribution, the next ticket to be punctured is sampled using a discrete Gaussian distribution with mean μ = 5000 and standard deviation σ (for varying values of σ ). We then simulate the state of both trees after puncturing the sampled ticket. We repeatedly sample tickets and puncture them, until we reach the desired puncturing rate. We then report the ratio between the storage for the standard binary tree and the storage for the domain-extended tree, in their final states.
Intuitively, the Gaussian distribution aims to simulate the assumption where tickets arrive in some periodic manner. For example, assume the tickets most likely to arrive are the tickets issued roughly one hour ago. Then the distribution of arriving tickets will exhibit a noticeable mode ("peak"), where tickets close to the mode are much more likely to arrive than tickets far from it. The Gaussian distribution is a natural fit for this description. On the other hand, the uniform distribution makes no assumptions on which ticket is likely to arrive next. In personal communication, Cloudflare have advised us that it is reasonable to assume tickets are redeemed roughly in order of issuance (they do not have readily-available data on returning clients' behavior). This motivated our use of Gaussian distributions. We hope to see additional research in this area. In particular, it would be helpful if large server operators could release anonymized datasets that allow simulating the behavior of returning clients in practice.
Using our domain extension technique with n = 4 results in a typical factor of 1.4 (or more) reduction in storage compared to a tree-based PPRF. Figure 6 plots the results when using the uniform distribution and a Gaussian distribution with σ = 2000. We encountered similar results when using other values for σ . We estimate ticket redeeming rates in large-scale deployments are roughly 50%. We therefore focus on cases where the puncturing rate is at least 40% and at most 60%. We note that in the worst-case, the domain extension performs as well as the binary tree.

Comparison of Solutions and Conclusion
Comparison of Solutions To summarize this work, Table 4 compares our two constructions with the standard solutions of session tickets and session caches. Note that we decided to exclude implementation-specific costs (such as database access) from our "dominant cost" column and only focus on cryptographically expensive factors.
Conclusion In most facets, TLS 1.3 offers significant improvements in security compared to earlier TLS versions. However, when 0-RTT mode is used, it surprisingly weakens standard security guarantees, namely forward security and replay resilience. This was noted as the protocol was standardized, but the latency reduction from 0-RTT was considered "too big a win not to do" [50].
This paper presented formal definitions for secure 0-RTT session resumption protocols, and two new constructions that allow achieving the aforementioned security guarantees at a practical cost. We expect continued research in the coming years in this area, of achieving secure 0-RTT traffic as cheaply as possible. Currently, many large Average storage improvement factor of the domain-extended binary tree (with n = 4) compared to a standard binary tree, depending on the ticket puncturing rate. All simulations used trees of 10,000 tickets. The dashed blue line (resp. continuous red line) shows the storage improvement when modeling client's arrivals with a uniform distribution (resp. discrete Gaussian distribution with mean μ = 5000 and standard deviation σ = 2000). For session tickets, we assume a deployment that rotates STEKs, as in [46]. For session caches, we assume each key is 128 bits (16 bytes) long. The unique ticket identifier, and other storage overhead, will typically require a few more bytes. We therefore estimate total storage per key as 20-30 bytes. For the Tree-based PPRF, actual storage per ticket highly depends on returning clients behavior. However, this solution always requires at most as much storage as a session cache server operators serve 0-RTT traffic using STEK-encrypted session tickets. As more Internet traffic becomes 0-RTT traffic, this solution rolls back the security guarantees offered to everyday secure sessions. The Eurocrypt 2019 version of this paper does not show if TLS 1.3 can be securely composed with the presented 0-RTT session resumption protocol. In this work we resolved this open problem and showed that any secure 0-RTT session resumption protocol can be generically composed with the TLS 1.3 resumption handshake. In particular, this yields the first variant of the TLS 1.3 resumption handshake that achieves forward secrecy for all messages (including the 0-RTT data) without modifying client implementations of TLS 1.3.
Funding Open Access funding enabled and organized by Projekt DEAL.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

A Accepting Replay Attacks and Idempotent Requests
When using session tickets, one option is to simply allow replay attacks, in cases where the server can be certain they do not harm security. This was proposed primarily in the case of HTTPS, where TLS encapsulates HTTP requests. Theoretically, HTTP GET requests only retrieve an HTTP resource located on the server, without changing server state. The argument then goes that an attacker replaying an HTTP GET request can only cause a resource to be retrieved several times instead of one, and this is harmless [51, §E.5]. It then follows that it is "safe" to allow replayable HTTP GET requests, and disallow other request types, such as HTTP POST, to be sent such that they can be replayed. This logic can be generalized to allow replay of any idempotent [51] request: a request that has the same effect on the server state whether it is served once or several times. Furthermore, an attacker is able to cause most modern web browsers to replay any request, idempotent or not [26]. Therefore, the naïve conclusion is that investing resources defending against replay attacks, either in the standard or in deployment practices, is futile. Colm MacCárthaigh [48] describes several convincing counterarguments against this reasoning. As a simple example, consider the following attack. An HTTP server provides two different medical documents, say DiseaseA.pdf and DiseaseB.pdf. A user downloads one of these documents with TLS 1.3 0-RTT, and doesn't want the attacker to learn which one. An attacker records the encrypted HTTP GET requests, and wants to learn which file was downloaded. At some later point in time, document DiseaseA.pdf is deleted from the server (or moved to a different URL, which is equivalent for this attack). The attacker then replays the encrypted HTTP GET request. If the user has downloaded DiseaseA.pdf, then an encrypted HTTP 404 error will be returned, resulting in a relatively "short" response. If the user downloaded DiseaseB.pdf, the server responds with an encrypted pdf document, which is typically much longer.

B Detailed Description of Protocol Values
In this section we provide additional technical details of our modified protocol, introduced in Sect. 4. The details include a table of labels and their values (cf. Table 5) and a short description of how the transcript hashes are computed.