Robust Channels Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3

,


Introduction
Cryptographic channel protocols should provide confidentiality and authenticity of communication in the presence of network adversaries.Consider for example the latest version of TLS in version 1.3 [Res18].Ignoring subtle issues like fragmentation, the record layer protocol should ensure that the sender's ciphertexts1 c 1 , c 2 , c 3 , . . .are correctly decrypted to the encapsulated messages at the receiver's side if they arrive in this order.Any (accidental or malicious) reordering or modifications of the ciphertexts should be detectable and, in case of suspicious behavior, the standard specifies that the connection must be closed: If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.
TLS therefore assumes, or at least hopes, that packets are delivered reliably on the network.If a ciphertext accidentally gets lost on the transport layer then this most likely closes the channel connection on the application level.Put differently, this way of dealing with errors is closely associated to the TCP protocol as the underlying reliable, connection-oriented transport layer.
Other cryptographic channels like QUIC [IT21,TT21] or DTLS 1.3 [RTM21], however, run atop an unreliable, datagram-oriented transport layer, UDP in these cases.From the channel's point of view this means that ciphertexts (or, fragments of ciphertexts) may be lost on the network or arrive in different order.Such protocols thus need to support more ample error handling.Usually, they use a slidingwindow technique to decrypt ciphertexts within the window, moving the window forward whenever a valid ciphertext beyond the current window arrives.
The sliding-window technique is interesting for the cryptographic channel for two reasons.One is that, currently, most cryptographic models for secure channels focus on the aborting type of protocols and thus do not touch upon the window technique (this includes, e.g., the initial formalization of stateful authenticated encryption [BKN02,BKN04] used to analyze the SSH protocol [YL06], length-hiding authenticated encryption variants used to study the TLS protocol [PRS11,JKSS12], as well as more specialized models covering fragmentation [BDPS12], streaming [FGMP15], bidirectionality [MP17], or ratcheting security [JS18]).Another interesting aspect is that such protocols necessitate another property besides correctness and the common security notions, which was mostly neglected so far.

Robustness of Channels as a First-class Property
In this work, we bring out robustness as a core property of cryptographic channels, which primarily focuses on protocols over an unreliable network, but also extends to reliable networks under active attacks.Robustness roughly says that malicious ciphertexts on the network cannot disturb the expected behavior of the channel.As a concrete example, robustness guarantees that an adversarially injected ciphertext cannot make the window of the sliding technique shift further, such that previous ciphertexts, which would otherwise have been inside the admissible window, would now get rejected.Let us emphasize that, despite at first glance similar in spirit, robustness does not aim at preventing network denial-of-service (DoS) attacks (a goal beyond classial cryptographic mechanisms), but captures that a channel should maintain functionality according to a certain robustness level for those received ciphertexts (e.g., but not only in, DoS settings).
We remark that robustness as a notion has so far not been captured by previous security definitions for channels when it comes to where it is most relevant, namely, for unreliable network transmission.In the realm of ratcheting [BSJ + 17], Jaeger and Stepanovs [JS18] discuss a restricted form of robustness for bidirectional channels as part of their correctness definition, but intentionally only treat reliable transport protocols.Boyd et al. [BHMS16], in their generalization of different levels of authentication/AEAD in a hierarchy similar to the one introduced by Kohno, Palacio, and Black [KPB03], come closest to the idea of a more fine-grained approach to different properties like reordering or dropping of ciphertexts.Likewise, Rogaway and Zhang [RZ18] capture different level sets for permissible ordering for stateful authenticated encryption, capturing a hierarchy similar to [BHMS16,KPB03].Yet, it turns out that QUIC [IT21,TT21] and DTLS 1.3 [RTM21], for example, would be declared as insecure according to their models.This is due to technically subtle, but model-inherent reasons resulting from the deployed dynamic sliding-window technique and the protocols' novel approach to only transmit partial packet numbers.We provide more details in Section 3.3 when introducing our formalism.
In a different light, Chen et al. [CJJ + 19] (and similarly Lychev et al. [LJBN15] in prior work for an early version) study the QUIC record layer as part of an overall ACCE-type analysis [JKSS12].While their formalism treats QUIC as having no reordering and replay protection (level 1 in the hierarchy of [BHMS16]), they argue that sequence number authentication in QUIC "essentially" achieves TLS-like authentication and reordering protection.Our work aims at providing a more fine-grained analysis of the properties that sliding-window cryptographic channel protocols achieve over an unreliable network.

Defining General Robustness
Defining robustness as a general notion is delicate because we need to compare the behavior in presence of an active adversary to the expected behavior of the channel under non-malicious alteration due to the network, be it reliable or unreliable.To capture different expected channel behaviors like the ability to recover from ciphertext losses or from ciphertext reordering in a single definition, we parameterize the channel protocol by a predicate supp describing supported ciphertexts, i.e., ciphertexts which should be processed correctly by the channel. 2 This predicate operates on the sequences of sent and received ciphertexts so far, and thus represents a global view on the network communication.
We show how such support predicates allow us to capture various scenarios for desired channel behavior, spanning both reliable and unreliable networks.On the extreme ends this includes a strict ordering of ciphertexts at the receiver's side, as in TLS 1.3 over reliable networks, and (almost) no guarantees as in DTLS 1.2 with no replay protection.Our notion also allows to portray the different sliding-window techniques with both static or dynamic window sizes.
Introducing supp as a parameter already affects the correctness definition of a channel.Correctness then says that the protocol acts as expected on supported ciphertext sequences, now defined as a game with a weak network adversary which can only tamper with the order of ciphertexts.Once we have the advanced notion of correctness we can define robustness in a generalized way.Our robustness notion, denoted ROB, compares the real behavior of the channel with the correct behavior that would be obtained when filtering out any maliciously modified or injected ciphertext by an active adversary.For a robust channel we expect both behaviors to be quasi identical, implying that the malicious ciphertexts cannot make the protocol deviate.In particular, if a channel uses sliding windows to identify admissible ciphertexts, then malicious network data cannot falsely modify the window boundaries.

Relations Between the Security Notions
We relate the notion of robustness to the classical notions of channel integrity and indistinguishability (under network-passive (IND-CPA) and -active attacks (IND-CCA)).For this we first recapture the (stateful) notion of ciphertext integrity INT-sfCTXT [BKN04] within our framework with the predicate supp, yielding

Robustness of QUIC and DTLS 1.3
Turning to the record layer protocols of QUIC and DTLS 1.3 we provide an abstract representation of their packet encryption as a cryptographic channel.Both protocols rely on an AEAD scheme to protect the payload.With minor differences, both use sequence numbers as nonces for AEAD encryption but only transmit parts of the sequence number with the ciphertext.As a result, the receiver must be able to recover the correct sequence number from the fraction transmitted with the ciphertext.This is accomplished by using a sliding window for determining the nearest sequence number to the received partial information.Remarkably, the window size is variable, e.g., can be between 1 and 4 bytes for QUIC, and chosen by the sender when creating the ciphertext.Note that this approach is different from previous approaches such as DTLS 1.2 which transmits the full nonce in clear.
The above window is required to determine the full packet number but does not necessarily provide protection against replay attacks.For instance, sending the same ciphertext twice immediately would yield the correct sequence number in both cases, since the window has not progressed too far the second time.
Therefore, both protocols use another (fixed-size) sliding window on the receiver side to detect replayed ciphertexts.Both these replay-check windows reach backwards from the last valid sequence number on the receiver's side.
We continue to establish that QUIC achieves the intended level of robustness with respect to its supported in-window reordering with replay protection.Robustness of QUIC, beyond the appropriate encoding of (truncated) nonces within the sliding window, relies on the underlying AEAD scheme's integrity.Our proof actually shows robustness and integrity in one go, so that we can immediately deduce that the channel achieves the ROB-INT property above.Arguing that QUIC is IND-CPA is straightforward using the confidentiality of the AEAD scheme, such that we can immediately conclude with our general results that the protocol provides ROB-INT-IND-CCA.We achieve similar results in our robustness analysis of DTLS 1.3.
The robustness results for QUIC and DTLS 1.3 surface a noteworthy security degradation: The fact that channels over unreliable networks need to keep the connection open when receiving (possibly maliciously) disordered ciphertexts gives an adversary multiple forgery attempts.This induces a non-tight security bound for robustness in the reduction to the underlying AEAD scheme's integrity.Upon closer inspection, this loss coincides with the security bounds of many AEAD schemes [Jon03,IOM12a,Pro14], including those underlying DTLS 1.3 and QUIC, and is also reminiscent of experiences with practical attacks being easier to mount on unreliable networks, e.g., as observed in the Lucky Thirteen attack on the (D)TLS record protocols [AP13].Maybe surprisingly, this higher integrity security loss (compared to reliable-transport protocols like TLS) so far has not been considered in prior DTLS versions and earlier drafts of the QUIC and DTLS 1.3 protocols.This is despite TLS 1.3 already defining limits on key usage [Res18, Section 5.5] for confidentiality, with the underlying analysis by Luykx and Paterson [LP17] pointing out that integrity bounds for DTLS would need to be considered differently.We communicated our security bounds to the respective IETF working groups, which led them to specify concrete forgery limits for packet protection for QUIC in draft-29 [TT20,Tho20a] and for DTLS 1.3 in draft-38 [RTM20,Tho20b], and the IRTF CFRG to work on a document guiding users about taking AEAD usage limits into consideration [GTW21].

Preliminaries
We introduce some notation used throughout the paper.Additionally, we provide a brief recap of syntax and security of authenticated encryption with associated data [Rog02].

Notation
We write a bit as b ∈ {0, 1} and a (bit) string as s ∈ {0, 1} * with |s| indicating its (binary) length.We implicitly interpret natural numbers as bit strings (of appropriate length) and vice versa, depending on the context, en-/decoding to/from big-endian binary encoding.For a bit string s and i, j ∈ [1, |s|], we denote with s[i] the i-th bit of s and with s[i..j] the substring of s starting with the i-th bit and ending with, and including, the j-th bit, where for j < i we set s[i..j] to be the empty string, denoted by ε.We write s t if s is a prefix of t (i.e., t[1..|s|] = s), s t for the concatenation and s ⊕ t for the bit-wise XOR of s, t.For a bit string s of length |s| = n and m ∈ N ∪ {0} we denote by s m the string s[1 + m..n + m] 0 min(m,n) of same length n resulting from shifting in m zeros from the right.Note that the notation also covers the case that m > n and hence the resulting (shifted) substring s[1 + m..n + m] is outside of the original range of the string.Hence this substring is initially empty and we concatenate a zero-string of length min(m, n) to assign each position in s[1 + m..n + m] a bit 0.
Similarly, for lists s, t, s t denotes concatenation, with s ← − x being a shorthand for s ← s (x), i.e., appending x as the next entry to s.We write |s| for the number of entries, s[i] = s i for the i-th entry in s, starting with index 1, and s[i, j] the sub-list of s starting with the i-th entry and ending with the  ) the m-entries list consisting of all i-th entries of t's sublists.We provide all security results in terms of concrete security but occasionally also need asymptotic behaviors, e.g., when defining a general property like robustness (ROB).In this case it is understood that all algorithms, including the adversary, then receive the security parameter in unary.In this case terms like "negligible" and "polynomial time" then refer to this security parameter.

Authenticated Encryption with Associated Data
Def inition 2.1 (AEAD).An authenticated encryption with associated data (AEAD) scheme AEAD = (Enc, Dec) is a pair of efficient algorithms associated with key, nonce, associated-data, and message spaces K, N , H, resp.M such that: We say that an AEAD scheme is correct if for all K ∈ K, N ∈ N , AD ∈ H and m ∈ M, it holds that We define confidentiality (IND-CPA security) of an AEAD scheme as the distinguishing advantage of an adversary querying inputs (N, AD, m 0 , m 1 ), with |m 0 | = |m 1 | and never repeating N ("nonce-respecting"), to a left-or-right encryption oracle Enc K,b returning Enc(K, N, AD, m b ) under a random key K ∈ K and bit b ∈ {0, 1}: Authenticity, or integrity of ciphertexts, INT-CTXT, of an AEAD scheme is classically [Rog02] defined wrt.an adversary's ability to forge a single ciphertext (i.e., to output a fresh triple (N, AD, c) decrypting to a non-error), given an encryption oracle.As we will see in our analyses of QUIC and DTLS 1.3, channels running atop unreliable transport however have to tolerate multiple attempts of an attacker trying to break the channels integrity.The reason is that the connection is not closed when receiving an invalid ciphertext.We therefore define a more general, multi-target INT-CTXT notion for AEAD schemes in Figure 2 in which the adversary is permitted multiple forgery attempts through a (responseless) Forge oracle.(The notion is equivalent to adaptively learning the forgery's validity, cf.Bellare et al. [BN00,BGM04].)We define the authenticity advantage of an adversary A making at most q F queries to its Forge oracle as 1) corresponds to the classical one-forgery authenticity by Rogaway [Rog02].By a standard hybrid argument, we furthermore have . This linear loss in the number of forgery attempts indeed surfaces in the security bounds of many AEAD schemes, including AES-CCM [Jon03], AES-GCM [IOM12a,IOM12b], and ChaCha20+Poly1305 [Pro14] underlying DTLS 1.3 and QUIC.The forgery limits for packet encryption added to QUIC in draft-29 and DTLS 1.3 in draft-38 [TT20, Tho20a, RTM20, Tho20b] following our analysis are determined based on these AEAD schemes' integrity bounds, aiming at similar security margins as for the key usage limits in TLS 1.3 for confidentiality (cf.Luyx and Paterson [LP17]).

Channels
In this section we give an augmented definition of channel protocols which will allow us to capture channel behavior over unreliable networks.As usual, a channel consists of three algorithms, for initialization, sending messages on the sender side, and receiving messages on the receiver side.However, we introduce two definitional twists that will allow us to capture different and possibly dynamic channel behaviors (depending on the underlying network): First, we parameterize the definition of correctness to capture different levels of supported variations in the ciphertext sequence (caused by the underlying network).Second, we provide the sending algorithm with an additional, auxiliary information (beyond the message to be transmitted) which is generic and recoverable from the ciphertext; this allows to capture dynamic sending behavior (like the variable-length packet number encoding we will see in QUIC and DTLS 1.3) that affects correctness properties.

Def inition 3.1 (Channel protocol).
A channel (protocol) Ch = (Init, Send, Recv, aux) with associated sending and receiving state space S S resp.S R , message space M ⊆ {0, 1} ≤M for some maximum message length M ∈ N, ciphertext space C, auxiliary information space X , error symbol ⊥ with ⊥ / ∈ M, consists of three main algorithms and one helper algorithm defined as follows.
• Init() $ − → (st S , st R ).This probabilistic algorithm outputs initial sending and receiving states st S ∈ S S , resp.st R ∈ S R .
• Send(st S , m, aux) $ − → (st S , c).On input a sending state st S ∈ S S , a message m ∈ M, and auxiliary information aux ∈ X , this (possibly) probabilistic algorithm outputs an updated state st S ∈ S S and a ciphertext (or error symbol) c ∈ C ∪ {⊥}.
• Recv(st R , c) → (st R , m).On input a receiving state st R ∈ S R and a ciphertext c ∈ C, this deterministic algorithm outputs an updated state st R ∈ S R and a message (or error symbol) m ∈ M ∪ {⊥}.
• aux(c) → aux.On input a ciphertext c ∈ C, this deterministic helper algorithm outputs the corresponding auxiliary information aux ∈ X .

Correctness
We define correctness of a channel protocol in terms of a correctness experiment.In order to capture the underlying network possibly arbitrarily dropping or reordering (yet not modifying) packets, we define correctness with a "semi-malignant" adversary which determines the message inputs to the sender and the arrival order of ciphertexts (but cannot modify or inject ciphertexts).In the experiment we specify correctness with respect to a supported sequence of received ciphertexts, formalized through a predicate supp.We require that supp(C S , DC R , c) = false for any support predicate supp, sequences C S and DC R , and any c / ∈ C S .This requirement encodes that supp is a correctness predicate and should only be true for genuinely sent ciphertexts.Correctness wrt.supp further encodes that supp must at least support channel ciphertext sequences delivered perfectly in-order.
The correctness experiment Expt correct(supp) Ch,A in Figure 3 initializes the channel state, three empty lists C S , DC R , and T for keeping track of processed data, and a flag win which shall indicate the adversary's success in violating correctness.Then the adversary is run with access to both Send and Recv oracles, providing interfaces to sending/receiving, with the restriction that Recv may be queried only on ciphertexts output by Send which are supported. 4(Recall that correctness captures the channel's operation under normal, yet unpredictably unreliable network behavior, hence the restriction to a "semi-malignant" adversary.)The adversary's goal is to violate correctness wrt.supp by either (1) making aux incorrectly recover the auxiliary information used in Send (Line 7); (2) making supp reject a ciphertext in a perfectly in-order sequence (Line 18); or (3) making Recv output an incorrect message on input a supported ciphertext (Line 22, this is the usual, core correctness requirement).More specifically, the Send and Recv oracles work as follows: Send.On input a message m and auxiliary information aux the Send algorithm is run to obtain a ciphertext and an updated sending state.The oracle then enforces condition (1) from above, checking that aux correctly recovers the auxiliary information from the ciphertext; otherwise, the flag win is set to 1 indicating that the adversary has won.The ciphertext is then appended to the list of sent ciphertexts C S and, together with m, stored in the lookup table T .Finally, the oracle returns the ciphertext to the adversary.
Recv.The oracle is invoked with an index j indicating that the j-th ciphertext output by Send should be received.(This encodes the "semi-malignant" adversary capturing the unreliable network, which reorders but does not modify or inject ciphertexts.)In case the index j is outside of the range, the oracle rejects (with ).Otherwise, the oracle considers the message-ciphertext pair (m, c) from T at position j, and determines the support decision d for that ciphertext.It then checks that, if all ciphertexts C * R so far (including c) have been received in the same order as they were sent, supp decides on true, declaring the adversary won by violating condition (2) from above otherwise in Line 18. Further, nothing is done (and the query rejected) if c is not supported; this encodes that correctness is concerned with the correct receipt of supported ciphertexts only.If supported, c is now received through Recv and the resulting message m compared with the sent message m; the adversary wins if the two differ, encoding the main correctness property (condition (3) above) that receiving supported ciphertexts (only) must yield the correct sent messages.Finally, DC R is appended with (d, c) and m returned to the adversary.= 0 for any (unbounded) A.

Def inition 3.2 (Correctness of channels
Note that one can easily define -correctness of the channel by requiring that the above advantage term is bounded by .

Examples of Support Classes
In the following, we discuss a few examples of different support classes which reflect different protocol purposes and environments (in terms of accepted reordering and replay protection).The examples illustrate the versatility of our supported predicate approach through a series of more and more complex designs; to assist understanding we underline for each predicate the major change wrt. to the previous one.In particular, our examples encompass the Internet security protocols DTLS [RM12,RTM21] and QUIC [IT21,TT21], but additionally include conceivable alternative support classes of channel protocols.Some classes reflect prior authentication hierarchy levels put forward in the works by Kohno et al. [KPB03], Boyd et al. [BHMS16], and Rogaway and Zhang [RZ18].In Section 3.3 below, we explain why inherent aspects of those prior approaches however prevent them from modeling our more complex support classes that capture DTLS 1.3 and QUIC.
To ease readability, let us define the following shorthands.We write C R = DC R 2 and D R = DC R 1 for the separated sequences of supportedly received ciphertexts and corresponding support decisions, respectively, in DC R .For index-recovering support predicates (i.e., D R ⊆ N), we furthermore let max = max(D R ) be the largest recovered index among all supportedly received ciphertexts, and nxt = max + 1 denote the "next expected" ciphertext index on the receiver's end (one past max).Finally, when defining support predicates capturing sliding windows, we often have to check if a ciphertext c is contained within a certain window C S [x, y] in the sequence of sent ciphertexts C S , and if so, determine that occurrence's index within the full C S .For this, we define the following check-index shorthand: false otherwise We are now ready to specify the support classes.Note that, in particular, all support predicates adhere to the requirement that supp(C S , DC R , c) = false for any sequences C S and DC R , and any c / ∈ C S ; i.e., they are false for any non-genuine ciphertext.
No ordering.A channel that accepts packets in any order where the packets can also be duplicates; e.g., DTLS 1.2 without replay protection [RM12].This is equivalent to level/type 1 in the authentication hierarchy of [KPB03,BHMS16] and level L 0 in [RZ18], essentially capturing plain authenticated encryption.
The corresponding predicate only ensures that each ciphertext was genuinely sent.Formally, c): No ordering with global anti-replay.A channel that accepts packets in any order, but rejects duplicates.This is equivalent to level/type 2 in [KPB03, BHMS16] and level L ∞ 1 in [RZ18].The corresponding predicate ensures that each ciphertext was genuinely sent and not received before.Formally, classify DTLS 1.2 with replay protection in their level 2 (equivalent to supp no-r ), DTLS 1.2 actually suggests a sliding anti-replay window [RM12, Section 4.1.2.6] and hence cannot provide global (anti-)replay decisions.Indeed, DTLS 1.2 would not achieve correctness wrt.supp no-r since it rejects old ciphertexts past its replay window which supp no-r would require to be supported.Note that, likewise, the L 1 level of [RZ18] only addresses reorderings up to some lag , but does not capture sliding anti-replay windows.For DTLS 1.2, we hence hence consider a more fine-grained approach towards replay protection next.

No ordering with anti-replay window.
A channel that accepts packets in a window of size w r before max (the highest last received packet index), or newer, rejecting duplicates; e.g., DTLS 1.2 with replay protection [RM12].Here, w r defines the size of the anti-replay window in which the channel checks for duplicates; any ciphertext older than what can be checked within this sliding window is conservatively rejected.
The corresponding predicate ensures that each ciphertext was genuinely sent, not received before, and is not older than w r positions before the highest supportedly received ciphertext.Formally, c): Observe that an infinite anti-replay window equals global anti-replay, i.e., supp no-r[∞] = supp no-r .

Static sliding window.
A channel that accepts packets in any order within a sliding window around the next expected ciphertext index nxt, reaching back w b positions and forward w f positions.Formally, c): Observe that an infinite static window equals no ordering, i.e., supp sw[∞,∞] = supp no .Further, a zerosized static window corresponds to what we call robust strict ordering as an extension for reliable transport (i.e., supp sw[0,0] = supp rso ); see the note on TLS below and Appendix A.

Static sliding window with anti-replay window.
A channel that accepts packets in any order within a sliding window (reaching w b positions backward and w f positions forward) around the next expected ciphertext index, if they additionally check as non-duplicates within an anti-replay window of size w r .
The corresponding predicate combines w r and w b in its in-window check since the received ciphertext index must be greater than or equal to both nxt − w b and max − w r = nxt − (w r + 1).Formally, c): Observe that an infinite static window equals no ordering with the same anti-replay window, i.e., supp sw[∞,∞]-r[wr] = supp no-r[wr] for any w r .For an infinitely-sized (i.e., global) anti-replay window w r = ∞ and sliding-window sizes w f = and

Dynamic sliding window with anti-replay window.
A channel that accepts packets in any order within a sliding window (around the expected next ciphertext index nxt) that is dynamically determined for each ciphertext sent, if they additionally check as non-duplicates within an anti-replay window of size w r ; e.g., DTLS 1.3 with replay protection [RTM21] and QUIC [IT21,TT21].
We assume the dynamic backward and forward window size w b , resp.w f , is encoded in the auxiliary information provided to Send as tuple aux = (w b , w f ) ∈ X .(For concrete instances see the treatments of QUIC and DTLS 1.3 in Section 6 and Section 7, respectively.)The supported predicate then individually determines for each ciphertext c whether it was received within the dynamic window determined by w c b , w c f as specified for c.Again, the backward window combines w c b and the anti-replay window size w r .Formally, Observe that for a single-entry auxiliary information space X = {(w b , w f )}, dynamic and static sliding window (with same replay window) coincide, i.e., supp dw-r[wr] = supp sw[w b ,w f ]-r[wr] for any w r .

Discussion and Comparison with Prior Models
Note that one cannot make a fair comparison between the support predicates.For example, the support predicate supp no is "more robust" when receiving ciphertexts compared to supp no-r[wr] since the latter rejects replays.However, this does not entail that a protocol being secure wrt. the former is "better," but rather illustrates that the usage of a support predicate primarily depends on the network and application context.
As mentioned before, prior channel-hierarchy models [KPB03, BHMS16, RZ18] do not capture QUIC and DTLS 1.3, and cannot easily be adapted to do so.This is due to both protocols deploying a dynamic sliding-window technique and their novel approach to only transmit partial packet numbers.
The need to revisit acceptance decisions.Sliding windows can lead to previously rejected ciphertexts being later, upon being re-sent or re-delivered by the network, (rightfully) accepted.Modeling replay protection, [KPB03, BHMS16, RZ18] (in their levels/types 2, resp.L 1 ) demand that a scheme must reject any ciphertext that has already been processed earlier.A scheme with a sliding-window technique may however first reject a ciphertext which is "too new" (too far ahead of the current window), but then later, when re-sent, rightfully accept this ciphertext (when it is within the window) without opening up to replay attacks.Accepting the ciphertext the second time however violates the notions in [BHMS16, RZ18], meaning those do not reflect the behavior in QUIC or DTLS 1.3.

The need to handle non-unique ciphertexts.
Prior models [KPB03, BHMS16, RZ18] defined somewhat simpler notions based on the pivotal assumption (explicit in [KPB03], implicit in [BHMS16,RZ18]) that sent ciphertexts never repeat.The sliding-window approach and packet encoding specified for QUIC and DTLS 1.3 however requires us to handle non-unique ciphertexts.As we will see in more detail in Sections 6 and 7, both protocols transmit truncated packet numbers as part of the overall channel ciphertext, which means that, in principle, such ciphertexts are unique only within a sliding window, but may repeat across different sliding windows-without hindering correct receipt.While one can argue such repetitions are unlikely based on the core AEAD ciphertexts not colliding, this would mean to take such security properties into account even for correctness.Our more fine-grained approach instead allows the supp predicate to recover indices, enabling us to precisely capture the nature of these sliding-window approaches and their (unconditionally) correct functioning.
A Note on TLS.We focus on modeling robust channel behavior for unreliable transport.For completeness we discuss in Appendix A how reliable-transport channels like TLS can be captured through extended support predicates, relating our support classes further to the hierarchies in [KPB03, BHMS16,RZ18].In particular, we discuss a conceivable robust version of TLS that rejects invalid ciphertexts without terminating the connection, and the resulting security degradation that-similarly to QUIC and DTLS 1.3-would need to be taken into account.

Robust Channels
We now introduce our new notion of robustness for channel protocols.With this notion, we aim to model behavior that is already present in protocols like QUIC [IT21, TT21] and DTLS 1.3 [RTM21], namely that ciphertexts can be delivered out-of-order within a certain (sliding) window, and in addition the receiver is robust against any interleaved ciphertext which do not fit into the window (or are even maliciously crafted by a network adversary).Robustness here refers to a channel's property to filter out any misplaced ciphertexts and correctly receive those ciphertexts that fit into the supported order.We define robustness according to Figure 4.The experiment processes the received sequence of ciphertexts (into which the adversary is free to inject forged ciphertexts) through two separate receiving instances: The first, "real" receiving instance (run on state st r R ) is called on every received ciphertext (Line 10).The second, "correct" receiving instance (run on state st c R ) is only given those ciphertexts that are supported according to the predicate supp (Lines 12 and 14).Robustness then demands that, on any supported ciphertext, the output of the "correct" receiving instance never differs from the "real" instance's output.
To unpack the intuition behind our robustness formalism, recall first that we require supp(C S , DC R , c) = false on any non-genuine ciphertext c / ∈ C S .In the robustness experiment, the "correct" receiving instance is hence only called on (and DC R augmented with) genuine and supported ciphertexts c ∈ C S .Observe that this exactly corresponds to the Recv oracle's behavior in the correctness experiment (Figure 3), where the adversary may only submit genuine and supported ciphertexts.Correctness hence ensures that the "correct" receiving instance (run on state st c R ) outputs the expected (i.e., correct) messages, and so, transitively, the "real" instance, too, does so on supported ciphertexts.

Robustness, Integrity, and Indistinguishability
In this section we relate the notion of robustness to the classical notions of channel integrity and indistinguishability.

Defining Robustness and Integrity
Robustness of a channel allows one to make a statement about the behavior of the channel on supported sequences, even if there are malicious ciphertexts in-between.We can also define a notion of integrity of channels over unreliable networks.This notion says that the receiver should not decrypt any ciphertext to a valid message, unless the ciphertext is supported.We first give a "classical" definition of integrity and then introduce an equivalent version which is cast in the style of our notion of robustness.
Recv(c) / / robustness:  On the upper right-hand side of Figure 5, we present the notion of integrity, and in the lower left-hand side our alternative notion of integrity.Note that the given experiment Expt only differs in the receive oracle compared to the robustness experiment (cf. Figure 4) and hence we simply provide the details of the receive oracle as a description of the experiment.In more detail, in this experiment we only check on unsupported ciphertexts if they decrypt to a valid message m r different from m c .The latter is always set to ⊥ in Line 31 and not changed for unsupported ciphertexts, because the if-clause in Line 33 is skipped.
We first argue that the notions of integrity, the classical one and our alternative notion, are equivalent.This is easy to see since in both experiments the receiver's oracle behavior on supported ciphertexts is identical-in our notion one only performs a redundant receiving step-and on unsupported ciphertexts the receiver checks the received message against ⊥.Hence, we can define integrity with respect to either receive oracle: Let us emphasize that our notion of integrity wrt.supp generalizes established integrity notions, as per the connections to prior hierarchies drawn in Section 3.2.For example, INT(supp no ) encodes conventional stateless integrity, corresponding to the ct-int-ctxt1 and auth 1 notions of Kohno et al. [KPB03], resp.Boyd et al. [BHMS16], and INT(supp no-r ) corresponds to ct-int-ctxt2 resp.auth 2 of [KPB03,BHMS16].
The lower right hand side of Figure 5 shows a combination of both notions which we call robust integrity.The difference compared to integrity is that we now check if the message decrypts to the expected value (correct m c , resp.m c = ⊥) on both supported and unsupported ciphertexts.

Relating Robustness and Integrity
We next show that robustness and integrity imply robust integrity and vice versa.We start by showing that robust integrity implies the other two notions.

Proposition 5.3 (ROB-INT ⇒ ROB ∧ INT)
. Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate.Then for any adversary A we have Proof.The proposition is straightforward from the experiments.Consider an adversary against robustness resp.against integrity.Consider the first query c to the receive oracle which causes win to become true.Up to this point all three experiments for integrity, robustness, and robust integrity display an identical behavior, always returning ⊥ in the receiver's oracle and keeping the same lists C S , DC R of sent ciphertexts and supportedly received ciphertexts and support decisions.If an adversary now triggers win to become 1 in either the robustness experiment (on a supported ciphertext) or the integrity experiment (on an unsupported ciphertext), then the if-clause in Line 47 of the robust-integrity experiment (cf. Figure 5) also sets win to 1.
Robustness and integrity individually are incomparable, though.Assume that we have a channel which processes supported ciphertexts as expected, but on unsupported ciphertexts always outputs the message m = 0.This channel would be robust because it works correctly on supported ciphertexts, but it does not provide integrity nor robust integrity, because it returns the message m = 0 = ⊥ on all unsupported ciphertexts.Note that this channel would nonetheless be correct.
Next, assume that we have a channel which, when receiving the first unsupported ciphertext will output ⊥ but from then on decrypt all supported ciphertexts to message m = 0.This behavior is encoded in the channel's state.This channel is still correct because the bad event is never triggered on genuine ciphertext sequences.Furthermore, the channel provides integrity because on all unsupported ciphertexts the behavior correctly returns errors ⊥.However, the channel clearly does not provide robustness nor robust integrity because of the wrong decryption on supported ciphertexts after the first unsupported ciphertext, returning m = 0 = ⊥ on all such ciphertexts.
The above examples show that robustness or integrity alone do not suffice to guarantee robust integrity.In combination, though, they achieve the stronger notion as the next proposition shows.Proof.Assume that we have an adversary A which causes win to become true because the if-clause m r = m c in Line 47 of Figure 5 is satisfied.Consider the first query where this happens.Up to this point all experiments behave identically.In particular, the sequence DC R is the same in all runs in all cases.This implies that the set of supported ciphertexts is also identical up till then.There are now two cases when the robust integrity adversary triggers the bad event: • Either the call is for a supported ciphertext c, in which case we will run the "correct" receiver to get m c and will thus also reach Line 17 in the robustness experiment (cf. Figure 5) for the same value m c , setting win to true there.
• Or, the call is for an unsupported ciphertext c, in which case m c = ⊥ and we will reach Line 37 in the integrity experiment (cf. Figure 5), and win will become true there.
Hence, any break in the robust integrity experiment means that the adversary breaks robustness or integrity, such that we can bound the advantage for the former by the sum of the advantages for the latter.
We give a more formal separation of robustness and integrity here, based on the support predicates for no ordering (supp no ) and no ordering with global anti-replay (supp no-r ) as put forward in Section 3.2.Recv * (st * R , c): We first argue that correctness is preserved.This follows as the receiver in the correctness experiment is only invoked on supported ciphertexts, in which case Recv * behaves like Recv.The sender-side and in-order receiving conditions are satisfied as Send is unchanged and by ciphertext uniqueness.
For robustness, the output of Recv * deviates (m ← 0) from that of Recv only on unsupported ciphertexts, without modifying st R .Since any ciphertext supported by supp no-r is also supported by supp no , any robustness violation on Ch * translates to one on Ch via a reduction B relaying the Recv calls to its Recv oracle.
Finally consider an adversary C against the integrity of Ch * which sends an arbitrary ciphertext c twice to the receiver oracle.The second query will be unsupported (as c ∈ C R at this point), so Recv * returns the message 0. The integrity game then sets win to true as m r = 0 = ⊥ = m c .Proof.The channel protocol Ch * alters the receiver algorithm Recv from Ch and leaves Init, Send and aux unmodified, only the initial receiver state becomes st * R = (st R , (), 0).Define As in the proof of Proposition 5.5, the check in Line 5 mimics the check by Correctness is preserved because the receiver in the correctness experiment is only executed on supported ciphertexts, such that the bit f remains 0 and the receiver algorithms answers faithfully for all queries.The sender-side and in-order receiving conditions are satisfied as Send is unchanged and by ciphertext uniqueness.

Robustness and Chosen-Ciphertext Security
Let us begin this section with defining IND-CPA security.

Def inition 5.7 (IND-CPA)
. Let Ch = (Init, Send, Recv) be a channel and experiment Expt IND-CPA Ch,A for an adversary A be defined as in Figure 6.
We define the advantage of A in breaking indistinguishability of chosen plaintexts of Ch as and say that Ch is ≈ 0 for any polynomial-time A.
We next define ROB-INT-IND-CCA for channels which follows the paradigm to combine confidentiality and integrity into a single experiment, called IND-CCA3 in [Shr04].The formal details are displayed in Figure 7.The idea is to return a message different from m by the receiver oracle if the adversary has broken robustness or integrity via the submitted ciphertext c, and if b = 1 (whereas we always return ⊥ if b = 0).This enables the adversary to determine the bit b when breaking robust integrity.For this we overwrite m r with ⊥ if m r = m c and no break has occurred (Line 21).But if the messages are distinct we return the message which is not ⊥ (Line 23).

ROB-INT-IND-CCA(supp) Ch,A
for an adversary A be defined as in Figure 7.We define the advantage of A in breaking robust integrity/indistinguishability of chosen ciphertexts wrt.supp of Ch as   First observe that, up to the first query of A to Recv yielding a message m = ⊥ as output, B's simulation perfectly mimics the actual attack from A's point of view in the sense that even the concrete executions match.In particular, the lists of sent and received ciphertexts are identical.Assume that A in its original attack at some point obtains a response distinct from ⊥ from the (genuine or simulated) receiver oracle for a ciphertext c.This can only happen if b = 1 and • the decrypted message m r is different from ⊥ and from m c (Line 21), or In this case, the receiver's oracle of B will evaluate the condition m r = m c in Line 47 (cf. Figure 5) to true and make win become 1.It follows that B wins against robust integrity if A ever makes the receiver oracle return a message m = ⊥.
Given that we have now turned the receiver oracle in A's attack into the always rejecting ⊥(•) oracle, we can easily wrap A into an adversary C against the IND-CPA property.For this we let C answer each receiver query of A with ⊥, and let C relay all send queries faithfully.It follows that A's advantage is bounded by C's advantage.Note that B perfectly simulates the environment for A's attack, independently of the secret bit b.By assumption, A hence breaks robust integrity in the simulation with the same probability.Whenever this happens and b = 1 then B obtains a message m = ⊥ and thus outputs b = 1.If we denote this event, that A breaks integrity and that b = 1, by Succ, then the probability of B predicting b correctly if lower bounded by the sum that the event happens plus the probability that the event does not occur but B's random guess is correct: , where the latter follows since A's success probability is independent of the random bit b in B's experiment.
We next show that instead of starting from IND-CPA and using robust integrity to achieve ROB-INT-IND-CCA, we can also add robustness to a channel which already provides INT-IND-CCA to arrive there.This gives an alternative construction and proof method for such channels.One option to show this would be to argue that INT-IND-CCA implies integrity.This would allow to conclude that robustness with integrity implies robust integrity, and that the latter each Recv call with ⊥ but forwards the query to its own oracle.If at some point C receives a reply distinct from ⊥ in one of such queries then it immediately outputs 1, else it eventually outputs a random bit.An analysis similar to the one of Proposition 5.10 shows that C succeeds with an advantage of at least 1 4 times the probability that A wins with an unsupported ciphertext.

QUIC
QUIC was initially designed and implemented by Google.Currently, QUIC is in the process of being standardized by the IETF [IT21,TT21].
QUIC distinguishes a variety of different packet types, mostly following either a long or short packet format [IT21, Section 17].For reference, we illustrate both formats in Figure 9.Our analysis focuses on the short packet format, which in particular is used for sending main application data.

QUIC Encryption Specifications
In the following, we provide a brief overview of the encryption specifics of QUIC.QUIC packets consist of a header and a payload, the latter being encrypted using an AEAD scheme.For this encryption, the packet number forms the AEAD nonce (with a random offset per key), and the unprotected header is used as the associated data.Headers in particular contain between 1 and 4 bytes of the packet number, allowing the receiver to reconstruct the correct nonce of (possibly reordered) packets within an appropriately-sized sliding window.
After packet encryption, QUIC additionally applies a header protection mechanism based on one of the nonce-hiding AE constructions proposed by Bellare et al. [BNT19], and further allows keys to be updated during the channel's lifetime.Delignat-Lavaud et al. [DLFP + 20] treat the header protection mechanism in their analysis of the QUIC protocol, and we defer the interested reader to their paper as well as the specification [IT21,TT21].Following TLS 1.3 [Res18], QUIC further allows to update encryption keys within a connection; see Günther and Mazaheri [GM17] for a security model for such multi-key channel design over reliable transport.In our analysis of QUIC, we do not treat header protection or key updates.We argue that our results still provide reasonable insights into the robustness of the QUIC channel, if one is willing to assume that header protection (happening after our sending, resp.before our receiving steps) and key updates (corresponding to a sequence of robust channels per phase) work as intended.Analyzing the QUIC channel in a model treating all these aspects is left as an avenue for future work.

QUIC as a Channel Protocol
When capturing QUIC as a cryptographic channel protocol, the first question arising is which interfaces to higher-and lower-level protocols should be considered.The lower-level interface is simple: running over UDP, QUIC outputs distinct (atomic) chunks of ciphertexts accompanied by headers in a datagramoriented manner.
For the higher-level interface, things are less clear: While QUIC offers a multiplexed interface of several parallel data streams to an application, its cryptographic packet protection merely works on atomic chunks of payload data which results from QUIC-internal, higher-level multiplexing and other processing.

Construction
We capture QUIC as the channel protocol Ch QUIC = (Init, Send, Recv, aux) described in Figure 10.It is built from any AEAD scheme AEAD = (Enc, Dec) with associated key space K and error symbol ⊥, the latter being inherited by the construction.QUIC employs a dynamic sliding window with an anti-replay window (for some arbitrary, but fixed replay window size w r ), i.e., we can precisely capture the supported network behavior by QUIC through the support predicate supp dw-r[wr] as defined in Section 3.2.QUIC's sliding window is set dynamically on the sender side, spanning 1-4 bytes wide around the next expected packet number pn R (i.e., the one subsequent to the highest successfully received packet number), where pn R is the rightmost entry in the left half of the window.We formalize this through an auxiliary information space X = {(2 7 − 1, 2 7 ), (2 15 − 1, 2 15 ), (2 23 − 1, 2 23 ), (2 31 − 1, 2 31 )} corresponding to 8, 16, 24, and 32 bit wide windows respectively, with (almost) half-sized w b + 1 = w f .5 Packet numbers play a crucial role for the sliding-windows technique in QUIC, and hence also in the construction.As described in Section 6.1, QUIC packet numbers determine the nonce and also (partially) the associated data for the AEAD scheme.Packet numbers are a running integer counter on the sender's side in the range from 0 to 2 62 − 1. QUIC then derives the nonce for packet encryption as the XOR of a (static) initialization vector IV (a 96-bit value obtained through key generation) and the packet number (accordingly padded with 0-bits).In our construction, this translates to sampling IV at random upon channel initialization and deriving the sending nonce based on a running sending counter pn S .While QUIC puts various header information in its packets (which enters the AEAD encryption as associated data), we focus here only on the partial, encoded packet number epn; i.e., the ciphertext space C = {0, 1} 8,16,24,32 ×{0, 1} * consists of the encoded packet number (of length n ∈ {8, 16, 24, 32}) and a (variablelength) AEAD ciphertext.Upon sending, epn is derived as the last n bits (for a dynamic sliding window size n) of the sending packet number pn S .Upon receiving, epn (of length n) is decoded to the (unique) packet number matching epn in its last n bits number which is contained in the 2 n -sized window centered around the next expected packet number pn R [IT21, Appendix A].We capture these encoding and decoding steps through the following sub-algorithms, and illustrate decoding within a sliding window in Figure 11.
Init.The initialization algorithm samples uniformly at random a key K from the AEAD key space K and (static) initialization vector IV of 96 bits length.The sending and receiving state, beyond K and IV , contain counters for the next packet number to be sent pn S , resp. to be received pn R , initialized to 0. Furthermore, the receiving state holds a (initially all-zero) bitmap R of size w r + 1 later used to record previously seen packet numbers in a window of size w r before the last successfully received packet number (+1 to account for the latter, too).
Send.The sending algorithm first ensures that the sending packet number pn S does not exceed the maximal value of 2 62 − 1.It derives the encoded packet number epn to be transmitted as the least significant In this situation, a received partial packet number epn = 000 2 will be (uniquely) decoded to pn = 8 = 1000 2 within the window (marked with diagonal lines), leading pn R to be updated to pn R = 9, moving both windows forward next.
1-4 bytes of pn S , captured through the Encode algorithm given above.It then computes the packet encryption nonce N as the XOR of the static IV and the running packet number pn S (implicitly padded to a 96-bit bitstring).The ciphertext c is computed as the AEAD-encryption of the input message m, using N as nonce and epn as associated data.The encoded packet number epn together with c form the full ciphertext c.The final output is the sending state, with the packet number incremented, together with c.
Recv.The receiving algorithm begins with decoding the encoded packet number epn in the ciphertext to the full packet number pn within the dynamic sliding window around pn R determined by |epn|; captured in the Decode algorithm given above.It then AEAD-decrypts the ciphertext c using N = IV ⊕ pn as nonce and epn as associated data, rejecting if this step fails (Line 24 of Figure 10).The algorithm also rejects if pn is older than what is represented in the replay-check window (of w r positions before the last successfully received packet number pn R − 1) and hence cannot be ensured to not be replayed (Line 25).Finally, it rejects if pn has been processed previously (determined by the bitmask R being 1 at the position corresponding to pn, Line 26).Otherwise, R is marked with a 1 at the position corresponding to pn, possibly shifted before in case pn is greater than the previously highest received packet number.The final output is the updated state and message m.
aux.The auxiliary sliding-window information of a ciphertext (epn, c ) is recovered as backward/forward windows half the size of epn, i.e., aux , where n = |epn|.

Correctness
To establish correctness wrt.support class supp dw-r[wr] (as defined in Section 3.2), we have to show that (1) aux correctly recovers the auxiliary information used to sent a ciphertext; (2) supp dw-r[wr] = true when ciphertexts are delivered in perfect order; and (3) Recv correctly receives messages of supported, genuinely sent ciphertexts.We will show that this holds unconditionally, i.e., Adv correct(supp dw-r[wr ] ) Ch QUIC ,A = 0. Observe that (1) follows directly from the definition of Encode, and (2) follows from the construction, as ciphertexts are unique within their dynamic sliding window and hence always supported when delivered perfectly in-order.For (3), observe that a genuine QUIC channel ciphertext (epn, c ) is unique within the sliding window (of size |epn|) it defines.This gives rise to the following property of QUIC's nonce encoding, which we denote as correct decodability: For any expected next packet number to be received pn R ∈ [0, 2 62 − 1], sliding window (w b , w f ) ∈ X , and (sending) packet number pn S ∈ [pn R − min(w b , w r + 1), pn R + w f ], it holds that Decode(Encode(pn S , aux), pn R ) = pn S .This is achieved in QUIC by interpreting the encoded packet number in a window of bit-size the encoded number's length (i.e., (w b +1+w f ) ∈ {2 8 , 2 16 , 2 24 , 2 32 }) [IT21, Appendix A], while dropping packets outside of the replay window w r before the last successfully received packet.
In order to violate correct message receipt, an adversary needs to invoke Recv on a supported ciphertext (i.e., d = supp dw-r[wr] (C S , DC R , c) needs to be true in Line 19 of Figure 3) such that c decrypts to a different message than was sent.The support predicate supp dw-r[wr] ensures that the sent index of a ciphertext (corresponding to pn S + 1, as QUIC packet number begins with 0) is in the interval [nxt − min(w c b , w r + 1), nxt + w c f ], where (w c b , w c f ) is the auxiliary information from the Send call and nxt is the next expected index (corresponding to pn R + 1).QUIC's correct decodability then ensures that the decoded packet number pn equals the pn S value used within the call to Send that output c.Hence, as AD = epn and c is part of c, Recv invokes AEAD decryption Dec on c with the same nonce and associated data as in the corresponding encryption step in Send.By correctness of the AEAD scheme, the decrypted message will hence always equal the sent message.

Robust Security of the QUIC Channel Protocol
We can now turn to the security analysis of QUIC, taking its robust handling of the underlying unreliable network into account.As we will show, QUIC achieves robust confidentiality and integrity (according to the combined notion ROB-INT-IND-CCA), receiving ciphertexts within a dynamic sliding window and with a window-based replay protection; i.e., formally wrt. the support predicate supp dw-r[wr] from Section 3.2.Leveraging the relations between notions, we separately establish robust integrity as well as indistinguishability under chosen-plaintext attacks, yielding the combined robust confidentiality and integrity guarantees via Proposition 5.9.
Compared to secure channels over reliable transports (like TLS over TCP), the integrity bound is not tight but, at its core, contains a loss linear in the number of received ciphertexts (denoted by q R in the theorem statement below): the channel's robustness leads to the adversary being able make multiple forgery attempts on the underlying AEAD scheme-in principle with every delivered ciphertext.This result matches the linear loss in the security bounds of many AEAD schemes, including AES-CCM [Jon03], AES-GCM [IOM12a,IOM12b], and ChaCha20+Poly1305 [Pro14] underlying QUIC and DTLS 1.3.It also coincides with the observation that vulnerabilities in a channel's encryption scheme are easier to exploit over non-reliable networks; see, e.g., the Lucky Thirteen attack on the (D)TLS record protocols [AP13].Surprisingly, this higher security loss (compared to TLS) was so far not considered in DTLS version up to 1.2 and earlier versions of QUIC (prior to draft-29) and DTLS 1.3 (prior to draft-38).Based on our work, both protocol's IETF working groups added concrete forgery limits on packet protection [TT20, Tho20a, RTM20, Tho20b], requiring that implementations "MUST count the number of received packets that fail authentication" and ensure this number stays below certain thresholds (2 36 for AES-GCM and ChaCha20+Poly1305, 2 23.5 for AES-CCM, factoring in the precise security degradation of each scheme and a targeted INT-CTXT advantage of at most 2 −57 ).Theorem 6.1 (Robust integrity of QUIC).Let Ch QUIC be the channel construction from Figure 10 from an AEAD scheme AEAD = (Enc, Dec), and support predicate supp dw-r[wr] be defined as in Section 3.2.Let A be an adversary against Ch QUIC in the robust integrity experiment Expt

ROB-INT(supp dw-r[wr ] )
Ch QUIC ,A from Figure 5 making q S queries to Send and q R queries to Recv.There exists an adversary B (given in the proof) against the multi-target authenticity of AEAD that makes q S queries to its encryption oracle Enc and at most q R queries to its Forge oracle, such that Proof.The core idea of the proof is to show that whenever the receiving oracle Recv is called in the robust integrity experiment Expt We show (a) and (b) hold for unsupported ciphertexts because Recv always returns an error in this case, either due to replay checks or AEAD decryption yielding an error.This holds unconditionally for the replay checks, while we argue the AEAD error case via a reduction B to the INT-CTXT security of the AEAD scheme.We call the event that an unsupported ciphertext is not rejected because of replay checks-and we are hence relying on the AEAD error-a "forgery attempt."Observe that B can identify such forgery attempts itself by checking the results of supp and the replay check.In the argument below, we show that upon such a forgery attempt, B can send some (N, AD, c ) to its Forge oracle which is (in principle) a permissible forgery because c was never output by encryption using nonce N and associated data AD.The reduction B will make at most q R such calls, and if any of the forgery attempt event does not yield in an AEAD decryption error, B breaks the multi-target integrity of the AEAD scheme, which gives the bound of the theorem.
The reduction B simulates the robust integrity game Expt

ROB-INT(supp dw-r[wr ] )
Ch QUIC ,A for A by not sampling a key K itself but using its encryption oracle to emulate the Enc calls within Send (q S times overall).To simulate the Recv oracle, B proceeds as follows: Whenever supp dw-r[wr] (C S , DC R , c) = true, B accounts for changes of pn R , obtaining the packet number regularly as Decode(epn, pn R ).Otherwise, it checks for replays and in case of a "forgery attempt", B submits (N = IV ⊕ Decode(epn, pn R ), epn, c ) as an attempted forgery to its Forge oracle.It does not need to update pn R .In either case, B does not need to perform decryption as Recv always returns ⊥.
First observe that, with unsupported ciphertexts being rejected in Lines 24-26, we have that pn R is only updated on supported ciphertexts and equals nxt = max(D R ) + 1 in the support predicate.Let us consider the cases in which a ciphertext c = (epn, c ) input to Recv is unsupported (i.e., supp dw-r[wr] (C S , DC R , c) = false).
is not in the admissible window (and hence cindex returns false), then we distinguish the cases according to the relationship of the replay-window size and the backward-window size:  b + w c f + 1).This packet number is either within the replay-check window (hence was marked previously, and is now rejected in Line 26) or is beyond that window (and hence rejected in Line 25).
Finally, observe that properties (a) and (b) above may only be violated in case 1.2.above when Dec(N = IV ⊕ pn, AD = epn, c ) = ⊥.In this case, B wins through its Forge call; B making at most q R such calls yields the overall ROB-INT bound of Adv INT-CTXT AEAD,B (q R ). On

DTLS 1.3
DTLS can be seen as a variant of TLS, running atop the unreliable transport protocol UDP, aiming to provide similar security guarantees even if records arrive out-of-order or may be duplicated-by the network, or an active adversary.Currently, the next protocol version DTLS 1.3 [RTM21] is in the process of being standardized by the IETF.
In the following we provide the full details on our channel construction for DTLS 1.3.We first describe the encryption specification for DTLS 1.3 and then provide the full details about the construction.In the final part, we show that this channel construction is ROB-INT-IND-CCA secure.Our analysis reveals that DTLS 1.3, like QUIC, has to tolerate multiple forgery attempts leading to a loss linear in the number of received ciphertexts (q R ) through a multi-target INT-CTXT bound with (up to) this many forgeries.We have informed the responsible IETF TLS working group about our observation.Based on this input, the working group has added concrete forgery limits on packet protection in DTLS 1.3 draft-38 [RTM20,Tho20b].Those place an effective upper bound on the robust integrity loss by requiring that implementations ensure that the number of received packets that fail authentication remains below certain specified thresholds (cf.Section 6.3).

DTLS Encryption Specifications
The record layer of DTLS 1.3 is different from the one in TLS 1.3 in the sense that DTLS 1.3 adds an explicit sequence number and an epoch to the ciphertext.DTLS 1.3 ciphertexts follow either the full or minimal format illustrated in Figure 12.
Let us have a closer look at the encryption specifics in DTLS 1.3.A DTLS ciphertext consists of a (protected) header and an encrypted record which is generated using an AEAD scheme.As an input, the encryption algorithm takes (as usual) four inputs, namely the key K, the nonce N , the associated data AD, as well as the message m.The specification of DTLS 1.3 [RTM21] details how the above inputs are derived.The (per-record) nonce [RTM21, Section 4] is derived by concatenating a 16-bit (key) epoch number with a 48-bit sequence number obtaining a 64-bit record sequence number. 6This value is then left-padded with zeros up to the nonce length.Finally this padded sequence number is XORed with a static, random initialization vector IV (derived along with the key) to obtain the nonce.The associated data covers the ciphertext header (full or minimal, cf. Figure 12), in particular including the truncated 8or 16-bit sequence number field.
Similar to QUIC, DTLS 1.3 employs a form of header protection [RTM21, Section 4.2.3],namely encrypting the sequence number.For this, a separate sequence number key is derived that is used with the underlying encryption algorithm to generate a mask which is then XORed with the sequence number.
We do not treat key updates and header protection in our following channel construction of DTLS 1.3.However, we argue that our results provide meaningful insights into the robustness of the DTLS 1.3 channel as long as one assumes that both the key updates and header protection function as intended.Similar to QUIC, we leave it as an avenue for future work to confirm these assumptions and analyze the DTLS 1.3 channel covering all of these aspects.

DTLS as a Channel Protocol
In the following, we aim to provide a cryptographic channel protocol capturing DTLS 1.3.As in Section 6, our focus for DTLS 1.3 is to show that our construction is indeed a robust channel.

Construction
We capture DTLS as the channel protocol Ch DTLS = (Init, Send, Recv, aux) described in Figure 13.It uses an arbitrary AEAD scheme AEAD = (Enc, Dec) (as defined in Section 2.2) with associated key space K and error symbol ⊥, the latter being inherited by the construction.Similar to QUIC's behavior of ciphertext processing, the construction of DTLS 1.3 also employs a dynamic sliding-window technique with an antireplay window as derived from the support predicate supp dw-r[wr] for some scheme-dependent fixed replay window size w r as detailed in Section 3.2.The sliding window is set dynamically on the sender side which is spanned around the next expected sequence number sn R and has a size of either 8 or 16 bits.Note that the expected sequence number corresponds to the largest successfully received sequence number (on the receiving side) plus one modeling that the channel expects that the next receiving sequence number is being incremented since a new ciphertext may be received and hence the window "moves" towards the right.We formalize this through an auxiliary information space X = {(2 7 − 1, 2 7 ), (2 15 − 1, 2 15 )} corresponding to 8-bit and 16-bit wide windows, respectively, with (almost) half-sized limits w b + 1 = w f .In DTLS, sequence numbers and epochs play a crucial role for the sliding-window technique.Both values are used to compute the nonce and additionally the epoch serves the purpose to keep track of key updates, i.e., the epoch is incremented whenever a key update has occurred.As mentioned above, we do not model key updates here and hence do not consider epochs explicitly in the construction and only rely on sequence numbers.Note that the concept of sequence numbers is in spirit very close to the packet numbers being used in QUIC.
As described in Section 7.1, sequence numbers are used in deriving the nonce and also (partially) the associated data for the AEAD scheme.Sequence numbers are a running 48-bit integer counter on the sender's side in the range from 0 to 2 48 − 1. DTLS 1.3 then derives the nonce as the XOR of the initialization vector IV which is an r-bit value (where r is the AEAD scheme's nonce length) obtained though key generation, and the sequence number which is accordingly padded with zeros from the left.In our construction, this translates to sampling IV at random upon channel initialization and deriving the nonce on sending based on the running sn S counter.DTLS 1.3 includes various header information into the associated data that enters the AEAD encryption process, we limit that information for modeling purposes to the encoded sequence number consisting of the least 8 or 16 bits of the full sequence number.The ciphertext space C = {0, 1} n × {0, 1} * accordingly consist of the encoded sequence number of length n ∈ {8, 16} and a variable-length AEAD ciphertext.Upon sending the encrypted record, DTLS 1.3 includes in the header an encoded sequence number whose encoding is derived in the sending algorithm based on the sequence number sn S and the dynamic sliding window size given through the auxiliary input.While receiving the ciphertext, the receiver algorithm aims to reconstruct the (full) sequence number from the encoded one which is numerically closest to the next expected sequence number sn R (cf.[RTM21, Section 4.2.2]).Note that this corresponds to the same encoding/decoding principle as put forward by QUIC (cf.Section 6.2.1).Therefore, we have the following two sub-algorithms that handle encoding and decoding respectively: Encode(snS, aux): Decode(esn, snR): In more detail, the construction works as follows.
Init.The initialization algorithm starts with sampling a key K uniformly at random from the key space K of the AEAD scheme, as well as a random (static) initialization vector IV of r bits length (where r is the AEAD scheme's nonce length).The sending and receiving state, beyond K and IV , contain sending and receiving packet numbers pn S and pn R , respectively, initialized to 0. The receiving state furthermore contains an (initially all-zero) bitmap R of size w r + 1 to record previously received sequence numbers and providing for later use a replay protection mechanism.
Send.The sending algorithm first ensures that the sending (record) sequence number sn S does not exceed the maximal value of 2 48 − 1.It then sets this sequence number to correspond to associated data.Then it continues computing the per-record nonce N as the XOR of the sequence number (implicitly padded to an r-bit string) with the initialization vector.The ciphertext c is the computed as the AEAD-encryption of the input message m, using N as nonce and sn S as associated data.Next it derives the encoded sequence number esn as the least 8 or 16 bits of sn S which is captured by running the above Encode algorithm.The full ciphertext c is then formed as the pair consisting of encoded sequence number esn and the AEAD ciphertext c .The final output is the sending state, with the sequence number incremented, together with c.
Recv.The receiving algorithm begins with decoding the encoded sequence number in the ciphertext to the full sequence number sn within the dynamic sliding window centered around sn R and determined through the length of esn which we capture by running the above decoding algorithm Decode.In order to avoid timing attacks, the algorithm first prepares the required inputs to perform the AEAD decryption algorithm and only checks afterwards if the sequence number is valid ensuring that no replay has occurred.In more detail, the algorithm rejects if the AEAD decryption failed, or if the received sequence number is older than (and hence before) the current replay window, or if the sequence number has indeed been previously processed which is determined by checking whether R contains a bit 1 at the respective position of the sequence number.Otherwise, if the previous checks were successful then R is marked with 1 at the corresponding position of sn (either directly or after shifting the replay window in case sn is greater than the previously highest received sequence number sn R ).The final output is the receiving state, with the sequence number being incremented, and the successfully decrypted message m.
aux.This helper algorithm recovers the auxiliary sliding-window information of a ciphertext (esn, c ) as backward/forward windows that are half of the size of esn.Hence we obtain aux = (w c b , w c f ) = (2 n−1 − 1, 2 n−1 ), where n = |esn|.

Correctness
In order to argue correctness for the DTLS 1.3 channel construction wrt.support class supp dw-r[wr] , we need to show that (1) aux correctly recovers the auxiliary information used to sent a ciphertext; (2) supp dw-r[wr] = true when ciphertexts are delivered in perfect order; and (3) Recv correctly receives messages of supported, genuinely sent ciphertexts.We will show that this holds unconditionally.
For (1), we can conclude from the definition of the encoding algorithm Encode that aux correctly recovers the auxiliary information.For (2), ciphertexts being unique within their dynamic sliding window ensures they are always supported when delivered perfectly in-order.For (3), we need to argue that DTLS 1.3 correctly receives messages from ciphertexts wrt. to the support predicate supp dw-r [wr] .Let us first observe that we require the same property as in QUIC about the nonce encoding for the AEAD scheme, namely correct decodability (cf.Section 6.2.1).In more detail, we require that for any next expected sequence number to be received sn R ∈ [0, 2 48 − 1], any sliding window (w b , w f ) ∈ X , and any sequence number sn S ∈ [sn R − min(w b , w r + 1), sn R + w f ], it holds that Decode(Encode(sn S , aux), sn R ) = sn S .
The above construction of DTLS achieves this property by interpreting the encoded sequence number within a window of the sequence number's length, i.e., (w b + 1 + w f ) ∈ {2 8 , 2 16 }.Furthermore, any packet containing a sequence number which is outside of the replay window will be discarded.
In order to violate correct receipt of a message, an adversary needs to invoke Recv on a supported ciphertext (i.e., supp dw-r[wr] (C S , DC R , c) = false in Line 19 of Figure 3) such that c decrypts to a different message than the one that was originally sent.The given support predicate supp dw-r[wr] ensures that the sent index of a ciphertext is in the interval [nxt − min(w c b , w r + 1), nxt + w c f ], where (w c b , w c f ) is the auxiliary sliding-window information from the aux call and nxt is the next expected index (corresponding to sn R +1).The correct decodability property of DTLS 1.3 ensures that the decoded (full) sequence number sn equals the sn S sequence number used within the call to Send that output c.Hence, as AD = sn and c is part of c, Recv invokes AEAD decryption Dec on c with the same nonce and associated data as in the corresponding encryption step in Send.By correctness of the AEAD scheme, the decrypted message will hence always equal the sent message, and thus the adversary has no further advantage in breaking correctness.

Robust Security of the DTLS Channel Protocol
We finally turn to analyzing the robust security of DTLS 1.3.In more detail, we wish to show on the one hand that our above channel construction from Figure 13 achieves robust integrity for the support predicate supp dw-r [wr] .Additionally, we show that this construction also achieves confidentiality for the same support predicate.Following the implication that we established in Section 5.3 with Proposition 5.9, we then finally argue that our channel construction for DTLS 1.3 achieves the combined ROB-INT-IND-CCA notion.
Before diving into the formal details, let us emphasize that-similar to our QUIC analysis-the integrity bound is not tight and contains a loss linear in the number of received ciphertexts (denoted by q R in the following theorem statement).
Theorem 7.1 (Robust Integrity of DTLS).Let Ch DTLS be the channel construction from Figure 13 from an AEAD scheme AEAD = (Enc, Dec), and support predicate supp dw-r[wr] be defined as in Section 3.2.Let A be an adversary against Ch DTLS in the robust integrity experiment Expt ROB-INT(supp dw-r[wr ] ) Ch DTLS ,A from Figure 5 making q S queries to Send and q R queries to Recv.There exists an adversary B (given in the proof) against the multi-target authenticity of AEAD that makes q S queries to its encryption oracle Enc and at most q R queries to its Forge oracle, such that AEAD,B (q R ).Proof.The idea of the proof is identical to the robust integrity proof of QUIC (cf.Theorem 6.1) and mainly only the syntax differs.We start with reviewing the idea and then provide the respective details for our channel construction Ch DTLS .
The main idea of the proof is to show that whenever the receiving oracle Recv is called in the robust integrity experiment Expt In the following, we show that both properties (a) and (b) hold for non-supported ciphertexts since Recv always returns an error wither due to the AEAD decryption error or the employed replay checks.This holds unconditionally for the latter case, and for the former one (AEAD decryption error) we argue via a reduction B to the INT-CTXT of the AEAD scheme.We start with calling such an event a "forgery attempt".Observe that the reduction B can identify such forgery attempts by checking the results of the support predicate supp and the replay check.In the following, we show that upon such a forgery attempt, B sends some triple of the form (N, AD, c ) to its Forge oracle since the ciphertext was never an output by an AEAD encryption using the nonce N and associated data AD.B will make at most q R calls of this form, and if any of these forgery attempts does not output an AEAD decryption error, then B breaks the multi-target integrity of the AEAD scheme yielding our bound of the theorem.
The reduction B simulates the robust integrity game Expt for A by not sampling a key K itself but using its encryption oracle to emulate the Enc calls within Send.To simulate the Recv oracle, B proceeds as follows: Whenever the ciphertext is supported, i.e., supp dw-r[wr] (C S , DC R , c) = true, then B accounts for changes of sn R (obtaining the sequence number as usual via Decode(esn, sn R )).Otherwise, it checks for replays and in case of a forgery attempt, B provides (IV ⊕Decode(esn, sn R ), esn, c ) as its forgery attempt to its Forge oracle, and does not need to update sn R here.Note that in both cases, B does not perform decryption as Recv always simply returns ⊥.
Observe that an unsupported ciphertext is rejected in Lines 24-26, and hence the sequence number sn R is only updated on supported ciphertexts and equals nxt = max(D R ) + 1 in the support predicate.Let us now consider the cases where a ciphertext of the form c = (esn, c ) as input to Recv can be unsupported.

If c /
∈ C S [nxt − min(w c b , w r + 1), nxt + w c f ] is not in the admissible window (and hence cindex returns false), then we have to distinguish the two cases according to the relationship of the replay-window size and backwards window size: .This sequence number is either within the replay-check window (hence was marked previously, and is now rejected in Line 26) or is beyond that window (and hence rejected in Line 25).
Finally, we can observe that the properties (a) and (b) can only be violated in Case 1.2.when Dec(N = IV ⊕ sn, AD = esn, c ) = ⊥, in which case B wins through this Forge call.Since B makes at most q R such calls, the overall bound is Adv INT-CTXT AEAD,B (q R ).Adversary B simulates the (left-or-right) IND-CPA experiment for A faithfully with the only exception that it does not sample its own key K as well as does not pick the challenge bit b.To simulate the Send oracle, B proceeds as follows.It performs an initialization phase where it samples at random an initialization vector IV as well as initializes the sending sequence number sn S to 0. Furthermore, B prepares the nonce and associated data by setting the sequence number to correspond to the associated data, and it performs an XOR operation of the initialization vector and the (appropriately padded) sequence number obtaining the nonce.Upon receiving a message pair (m 0 , m 1 ) from A, B sends the tuple (N, AD, m 0 , m 1 ) to its oracle.It receives back a ciphertext c .B then encodes the sequence number obtaining esn which together with c builds the full ciphertext c and it increments the sequence number.Next, it provides the ciphertext c to A. When A eventually outputs a guess b , then B simply forwards b as its own guess.
Note that B perfectly simulates the experiment Expt Using the results from the above proofs, we can conclude via Proposition 5.9 that our channel construction for DTLS 1.3 achieves ROB-INT-IND-CCA security.

Figure 1 :
Figure 1: Overview over relationships of robustness, integrity, and indistinguishability notions for any fixed predicate supp; with notions encoding robustness highlighted in gray.Solid arrows from A to C via B indicate implications A ∧ B ⇒ C. Dotted arrows from A to B indicate explicitly shown implications A ⇒ B; further implications follow by transitivity.Dashed, struck-through arrows between A and B indicate separations of A and B. Numbers indicate the corresponding propositions.
1} * takes as input a secret key K, a nonce N , associated data AD, and a message m, and outputs a ciphertext c. • Deterministic decryption Dec : K × N × H × {0, 1} * → M ∪ {⊥} takes as input a secret key K, a nonce N , associated data AD, and a ciphertext c, and outputs either a message m ∈ M or a dedicated error symbol ⊥ indicating that the ciphertext is invalid.

Figure 3 :
Figure 3: Experiment for correctness wrt.support class supp of a channel protocol Ch.

Figure 4 :
Figure 4: Experiment for robustness wrt.support class supp of a channel protocol Ch.

Def inition 4
.1 (Robustness of channels, ROB).Let Ch = (Init, Send, Recv) be a channel, supp a correctness support predicate, and experiment Expt ROB(supp) Ch,A for an adversary A be defined as in Figure 4. We define the advantage of A in breaking robustness wrt.supp of Ch as Adv ROB(supp) Ch,A := Pr Expt ROB(supp) Ch,A ⇒ 1 , and say that Ch is robust wrt.supp if Adv ROB(supp) Ch,A is negligible for any polynomial-time A.

Figure 5 :
Figure 5: Receiver oracles in the experiments for robustness (upper left), integrity (upper right), alternative integrity (lower left) and robust integrity (lower right) wrt.support class supp of a channel protocol Ch.Differences are highlighted in grey boxes .
Def inition 5.1 (Integrity of channels, INT ).Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate, and experiment Expt INT(supp) Ch,A for an adversary A be defined as on the upper right hand side or lower left hand side in Figure 5.We define the advantage of A in breaking integrity wrt.supp of Ch as Adv INT(supp) Ch,A := Pr Expt INT(supp) Ch,A ⇒ 1 .We say that Ch provides integrity wrt.supp if Adv INT(supp) Ch,A is negligible for any polynomial-time A.

Def inition 5. 2 (
Robust integrity of channels, ROB-INT).Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate, and experiment Expt ROB-INT(supp) Ch,A for an adversary A be defined as on the lower right hand side in Figure 5.We define the advantage of A in breaking robust integrity wrt.supp of Ch as Adv ROB-INT(supp) Ch,A := Pr Expt ROB-INT(supp) Ch,A ⇒ 1 , and say that Ch achieves robust integrity wrt.supp if Adv ROB-INT(supp) Ch,A is negligible for any polynomial-time adversary A.

Proposition 5. 4 (
ROB ∧ INT ⇒ ROB-INT).Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate.Then for any adversary A we have Adv Proposition 5.5 (ROB ⇒ INT).Let Ch = (Init, Send, Recv, aux) be a perfectly correct, robust, and integrous channel wrt.support predicate supp no with unique ciphertexts.Then there is a channel protocol Ch * = (Init * , Send * , Recv * , aux * ) such that for any adversary A, there exist adversaries B and C such that Adv correct(supp no-r ) Ch * ,A = 0, Adv ROB(supp no-r ) Ch * ,A = Adv ROB(supp no ) Ch,B , but Adv INT(supp no-r ) Ch * ,C = 1.Proof.The new channel Ch * only modifies the receiver algorithm Recv from Ch and leaves Init, Send and aux essentially unchanged, only the initial receiver state becomes st * R = (st R , ()).Define

4 CR ← − c 5 else 6 m ← 0 7
return ((stR, CR), m) Observe that since Ch is correct, robust and integrous, Recv outputs m = ⊥ if and only if supp no (C S , DC R , c) = c ∈ C S = true.The check in Line 3 exactly corresponds to the check by supp no-r (C S , DC R
order to violate INT-IND-CCA security, the adversary A needs to make Recv * output a message m = ⊥ on an unsupported ciphertext c, i.e., for c / ∈ C S or c ∈ C R .In the latter case, Recv * always outputs ⊥.Otherwise, it relays the output of Recv, so if c / ∈ C S , Recv outputting m = ⊥ is a violation of the INT-IND-CCA security of Ch wrt.supp no .A simple relaying reduction B hence yields the claim.The adversary C against robustness first calls the sender about the message m = 1 to get a ciphertext c.Then it calls the receiver oracle on c twice.Since this ciphertext is supported in the first call and unsupported in the second call, the latter turns the receiver's state st * ,r R to (st R , (c), 1), but leaves st * ,c R unaltered from the previous valid call.Then the adversary calls the sender about message m = 1 again to get a ciphertext c and forwards c to the receiver oracle.According to correctness of the original channel the ciphertext c must be supported and result in the message m c = 1; the reason is that from Expt IND-CPA Ch,A

Figure 6 :
Figure 6: Experiment for IND-CPA of a channel protocol Ch.
and say that Ch is ROB-INT-IND-CCA-secure wrt.supp if Adv ROB-INT-IND-CCA(supp) Ch,A is negligible for any polynomial-time adversary A. The next proposition says that a channel achieves ROB-INT-IND-CCA if it has both robust integrity (ROB-INT) and IND-CPA confidentiality.

Figure 7 :
Figure 7: Experiment for ROB-INT-IND-CCA wrt.support class supp of a channel protocol Ch.

.
In the following, we show that robust integrity (ROB-INT) and IND-CPA are both necessary to achieve the ROB-INT-IND-CCA property.Proposition 5.10 (ROB-INT-IND-CCA ⇒ ROB-INT ∧ IND-CPA).Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate.Then for any adversary A there exists adversary B with comparable run time such that we have Proof.Clearly, if we can break IND-CPA security of the channel, then we also break ROB-INT-IND-CCA security (by omitting calls to the receiver oracle).We next argue that we can break ROB-INT-IND-CCA if we can break robust integrity, too.Assume that we have an attacker A against robust integrity.We build an attacker B against the ROB-INT-IND-CCA property.Algorithm B simulates A by answering each call (m, aux) to the Send oracle by forwarding (m, m, aux) to its own Send oracle and handing back the ciphertext c.Each of A's call to Recv is forwarded by B to its own receiver oracle, and B returns ⊥ to A. If the receiver oracle at some point returns a message m = ⊥ to B then B immediately outputs 1; in any other case it outputs a random bit.
yields ROB-INT-IND-CCA together with the IND-CPA security of the channel.Here, we show the security of the transform directly starting from INT-IND-CCA and adding robustness.Def inition 5.11 (INT-IND-CCA).Let Ch = (Init, Send, Recv, aux) be a channel, supp a support predicate, and experiment Expt INT-IND-CCA(supp) Ch,A for an adversary A be defined as in Figure 8.We define the advantage of A in breaking integrity/indistinguishability of chosen ciphertexts wrt.supp of Ch as Adv INT-IND-CCA(supp) Ch,A := Pr Expt INT-IND-CCA(supp) Ch,A ⇒ 1 − 1 2 ,

Figure 9 :
Figure 9: QUIC packet formats for long (left) and short (right) packets [IT21, Section 17].The first byte contains flags T: Type, R: Reserved, P: Packet number length, S: Spin, K: Key phase.Field bit-length is given in parentheses, (*) indicating variable length.

Figure 11 :
Figure 11: Exemplary illustration of a dynamic sliding receiving window of (toy) size 2 n = 8 (i.e., w b = 3 and w f = 4) around the next expected packet number pn R = 5 = 0101 2 , replay-check window of size w r + 1 = 4. Packet numbers 1 and 4 have been received before, crossed-out in the replay-window.Grayed-out packet numbers are outside the current sliding window.In this situation, a received partial packet number epn = 000 2 will be (uniquely) decoded to pn = 8 = 1000 2 within the window (marked with diagonal lines), leading pn R to be updated to pn R = 9, moving both windows forward next.
ROB-INT(suppdw-r[wr ] ) Ch QUIC ,A on a ciphertext c = (epn, c ) such that supp dw-r[wr] (C S , DC R , c) = false (and hence correct receiving is skipped), we have that (a) the real receiving state st r R remains unchanged in that oracle call, and (b) the real received message is an error, i.e., m r = ⊥.We argue these properties by showing that Recv(st r R , c), in Lines 24-26 of Figure 10, for such a call to Recv always returns an error due to the replay checks or AEAD decryption yielding an error; hence Recv(st r R , c) returns (a) unchanged receiving state and (b) an error output, as claimed.Having shown (b), the adversary cannot win anymore on input a non-supported ciphertext, as m r = m c = ⊥ in Line 47 of experiment Expt ROB-INT(supp dw-r[wr ] ) Ch QUIC ,A (Figure 5) in this case.Furthermore, property (a), st r R remaining unchanged on non-supported ciphertexts, implies that in any query to Recv on a supported ciphertext, leaves st r R = st c R in the two calls to Recv in Lines 40 and 44 in Figure 5. Thus, the two states are always in-sync.Due to Recv being deterministic, this implies that m r = m c always holds in Line 47, preventing A from winning.

1. 1 .
If w r + 1 < w c b , it might be that c ∈ C S [nxt − w c b , nxt − w r − 2]still lies in the overhanging part of the sliding window.But then Recv decodes a packet number pn < nxt − 1 − w r , leading to rejection (Line 25).1.2.If w cb ≤ w r + 1, we know from c / ∈ C S [nxt − w c b , nxt + w c f ] that c was never output by Send using the decoded packet number pn.This is the "forgery attempt" event, enabling B to send (N = IV ⊕ pn, AD = epn, c ) to its Forge oracle.

2 .
If cindex(c, C S [nxt − min(w c b , w r + 1), nxt + w c f ]) ∈ D R then this index has been output by supp before, and in particular the ciphertext has been processed by Recv earlier.The index corresponds to (one plus) the decoded packet number pn ∈ [pn R − w c b ..pn R + w c f ], which is unique as |epn| = log 2 (w c closer examination, the INT-CTXT reduction B in the ROB-INT proof for QUIC makes one Forge call per AEAD decryption which should output ⊥.The upper bound on the number of failed forgery attempts is precisely what QUIC (and DTLS 1.3, cf.Section 7) chose to limit in order to keep the AEAD INT-CTXT advantage for the deployed algorithms (AES-CCM, AES-GCM, small [TT21, Tho20a].Theorem 6.2 (Confidentiality of QUIC).Let Ch QUIC be the channel construction from Figure 10 from an AEAD scheme AEAD = (Enc, Dec), and support predicate supp dw-r[wr] be defined as in Section 3.2.Let A be an adversary against Ch QUIC in the IND-CPA experiment Expt IND-CPA Ch QUIC ,A from Figure 6 making q S queries to Send.There exists an adversary B (given in the proof) against the IND-CPA security of AEAD that makes q S queries to its encryption oracle Enc such that Adv IND-CPA Ch QUIC ,A ≤ Adv IND-CPA AEAD,B .Proof.From an adversary A against the IND-CPA security of Ch QUIC we construct a reduction B to the IND-CPA security of AEAD as follows.Adversary B simulates the (left-or-right) IND-CPA experiment for A faithfully, with the only exception that it does not pick a challenge bit b and AEAD encryption key itself.Instead, it uses its encryption oracle Enc (on the derived nonce and associated data, and the two left-or-right messages m 0 and m 1 ) in place of the AEAD encryption step within Send.When A eventually outputs a bit b guess, B forwards b as its own guess.Having B perfectly simulating the Expt IND-CPA Ch QUIC ,A experiment for A, inheriting the challenge bit from its own IND-CPA game, we have that Adv IND-CPA Ch QUIC ,A ≤ Adv IND-CPA AEAD,B .
Figure 12: DTLS header types: General ciphertext header (left), and examples for full (middle) and minimal (right) DTLS 1.3 ciphertext structures [RTM21, Section 4].The three leftmost bits of the first byte are set to 001 indicating that the packet is a ciphertext.Furthermore, the first byte also contains flags, indicated as C: Connection ID, S: size of sequence number, L: length, E: Epoch.If the bit in C and L are set then those parts are present.In case S is set to 0 then the ciphertext structure contains an 8-bit sequence number, otherwise 16 bits.E includes the low order two bits of the epoch.

Adv
ROB-INT(supp dw-r[wr ] )Ch DTLS ,A ≤ AdvINT-CTXT ROB-INT(supp dw-r[wr ] )Ch DTLS ,A on a ciphertext c such that supp dw-r[wr] (C S , DC R , c) = false (and hence correct receiving is skipped), we have that (a) the real receiving state st r R remains unchanged in that oracle call, and (b) the real received message is an AEAD error, i.e., m r = ⊥.Observe that for such a ciphertext call to Recv(st r R , c), i.e., executing Line 23 of Figure13, it calls the Recv oracle always resulting into a AEAD decryption error which is output in Line 24 or it returns an error due to the replay checks failing in Lines 25 and 26, respectively.This simply results in (a) outputting an unchanged receiving state st r R , and (b) an erroneous output as claimed.Having shown (b), the adversary cannot win anymore on input of a non-supported ciphertext, as m r = m c = ⊥ in Line 47 of experiment Expt ROB-INT(supp dw-r[wr ] ) Ch QUIC ,A in this case.Furthermore (a), the receiving state st r R remains unchanged on nonsupported ciphertexts which implies that in any query to Recv on a supported ciphertext, st r R = st c R in the two calls to Recv in Lines 40 and 44 in Figure 5. Due to Recv being deterministic, this implies that m r = m c always holds in Line 47, preventing A from winning.

1. 1 .
If w r + 1 < w c b , it might be that c ∈ C S [nxt − w c b , nxt − w r − 2] still lies in the overhanging part of the sliding window.However, Recv then decodes a sequence number sn < nxt − 1 − w r , leading to rejection (Line 25).1.2.If w c b ≤ w r + 1, we know from c / ∈ C S [nxt − w c b , nxt + w c f ] that c was never output by Send using the decoded sequence number sn.This is the forgery attempt, enabling B to send (N = IV ⊕sn, AD = esn, c ) to its Forge oracle.2. If cindex(c, C S [nxt − min(w c b , w r + 1), nxt + w c f ] ∈ D R then this index has been an output from supp before, and in particular the ciphertext hash been processed by Recv.The index corresponds to (one plus) the uniquely decoded sequence number sn ∈ [sn R − w c b ..sn R + w c f ] which is indeed unique since |esn| = log 2 (w c b + w c f + 1)

Theorem 7. 2 (
Confidentiality of DTLS).Let Ch DTLS be the channel construction from Figure13from an AEAD scheme AEAD = (Enc, Dec), and support predicate supp dw-r[wr] be defined as in Section 3.2.Let A be an adversary against Ch DTLS in the IND-CPA experiment Expt IND-CPA Ch DTLS ,A from Figure6making q S queries to Send.There exists an adversary B (given in the proof) against the IND-CPA security of AEAD that makes q S queries to its encryption oracle Enc such thatAdv IND-CPA Ch DTLS ,A ≤ Adv IND-CPA AEAD,B .Proof.Assume that A isan adversary attacking Ch DTLS in the IND-CPA sense.Then we construct a new adversary B, running A as a sub-routine, attacking the IND-CPA security of AEAD.
IND-CPA Ch,A for A, inheriting the challenge bit from its own IND-CPA experiment.Thus, we have that Adv IND-CPA Ch DTLS ,A ≤ Adv IND-CPA AEAD,B .
j-th entry.We write x ∈ s if s[i] = x for some i and i = index(x, s) if this i is unique, () for the empty list, s t if s prefixes t.For an m-entries list of n-entries lists t = ((t 1 The predicate supp(C S , DC R , c), on input a sequence of sent ciphertexts C S , a (combined) sequence of so-far supportedly received ciphertexts and support decisions DC R , as well as a next ciphertext c to be received, outputs a decision d ∈ D = N ∪ {true, false} whether this next ciphertext is supported, with d ).Let Ch = (Init, Send, Recv, aux) be a channel, supp a correctness support predicate, and experiment Expt