Secure Communication Channel Establishment: TLS 1.3 (over TCP Fast Open) vs. QUIC

Abstract

Secure channel establishment protocols such as TLS are some of the most important cryptographic protocols, enabling the encryption of Internet traffic. Reducing the latency (the number of interactions between parties) in such protocols has become an important design goal to improve user experience. The most important protocols addressing this goal are TLS 1.3 over TCP Fast Open (TFO), Google’s QUIC over UDP, and QUIC[TLS] (a new design for QUIC that uses TLS 1.3 key exchange) over UDP. There have been a number of formal security analyses for TLS 1.3 and QUIC, but their security, when layered with their underlying transport protocols, cannot be easily compared. Our work is the first to thoroughly compare the security and availability properties of these protocols. Towards this goal, we develop novel security models that permit “layered” security analysis. In addition to the standard goals of server authentication and data privacy and integrity, we consider the goals of IP spoofing prevention, key exchange packet integrity, secure channel header integrity, and reset authentication, which capture a range of practical threats not usually taken into account by existing security models that focus mainly on the crypto cores of the protocols. Equipped with our new models we provide a detailed comparison of the above three protocols. We hope that our results will help protocol designers in their future protocol analyses and practitioners to better understand the advantages and limitations of novel secure channel establishment protocols.

A TFO+TLS 1.3 and UDP+QUIC Protocol Definitions

1.1 A.1 TFO+TLS 1.3 Protocol Definition

Referring to the msACCE protocol syntax, a TFO+TLS 1.3 2-RTT full handshake (see Fig. 1) is a 2-stage msACCE protocol in the full mode and a 0-RTT resumption handshake (see Fig. 1) 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 [10, 43], the TFO+TLS 1.3 header contains the TCP header [39]. 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 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 the 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. Note that $\mathsf {scfg\_gen}$ is undefined.

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. $\mathcal {M}_{\mathsf {pRST}}=\varnothing$. We refer to the full version [9] for the remaining TFO details and to [6, 18] for the detailed descriptions of TLS 1.3 handshake messages and key generations in earlier TLS 1.3 drafts as well as [43] for the latest updates.

1.2 A.2 UDP+QUIC Protocol Definition

Referring to the msACCE protocol syntax, an UDP+QUIC 1-RTT full handshake (see Fig. 2) is a 2-stage msACCE protocol in the full mode and a 0-RTT resumption handshake (see Fig. 2) 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 [32, 38, 45], the UDP+QUIC header contains the UDP header [38] 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 only affects the length of the QUIC header and payload. We thus can completely omit the UDP header and define the header space $\mathcal {H}$ as containing the following fields: an 8-bit public flag ${\mathtt {flag}}$, a 64-bit connection ID ${\mathtt {cid}}$, a variable-length (${\le }$48-bit) sequence number ${\mathtt {sqn}}$, and other optional fields. 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. A reset packet header only contains ${\mathtt {flag}}$ and ${\mathtt {cid}}$.

As with TLS 1.3, 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 [35] for the detailed descriptions of $\mathsf {scfg\_gen}$ and QUIC handshake messages and key generations.