Equipped with msACCE security models, we now analyze and compare the security of TFO+TLS 1.3, UDP+QUIC, and UDP+QUIC[TLS]. The security results are summarized in Table 2 (recalled as Table 3). As mentioned in Introduction, by [27, 49] results, none of the above protocols achieves forward secrecy for 0-RTT keys or protects against 0-RTT data replays (which contribute to the first two rows in the table). We now move to the detailed analyses and start with TFO+TLS 1.3.
Table 3 Security comparison TLS 1.3 over TFO
(1) Protocol Description
Referring to msACCE protocol syntax, the TFO+TLS 1.3 2-RTT full handshake (see Fig. 2a) is a 2-stage msACCE protocol in the full mode and the TFO+TLS 1.3 0-RTT resumption handshake (see Fig. 2b) is a 3-stage msACCE protocol in the resumption mode. Note that we focus only on the main components of the handshakes and omit more advanced features such as 0.5-RTT data, client authentication, and post-handshake messages (except NewSessionTicket). In a full handshake, the initial keys are set after sending or receiving ServerHello and the final keys (i.e., session keys) are set after sending or receiving ClientFinished (but only handshake messages up to ServerFinished are used for final key generation). In a 0-RTT resumption handshake, the parties set 0-RTT keys to encrypt or decrypt 0-RTT data, after sending or receiving ClientHello.
According to the TFO and TLS 1.3 specifications [17, 60], the TFO+TLS 1.3 header contains the TCP header (see Fig. 1). We ignore some uninteresting header fields such as port numbers and the checksum because modifying them only leads to redirected or dropped packets. Such adversarial capabilities are already considered in the msACCE security models. We thus define the header space \(\mathcal {H}\) as containing the following TCP header fields: a 32-bit sequence number \({\mathtt {sqn}}\), a 32-bit acknowledgment number \({\mathtt {ack}}\), a 4-bit data offset \({\mathtt {off}}\), a 6-bit reserved field \({\mathtt {resvd}}\), a 6-bit control bits field \({\mathtt {ctrl}}\), a 16-bit window \({\mathtt {window}}\), a 16-bit urgent pointer \({\mathtt {urgp}}\), a variable-length (\(\le \) 320-bit) padded options \({\mathtt {opt}}\). For encrypted packets, \(\mathcal {H}\) additionally contains TLS 1.3 record header fields: an 8-bit type \({\mathtt {type}}\), a 16-bit version \({\mathtt {ver}}\), and a 16-bit length \({\mathtt {len}}\). We further define reset packets as those with the RST bit (i.e., the 4-th bit of \({\mathtt {ctrl}}\)) set to 1.
In “Appendix A,” we formalize TLS 1.3’s stateful AEAD scheme \(\mathsf {sAEAD}_\text {TLS}\) based on its underlying nonce-based AEAD scheme (instantiated with AES-GCM or other schemes as documented in [60]). The associated data space \(\mathcal {AD}\) contains the TLS 1.3 record header. TLS 1.3 enforces different content types for encrypted key exchange and secure channel messages. For simplicity, we define \(\mathcal {M}_{\mathsf {KE}}\) and \(\mathcal {M}_{\mathsf {SC}}\) as consisting of bit strings differing in their first bits. Note that \(\mathcal {M}_{\mathsf {pRST}}=\varnothing \).
For TFO+TLS 1.3, \(\mathsf {scfg\_gen}\) erases the server’s resumption states (if any) and refreshes the (static) key
used by the TFO cookie generation function F. If the TLS 1.3 session ticket is implemented as a self-encrypted and self-authenticated value, \(\mathsf {scfg\_gen}\) also refreshes the server’s (static) session ticket encryption key
used by an authenticated encryption scheme (e.g., AES-GCM [50]).
We refer to Fig. 6 for the remaining details of TFO, where F is instantiated with an AES-128 block cipher with output truncated to 64 bits as suggested in [17, 59]. Note that \(F_{k_{{\mathtt {ck}}}}\) takes as input a 128-bit string, so a 4-byte IPv4 address is padded with trailing 0s while a 16-byte IPv6 address is used without padding. We then refer to [26] for the detailed descriptions of TLS 1.3 handshake messages and key generations as well as [25, 60] for details about TLS 1.3’s handling of session tickets.
(2) Security Results
TFO+TLS 1.3’s session identifier \({\mathtt {sid}}_\text {TLS}\) is defined as all key exchange messages (that could be encrypted) from ClientHello to ServerFinished, excluding TCP headers and IP addresses. The msACCE-std security of TFO+TLS 1.3 is by definition independent of TCP headers and is hence provided by the TLS 1.3 component. Previous works [26, 47] only proved TLS 1.3’s authenticated key exchange security, i.e., the stage keys are authenticated and indistinguishable from random ones under reasonable computational assumptions. In “Appendix B,” we outline how their security results can be adapted to prove TLS 1.3’s Server Authentication and level-4 Channel Security in our msACCE-std model, by additionally relying on the level-4 AEAD security of \(\mathsf {sAEAD}_\text {TLS}\) (which can be reduced to security of the underlying nonce-based AEAD as shown in [21]).
The msACCE-pauth security analyses are shown as follows.
IP-Spoofing Prevention This security of TFO+TLS 1.3 is provided by the TFO component through TCP sequence number randomization and TFO cookies. By modeling the cookie generation function F as a PRF, we have the following theorem:
Theorem 1
For any efficient adversary \(\mathcal {A}\) making at most \({q_{\mathsf {T}}},{q_{\mathsf {S}}}\) queries, respectively, to \({\mathsf {NextTP}},{\mathsf {Send}}\), there exists an efficient adversary \(\mathcal {B}\) such that:
$$\begin{aligned} {\mathbf{Adv}}_{\mathrm{TFO+TLS 1.3}}^{{\mathsf {ipsp}}}({\mathcal {A}})\le (|{{\mathsf {cs}}}| +{q_{{\mathsf {T}}}}){\mathbf{Adv}}_{F}^{{\mathsf {prf}}} ({\mathcal {B}})+\frac{q_{{\mathsf {S}}}(|{\mathcal {S}}|+{q_{{\mathsf {T}}}})}{2^{|{\texttt {sqn}}|}}, \end{aligned}$$
where \(|\mathcal {S}|\) is the number of servers and \(|{\mathtt {sqn}}|\) is the bit length of a TCP sequence number.
Proof
Consider a sequence of games (i.e., experiments) and let \(\Pr _i,i\ge 0\) denote the winning probability of \(\mathcal {A}\) in Game i.
This is the original IP-Spoofing Prevention experiment, so
.
This game is identical to Game
except the challenger first guesses the target server S (and the associated time period) that accepts a spurious connection request and aborts if the guess is wrong. Since the probability of a correct guess is at least \(1/(|\mathcal {S}|+{q_{\mathsf {T}}})\), we have
.
This game replaces the PRF F used by S for TFO cookie generation with a truly random function f. By the PRF definition, it is straightforward to construct an efficient adversary \(\mathcal {B}\) such that
.
Now, in Game
, the TFO cookies generated by S are independent from each other for each client. We can bound
by considering two cases. 1) \(\mathcal {A}\) wins by sending a valid ACK packet in a full session. In this case, \(\mathcal {A}\) must have generated a valid \(ack_C\) by correctly guessing the target server’s TCP sequence number \(sqn_{S}\). The winning probability of each guess is exactly \(1/2^{|{\mathtt {sqn}}|}\). 2) \(\mathcal {A}\) wins by sending a valid SYN packet in a resumption session. In this case, \(\mathcal {A}\) must have forged a valid TFO cookie \(ck\in \{0,1\}^{64}\). The winning probability of each forgery is exactly \(1/2^{|{\mathtt {ck}}|}\) because the TFO cookie generation function is now a truly random function. By applying a union bound on the \({q_{\mathsf {S}}}\) queries and noting that \(|{\mathtt {sqn}}|=32<64=|{\mathtt {ck}}|\), we have
. \(\square \)
Remark
Note that the above second probability term is not very small since \(|{\mathtt {sqn}}|=32\). Actually, an attacker can indeed successfully establish a TCP connection using a spoofed client IP address with roughly \(2^{32}\) random guesses. However, our security bound is still acceptable because each guess made by the attacker corresponds to an “online” \({\mathsf {Send}}\) query. Here, “online” means that the attacker has to interact with the server every time it makes a guess, no matter how many resources it may consume offline. Such online attacks are easy to detect and suppress.
KE Header Integrity. TFO+TLS 1.3 does not achieve this security notion because TCP headers are never authenticated. We find a new practical attack below, where an efficient adversary \(\mathcal {A}\) can always get \(\mathbf {Adv}_\text {TFO+TLS 1.3}^{\mathsf {int\text {-}keh}}(\mathcal {A})=1\):
TFO Cookie Removal. \(\mathcal {A}\) can first make \(\pi _C^{i'}\) complete a full handshake with \(\pi _S^{j'}\) (via \({\mathsf {Connect}},{\mathsf {Send}}\) queries), then query \({\mathsf {Resume}}(\pi _C^i,S,i')\) (\(i'<i\)) to get the output packet \((\text {IP}_C,\text {IP}_S,H,pd)\), which is a SYN packet with a TFO cookie. \(\mathcal {A}\) then modifies the \({\mathtt {opt}}\) field of H to get a new \(H'\ne H\) that contains no cookie. The resulting SYN packet will be accepted by a new server oracle \(\pi _S^j\), which will then respond with a SYN-ACK packet that does not contain a TFO cookie, indicating a fallback to the standard 3-way TCP. As a result, a 1-RTT handshake is needed to complete the connection and any 0-RTT data sent with SYN would be retransmitted. This eliminates the entire benefit of TFO without being detected, resulting in reduced performance and increased handshake latency. A similar attack is possible by removing the TFO cookie in a server’s SYN-ACK packet.
Interestingly, clients are supposed to cache negative TFO responses and avoid sending TFO connections again for a lengthy period of time. This is because the most likely explanation for this behavior is that the server does not support TFO, but only standard TCP [17]. As a result, performing this attack for a single connection prevents TFO from being used with this server for a lengthy time period (i.e., days or weeks).
KE Payload Integrity TFO+TLS 1.3 is secure in this regard simply because \({\mathtt {sid}}_\text {TLS}\) consists of the payloads of all key exchange packets exchanged between the communicating parties before the client sets its session key. That is, for any client oracle that has a peer server oracle, by definition they observe the same \({\mathtt {sid}}_\text {TLS}\) and hence no key exchange packet payload can be modified, i.e., \(\mathbf {Adv}_\text {TFO+TLS 1.3}^{\mathsf {int\text {-}kep}}(\mathcal {A})=0\) for any efficient adversary \(\mathcal {A}\).
SC Header Integrity TFO+TLS 1.3 does not achieve this security notion again because of the unauthenticated TCP headers.
A efficient adversary \(\mathcal {A}\) can get \(\mathbf {Adv}_\text {TFO+TLS 1.3}^{\mathsf {int\text {-}h}}(\mathcal {A})=1\) by either modifying the TCP header of an encrypted packet (e.g., reducing the \({\mathtt {window}}\) value) or by forging a header-only packet (e.g., removing the payload of an encrypted packet and changing its \({\mathtt {ack}}\) value). Such packets are valid and will be accepted by the receiving session oracle.
The above fact exposes the adversary’s ability to arbitrarily modify or even entirely forge the information in the TCP header, which is being relied on to provide reliable delivery, in-order delivery, flow control, and congestion control for the targeted flow. This leads to a whole host of availability attacks that the networking community has been slowly uncovering via manual investigation over the last 30 years [3, 16, 31, 32, 38,39,40, 44, 45, 52, 57, 58, 63, 70]. Some of the practical attacks are describedas follows:
TCP Flow Control Manipulation. An adversary with access to the communication channel can impact TCP’s flow control mechanism to decrease the sending rate or stall the connection by modifying TCP’s \({\mathtt {window}}\) header field. This field controls the amount of received data the sender of this packet is prepared to buffer. By reducing this quantity, the throughput of the connection can be reduced and if it is set to zero the connection will completely stall.
One example of this attack would be to modify the window field to zero in a TCP packet containing a TLS-encrypted HTTP request. Since TCP headers are not authenticated, this modification will not be detected. As a result, when the server receives this request and attempts to send the response, it will believe that the client cannot currently accept any data and will delay sending the response. After some timeout, TCP will probe the client with a single packet of data to determine whether the window is still zero. If the adversary also modifies the responses to these probes, the connection will remain stalled indefinitely; otherwise, the connection will eventually recover after a lengthy delay.
TCP Acknowledgment Injection. An adversary who can observe a target connection and forge packets can inject new acknowledgment packets into the TCP connection. Acknowledgment packets have no data making them undetectable by either TLS or the application. However, they are used by congestion control to determine the allowed sending rate of a connection.
Injecting duplicate or very slowly increasing acknowledgments can be used to slow a target connection down drastically. [39] demonstrated a 12x reduction in throughput using this approach with the attacker required to expend only 40Kbps. This, of course, represents a significant performance degradation for a TFO+TLS 1.3 connection.
Injecting acknowledgments can also be used to dramatically increase the sending rate of a connection, turning it into a firehose that an attacker can point at their desired target. This is done by sending acknowledgments for data that has not been received yet, an attack known as Optimistic Ack [63]. This attack renders TCP insensitive to congestion and can completely starve competing flows. It could be used with great effect to cause denial of service against a server or the Internet infrastructure as a whole [66].
Reset Authentication TFO+TLS 1.3 is insecure in this sense because its reset packet, TCP Reset, is an unauthenticated header-only packet. This leads to a practical attack below, where an efficient adversary \(\mathcal {A}\) always gets \(\mathbf {Adv}_\text {TFO+TLS 1.3}^{\mathsf {rst\text {-}auth}}(\mathcal {A})=1\):
TCP Reset Attack. \(\mathcal {A}\) can first make two session oracles complete a handshake using \({\mathsf {Connect}},{\mathsf {Send}}\) queries, then use \({\mathsf {Pack}},{\mathsf {Deliver}}\) queries to let them exchange secure channel packets. By observing these packet headers, \(\mathcal {A}\) can easily forge a valid reset packet by setting its RST bit to 1 and the remaining header fields to reasonable values. This attack will cause TCP to tear down the connection immediately without waiting for all data to be delivered.
Note that even an off-path adversary who can only inject packets into the communication channel may be able to accomplish this attack. The injected TCP reset packet needs to be within the receive window for the client or server, but [70] demonstrated that a surprisingly small number of packets is needed to achieve this, thanks to the large receive windows typically used by implementations.
QUIC over UDP
(1) Protocol Description
Referring to msACCE protocol syntax, the UDP+QUIC 1-RTT full handshake (see Fig. 4a) is a 2-stage msACCE protocol in the full mode and the UDP+QUIC 0-RTT resumption handshake (see Fig. 4b) is a 2-stage msACCE protocol in the resumption mode. The initial keys are set after sending or receiving ClientHello, and the final keys (i.e., session keys) are set after sending or receiving ServerHello.
According to the UDP and QUIC specifications [20, 46, 55], the UDP+QUIC header contains the UDP header (see Fig. 3 ) and the QUIC header (described below). As with the TCP header, we ignore the port numbers and checksum in the UDP header. Similarly, we also ignore the UDP length field because it affects only the length of the QUIC header and payload, while the adversary is already allowed to directly modify the packet length. We thus can completely omit the UDP header and define the header space \(\mathcal {H}\) as containing the following QUIC header fields: an 8-bit public flag \({\mathtt {flag}}\), a 64-bit connection ID \({\mathtt {cid}}\), a 64-bit packet number \({\mathtt {pn}}\), and other optional fields. Note that in reality QUIC header contains only, say 32, lower bits of \({\mathtt {pn}}\), but this is enough to deduce the correct 64-bit value since the QUIC packet numbers are consecutive and start from 1. For simplicity, we consider a full 64-bit \({\mathtt {pn}}\) in the header as with the previous work [49]. We further define reset packets as those with the PUBLIC_FLAG_RESET bit (i.e., the 7-th bit of \({\mathtt {flag}}\)) set to 1. The header of a reset packet contains only \({\mathtt {flag}}\) and \({\mathtt {cid}}\).
In “Appendix A,” we formalize QUIC’s stateful AEAD scheme \(\mathsf {sAEAD}_\text {QUIC}\) based on its underlying nonce-based AEAD scheme (instantiated with AES-GCM [50]). The associated data space \(\mathcal {AD}\) contains the entire QUIC header. As with TLS 1.3, for UDP+QUIC we define \(\mathcal {M}_{\mathsf {KE}}\) and \(\mathcal {M}_{\mathsf {SC}}\) as consisting of bit strings differing in their first bits. \(\mathcal {M}_{\mathsf {pRST}}=\varnothing \).
We refer to [49] for the detailed descriptions of \(\mathsf {scfg\_gen}\) and QUIC handshake messages and key generations.
(2) Security Results
UDP+QUIC’s session identifier \({\mathtt {sid}}_\text {QUIC}\) is defined as the ClientHello payload and ServerHello, excluding IP addresses. The msACCE-std security of UDP+QUIC follows from prior works . It has been proven in [49] that QUIC is QACCE-secure in the random oracle model based on the unforgeability of the signature scheme, computational Diffie–Hellman assumption [2], and nonce-based AEAD security. Note that msACCE-std with \(\mathsf {sAEAD}_\text {QUIC}\) is semantically equivalent to QACCE with nonce-based \(\mathsf {AEAD}\) and \({\mathsf {get\_iv}}\) (defined in [49]), except that our model formalizes the advancement of time periods that was assumed by QACCE. More precisely, our model captures server-side local time periods (without time synchronization) while QACCE assumed a global time notion, but this difference does not affect the security results because QACCE essentially does not rely on time synchronization either. In other words, the same proofs in [49] can also show that QUIC is secure in the modified QACCE model that instead uses local time counters. As a result, their proofs can be easily adapted to show that UDP+QUIC achieves Server Authentication and level-1 Channel Security in our msACCE-std model. Note that one can also prove UDP+QUIC’s msACCE-std security by relying on the level-1 AEAD security of \(\mathsf {sAEAD}_\text {QUIC}\) instead of the underlying nonce-based AEAD security, where the former can be reduced to the latter as shown in “Appendix A.” Note also that UDP+QUIC only achieves level-1 Channel Security (based on the level-1 AEAD security of \(\mathsf {sAEAD}_\text {QUIC}\) ), nevertheless, as discussed in [49], QUIC implicitly prevents packet dropping and reordering by authenticating \({\mathtt {pn}}\) in the packet header. It also prevents replays with frame sequence numbers encrypted in the payload. Therefore, UDP+QUIC essentially achieves level-4 authentication as TLS 1.3 does.
The msACCE-pauth security analyses are shown as follows.
IP-Spoofing Prevention In [49], QUIC has been proven secure against IP spoofing based on the AEAD security. Their IP-spoofing security notion is the same as our IP-Spoofing Prevention notion for UDP+QUIC except that ours additionally captures attacks in full sessions. However, since source-address tokens are validated in both full and resumption sessions, their results can be trivially adapted to show that UDP+QUIC achieves IP-Spoofing Prevention.
KE Header and Payload Integrity UDP+QUIC does not achieve these security notions because its first-round key exchange messages, i.e., InchoateClientHello and ServerReject, and any invalid ClientHello are not fully authenticated. Interestingly, a variety of existing attacks on QUIC’s availability discovered in [49] are all examples of key exchange packet manipulations (e.g., the server config replay attack, connection ID manipulation attack, etc.), but these attacks cause connection failure and hence are easy to detect. However, successful attacks breaking KE Header or Payload Integrity will be harder (if not impossible) to detect.
For KE Header Integrity, we do not find any harmful attacks but theoretical attacks exist. For instance, an efficient adversary \(\mathcal {A}\) can get \(\mathbf {Adv}_\text {UDP+QUIC}^{\mathsf {int\text {-}keh}}(\mathcal {A})=1\) as follows. \(\mathcal {A}\) can first query \({\mathsf {Connect}}(\pi _C^i,S)\) to get the output packet \((\text {IP}_C,\text {IP}_S,H,pd)\), then modify the \({\mathtt {flag}}\) and \({\mathtt {pn}}\) fields of H to get a new header \(H'\ne H\) that only changes \({\mathtt {pn}}\)’s length but not its underlying value. The resulting packet will be accepted by a new server oracle \(\pi _S^j\).
This attack has no practical impact on UDP+QUIC but it successfully modifies the protocol header without being detected.
For KE Payload Integrity, we find a new practical attack described below where an efficient adversary \(\mathcal {A}\) can get \(\mathbf {Adv}_\text {UDP+QUIC}^{\mathsf {int\text {-}kep}}(\mathcal {A})\approx 1\):
ServerReject Triggering. \(\mathcal {A}\) can first let \(\pi _C^{i'}\) complete a full handshake with \(\pi _S^{j'}\) with \({\mathsf {Connect}},{\mathsf {Send}}\) queries and then query \({\mathsf {Resume}}(\pi _C^i,S,i')\) (\(i'<i\)) to get the output ClientHello packet. \(\mathcal {A}\) then modifies its payload by replacing the source-address token stk with a random value, which with high probability is invalid. Sending this modified packet to a new server oracle \(\pi _S^j\) will trigger a ServerReject packet containing a new valid \({\mathtt {stk}}\). This as a result downgrades the original 0-RTT resumption connection to a full 1-RTT connection, which causes increased latency and results in the retransmission of any 0-RTT data. Note that this attack is hard to detect because \(\pi _C^i\) may think its original \({\mathtt {stk}}'\) has expired (although this does not happen frequently).
SC Header Integrity UDP+QUIC is secure in this regard because it does not allow header-only packets to be sent in the secure channel phases and the entire protocol header is taken as the associated data authenticated by the underlying encryption scheme. Therefore, UDP+QUIC’s SC Header Integrity can be reduced to its level-1 Channel Security. Formally, for any efficient adversary \(\mathcal {A}\) there exists an efficient adversary B such that \(\mathbf {Adv}_\text {UDP+QUIC}^{\mathsf {int\text {-}h}}(\mathcal {A})\le \mathbf {Adv}_\text {UDP+QUIC}^{{\mathsf {cs}}\text {-}1}(\mathcal {B})\). This is because \(\mathcal {B}\) can simulate \(\mathcal {A}\)’s security experiment perfectly by answering the \({\mathsf {Pack}}\) queries using \({\mathsf {Encrypt}}\) with same inputs and forwarding the \({\mathsf {Deliver}}\) queries to \({\mathsf {Decrypt}}\), and if \(\mathcal {A}\) outputs (P, i) and wins then \(\mathcal {B}\) will also win by getting the secret bit \(b_P^{i}\) from \({\mathsf {Decrypt}}\).
Reset Authentication UDP+QUIC does not achieve this security notion because, similar to TCP Reset, its reset packet PublicReset is not authenticated either. In the following availability attack, an efficient adversary \(\mathcal {A}\) can always get \(\mathbf {Adv}_\text {UDP+QUIC}^{\mathsf {rst\text {-}auth}}(\mathcal {A})=1\):
PublicReset Attack. \(\mathcal {A}\) can first make two session oracles complete a handshake using \({\mathsf {Connect}},{\mathsf {Send}}\) queries, then use \({\mathsf {Pack}},{\mathsf {Deliver}}\) queries to let them exchange secure channel packets. By observing these packet headers, \(\mathcal {A}\) can easily forge a valid (plaintext) reset packet by setting its PUBLIC_FLAG_RESET bit to 1 and the remaining packet fields to reasonable values (which is easy because it simply contains the connection ID \({\mathtt {cid}}\), the sequence number of the rejected packet, and a nonce to prevent replay). This attack will cause similar effects as described in the TCP Reset attack. Note that this vulnerability is fixed in QUIC[TLS] shown below.
QUIC[TLS] over UDP
(1) Protocol Description
As mentioned in the Background, QUIC[TLS] replaces QUIC’s key exchange with the TLS 1.3 key exchange, i.e., the stage keys are set in the same way as TLS 1.3. Therefore, the UDP+QUIC[TLS] 2-RTT full handshake is a 2-stage msACCE protocol in the full mode and the UDP+QUIC[TLS] 0-RTT resumption handshake is a 3-stage msACCE protocol in the resumption mode.
The UDP+QUIC[TLS] header is similar to the UDP+QUIC header and we can likewise omit the entire UDP header for our analysis. The detailed description of the QUIC[TLS] header is omitted here and referred to [36]. A reset packet in UDP+QUIC[TLS] looks indistinguishable from a non-reset secure channel packet, but accepting it leads to a session reset.
The stateful AEAD scheme \(\mathsf {sAEAD}_\text {QUIC[TLS]}\) used by QUIC[TLS] to encrypt packets is very similar to \(\mathsf {sAEAD}_\text {QUIC}\), except that the nonce of the underlying nonce-based AEAD is computed as the exclusive OR of the secret iv (part of the key generated in \(\mathsf {sAEAD}_\text {QUIC[TLS]}\)) and the packet number. As with \(\mathsf {sAEAD}_\text {QUIC}\), the level-1 AEAD security of \(\mathsf {sAEAD}_\text {QUIC[TLS]}\) is reduced to the security of its underlying nonce-based AEAD, following a proof very similar to that of Theorem 3 in “Appendix A.” The associated data space \(\mathcal {AD}\) contains the entire QUIC[TLS] header.
Note that QUIC[TLS] applies a header protection mechanism on the encrypted packet to further hide some header fields (e.g., those related to the packet number), which provides stronger nonce-hiding security (a notion proposed by [8]). For simplicity, we do not consider this new feature and assume header protection will not weaken the security of the encrypted packet, as our analysis focuses on the packet header’s integrity rather than its confidentiality. We refer to [22] for a mechanized analysis of QUIC[TLS]’s record layer security that covers header protection.
QUIC[TLS] enforces different frame types for encrypted key exchange, secure channel, and pre-reset messages. For simplicity, we define \(\mathcal {M}_{\mathsf {KE}},\mathcal {M}_{\mathsf {SC}},\mathcal {M}_{\mathsf {pRST}}\) as consisting of bit strings differing in their first two bits. For UDP+QUIC[TLS], \(\mathsf {scfg\_gen}\) is undefined.
QUIC[TLS] also provides address validation with a secure token generated by the server, similar to the case in Google’s QUIC. We discuss QUIC[TLS]’s stateless reset mechanism later in the security analysis of Reset Authentication and refer to [36, 68] for the detailed UDP+QUIC[TLS] handshake messages and key generations.
(2) Security Results
UDP+QUIC[TLS]’s session identifier \({\mathtt {sid}}_\text {QUIC[TLS]}\) is defined as all key exchange messages (that could be encrypted) from ClientHello to ServerFinished, excluding the header fields. By construction, UDP+QUIC[TLS] inherits the msACCE-std security from TLS 1.3, but uses \(\mathsf {sAEAD}_\text {QUIC[TLS]}\) for encryption. That is, it achieves level-1 Channel Security and implicitly achieves level-4 authentication in the same way as UDP+QUIC. The IP-Spoofing Prevention of UDP+QUIC[TLS] follows a address validation scheme very similar to UDP+QUIC. In particular, if the token is generated with an authenticated encryption scheme, then the IP-Spoofing Prevention security is reduced to the encryption scheme’s authenticity security, as with UDP+QUIC. However, such an address validation scheme suffers from the same kind of availability attack against KE Payload Integrity as ServerReject Triggering for UDP+QUIC, where the adversary replaces the address-validation token with a random value to downgrade a 0-RTT resumption connection. As noted in [68], an adversary can also modify the unauthenticated ACK frames in the Initial packets without being detected. Furthermore, UDP+QUIC[TLS] achieves SC Header Integrity in the same way as UDP+QUIC. We are only left to show its security of KE Header Integrity and Reset Authentication.
KE Header Integrity UDP+QUIC[TLS] does not achieve these security notions because its first-round Initial packets (see [36]) are not authenticated. For instance, an efficient adversary \(\mathcal {A}\) can get \(\mathbf {Adv}_\text {UDP+QUIC[TLS]}^{\mathsf {int\text {-}keh}}(\mathcal {A})=1\) as follows. \(\mathcal {A}\) first queries \({\mathsf {Connect}}(\pi _C^i,S)\) to get \(\pi _C^i\)’s Initial packet \((\text {IP}_C,\text {IP}_S,H,pd)\). Then, as described in [68], \(\mathcal {A}\) can decrypt this packet with its destination connection ID cid in H, change it to another value \(cid'\), and re-encrypt the whole packet with this new \(cid'\). The resulting packet \((\text {IP}_C,\text {IP}_S,H',pd')\), where \(H\ne H'\), is valid and will be accepted by a new server oracle \(\pi _S^j\) without being detected by the client. However, this is only a theoretical attack with no practical impact.
Reset Authentication In UDP+QUIC[TLS], the stateless reset works as follows. One party generates a 128-bit reset token using its static key and a random 64-bit QUIC connection ID as input. Then, this token (carried within the pre-reset message) is sent to the other party in a secure channel phase. Later, the same party that generated this token can perform a stateless reset by regenerating the token and sending it to the other party in clear (via a reset packet).
The Reset Authentication security of UDP+QUIC[TLS] can be reduced to its level-1 Channel Security and the PRF security of the reset token generation function F (which can be instantiated with an HMAC [6] for instance), as shown in the following theorem:
Theorem 2
For any efficient adversary \(\mathcal {A}\) making at most \({q_{\mathsf {D}}}\) \({\mathsf {Deliver}}\) queries, there exist efficient adversaries \(\mathcal {B}\) and \(\mathcal {C}\) such that:
$$\begin{aligned} {\mathbf{Adv}}_{\mathrm{UDP+QUIC[TLS]}}^{{\mathsf {rst}}\text {-}{\mathsf {auth}}}({\mathcal {A}})\le & {} | {\mathcal {P}}|{\mathbf{Adv}}_{F}^{{\mathsf {prf}}}({\mathcal {B}})+|{\mathcal {P}}|{\mathbf{Adv}} _{\mathrm{UDP+QUIC[TLS]}}^{{{\mathsf {cs}}\text {-}1}}({\mathcal {C}})+\frac{|{\mathcal {P}}|{q_{\mathsf {D}}}}{2^{|{\texttt {rtk}}|}}\\&+\frac{|{\mathcal {P}}|N^2}{2^{|{\texttt {cid}}|}}, \end{aligned}$$
where \(|\mathcal {P}|\) is the number of parties, N is the maximum number of sessions for each party, \(|{\mathtt {rtk}}|\) is the bit length of a reset token, and \(|{\mathtt {cid}}|\) is the bit length of a connection ID.
Proof
Consider a sequence of games (i.e., experiments) and let \(\Pr _i,i\ge 0\) denote the winning probability of \(\mathcal {A}\) in Game i.
This is the original Reset Authentication experiment, so
.
This game is the same as Game
except it aborts if the connection IDs repeat for a party. Since the probability of such a collision for each party is at most \(N^2/2^{|{\mathtt {cid}}|}\), by a union bound we have
.
The challenger proceeds as before except it first guesses the target party P (recall that \(\mathcal {A}\) outputs (P, i) in the end) and aborts if the guess is wrong. Since the probability of a correct guess is at least \(1/|\mathcal {P}|\), we have
.
This game replaces the PRF F used by P for reset token generation with a truly random function f. By the PRF definition, it is straightforward to construct an efficient adversary \(\mathcal {B}\) such that
.
This game replaces the pre-reset packet (if any) output by the target session oracle \(\pi _P^i\) (i.e., output by \({\mathsf {Pack}}(\pi _P^i,\cdot ,{\mathtt {prst}})\)) with encryption of an arbitrarily fixed pre-reset message \(m^*_{\mathsf {prst}}\in \mathcal {M}_{\mathsf {pRST}}\). As illustrated below, there exists an efficient adversary \(\mathcal {C}\) against the level-1 Channel Security of UDP+QUIC[TLS] such that
.
\(\mathcal {C}\) samples the static reset token generation keys for all parties and simulate \({\mathsf {Pack}}\) and \({\mathsf {Deliver}}\) queries with its \({\mathsf {Encrypt}}\) and \({\mathsf {Decrypt}}\) queries. In particular, for a \({\mathsf {Pack}}(\cdot ,\cdot ,{\mathtt {prst}})\) query made to a session oracle of some party other than the target party P, \(\mathcal {C}\) generates the reset token with \(F_k(cid)=rtk\) (where k is the token generation key of the specified party and cid is the connection ID used by the specified session oracle) and forms the pre-reset message \(m_{\mathsf {prst}}\) that carries that token \(F_k(cid)\), then queries \({\mathsf {Encrypt}}\) with \((m_{\mathsf {prst}},m_{\mathsf {prst}})\) as the challenge message pair and uses the output ciphertext to form a pre-reset packet sent to \(\mathcal {A}\). For a \({\mathsf {Pack}}(\cdot ,\cdot ,{\mathtt {prst}})\) query made to a session oracle of the target party P but not the target session i, the token is instead generated with
via lazy sampling and the rest is the same. For a \({\mathsf {Pack}}(\pi _P^i,\cdot ,{\mathtt {prst}})\) query (i.e., to the target session oracle), \(\mathcal {C}\) generates a random reset token f(cid) (if f(cid) is not yet set) and forms a pre-reset message \(m_{\mathsf {prst}}\) that carries that token f(cid), then queries \({\mathsf {Encrypt}}\) with \((m_{\mathsf {prst}},m^*_{\mathsf {prst}})\) as the challenge message pair and uses the output ciphertext to form a pre-reset packet sent to \(\mathcal {A}\). The \({\mathsf {Pack}}(\cdot ,\cdot ,{\mathtt {rst}})\) queries can be simulated in a similar way, except that no \({\mathsf {Encrypt}}\) query is needed and the reset token is used to form a reset packet sent to \(\mathcal {A}\). When receiving a reset packet via a \({\mathsf {Deliver}}\) query, \(\mathcal {C}\) checks if the reset token carried in this packet matches the previously received reset token carried in the pre-reset packet and then accepts it if and only if the check passes. It is not hard to see that \(\mathcal {C}\) can perfectly simulate Game
in the left world (\(b_P^i=0\)) or Game
in the right world (\(b_P^i=1\)). \(\mathcal {C}\) outputs 1 if and only if \(\mathcal {A}\) wins.
Now, in Game
, the random pre-reset message of the target \(\pi _P^i\) is independent from \(\mathcal {A}\)’s view and each guess is correct with probability \(1/2^{|{\mathtt {rtk}}|}\). By a union bound, we have
. \(\square \)
Remark
Recall that \(|{\mathtt {rtk}}|=128\) and \(|{\mathtt {cid}}|=64\). Similar to the remark following Theorem 1, regarding the last probability term, any attacker has to observe roughly \(2^{32}\) online sessions in order to find a connection ID collision. To forge (basically replay) a valid reset packet, the attacker has to make roughly \(2^{32}\) online \({\mathsf {Pack}}(\cdot , \cdot , {\mathtt {rst}})\) queries to the target party to keep record of the reset packets for those observed sessions since each session is typically alive for a short time; this is an online attack that is easy to detect and suppress. Note that in theory if the target party can open \(2^{32}\) concurrent sessions, then the attacker only needs to make a single online query; however, in practice this is very unlikely since there are only \(2^{16}-1\) TCP sockets per IP address. Note also that the attacker does not get to choose which session to be maliciously reset since a collision can occur at any time.