QUIC (Quick UDP Internet Connections) is an internet transport protocol that is encrypted by default, designed to provide secure, fast HTTP transport as a replacement for TCP and TLS. Google QUIC’s default encryption protocol is its own QUIC Crypto.

The fundamental difference between QUIC and TCP lies in the design principle of providing secure transport by default. The original QUIC combined TCP’s three-way handshake with the TLS 1.3 handshake, replacing TLS’s record-layer data frame format with QUIC’s own while retaining TLS handshake messages. This approach ensures connections are always authenticated and encrypted while making initial connection establishment faster. TCP and TLS 1.3 require two round trips to complete the handshake, whereas the QUIC handshake requires only one. If the client has cached the server’s configuration information, no handshake is needed at all.

Negotiation cost comparison

QUIC

The QUIC server has a server config parameter list signed with a private key, containing regular parameters, DH public keys, validity period, and other information. Since this data is static, a single signature can be used for a long time without needing to sign on every connection establishment.

Channel key negotiation uses Diffie-Hellman. The server parameters required by the DH algorithm are in the server config, and client parameters are sent to the server in the first handshake message. The static server config designed to enable 0-RTT handshakes also introduces a forward secrecy problem for encrypted connections. As long as the server still holds the server config, if the key is compromised, all data previously encrypted with that key can be decrypted.

Therefore QUIC provides two levels of encryption: initial data from the client is encrypted using the DH value in the server config, which can be persisted for several days. After receiving the client’s connection, the server immediately replies with an ephemeral DH value and re-encrypts the connection.

Although at first glance this approach does not achieve the same level of forward secrecy as TLS 1.3, in practice, TLS deployments at scale often enable SessionTickets to reduce network round trips, and SessionTickets is also persisted and can be used to decrypt connections. server config and SessionTickets are roughly on par. Comparatively, QUIC provides an ephemeral key for actual communication, which is slightly stronger than the TLS approach.

The security difference between using one ephemeral key per connection and sharing one ephemeral key across all connections is negligible, and the complexity reduction from sacrificing that small difference is substantial. So it is reasonable to reuse the server’s DH key across all connections within a short time span.

TLS1.3

The TLS 1.3 handshake does three main things: key exchange, obtaining server parameters, and authentication.

Key exchange: this phase shares the materials needed to generate keys, such as the computation method or named group (ECDHE or DHE), and selects cipher parameters, such as symmetric encryption options.
Server parameters: this phase confirms other handshake parameters, such as whether certificate-based client authentication is required.
Authentication: this phase authenticates the server, optionally authenticates the client, and verifies the keys as well as the integrity of the handshake messages.

TLS has two handshake types: non-forward-secret and forward-secret. Their handshake efficiency compared with QUIC is roughly:

For a non-forward-secret handshake, the client does one public-key encryption at about 34us, and the server does one private-key decryption at about 1100us;
For a forward-secret handshake, the client does one public-key encryption, one DH operation, and one PRF operation, taking about 230us; the server does one private-key decryption, one DH operation, and one PRF operation, taking about 1300us;
A QUIC client does one DH operation, two PRF operations, and one public-key encryption, taking about 184us; the server does two PRF operations, taking about 100us;

The cost difference between QUIC and TLS in the negotiation phase comes mainly from asymmetric encryption and decryption. This does not include operations like certificate chain verification, since both protocols have that. It also assumes both protocols use cipher algorithms and options at the same or equivalent performance level, for example both use SHA-256 for digests and Curve25519 for the DH curve. If QUIC used ECDH P-256 while TLS used Curve25519, the results would be different.

TLS also has a session resumption mechanism, while QUIC requires the client and server to each maintain a cache of DH results. Although this is not supported at the protocol level, trading that convenience for roughly a 5x efficiency gain is still worthwhile.

QUIC handshake

QUIC’s negotiation process can be summarized in three points:

server config is a parameter set containing the server’s ephemeral key and is updated roughly every few days;
The initial client hello when establishing a connection for the first time is actually an empty message, whose purpose is to get from the server a REJ(ect) message containing the latest server config. Once obtained, the client sends a formal client hello again;
Server hello is an encrypted message containing the ephemeral key;

First connection

To achieve a 0-RTT handshake, the client needs to obtain server config, so the first connection costs 1-RTT.

When the client establishes a connection for the first time, before the handshake succeeds, it first sends an incomplete hello message to get the server configuration and its authenticity proof. To avoid sending large authenticity proofs to arbitrary unverified endpoints, the server needs to verify the client’s identity. This may involve multiple round trips, but these are one-time costs.

The client’s hello message contains key-value pairs such as the server domain, source address token, acceptable authentication types, common certificate sets, cached certificates, and so on (some are optional). It is mainly used to establish identity. After receiving the client’s hello message, the server returns either a rejection message or a server hello. A hello indicates a successful handshake, while a rejection message carries information for the client to use in its next handshake attempt.

For example, if the client does not include a source address token and the server does not want to send a server config to an unauthenticated IP source, the server includes a source address token in the rejection message so that the client’s next handshake can pass validation.

server config describes a set of server parameters through key-value pairs, including the server config ID, key exchange algorithm, authenticated encryption algorithm, public key list, validity period, and version. After receiving it, the client authenticates it through the certificate chain and signature, then sends a complete handshake message. In addition to the fields in the earlier incomplete message, the complete message includes the chosen server config ID, authenticated encryption and key exchange algorithms, client and server nonces, and public key.

After the client sends the complete hello message, both parties share a non-forward-secure key, also called the initial key, and the client can begin sending application data.

Non-first connection

After the first connection, the client stores server config and on subsequent connections can send application data directly, achieving 0-RTT.

TLS 1.3 state machine

The TLS 1.3 handshake is significantly simpler than TLS 1.2 and mainly supports three modes:

sequenceDiagram
    participant Client
    participant Server

    rect rgb(240, 248, 255)
        Note over Client,Server: 1-RTT handshake (standard mode)
        Client->>Server: ClientHello (Key Share)
        Server->>Server: Generate server Key Share
        Server-->>Client: ServerHello + Key Share + Certificate + Finished
        Client->>Server: Verify certificate + Finished
        Note over Client,Server: Handshake complete, encrypted transport begins
    end

    rect rgb(255, 250, 240)
        Note over Client,Server: 0-RTT handshake (resumption mode)
        Client->>Server: ClientHello (Key Share + Early Data)
        Server-->>Client: ServerHello + Key Share + Finished
        Note over Client,Server: 0-RTT data can be sent immediately
    end

    rect rgb(240, 255, 240)
        Note over Client,Server: PSK session resumption
        Client->>Server: ClientHello (PSK Identity)
        Server-->>Client: ServerHello + Finished
        Note over Client,Server: No full key exchange required
    end

TLS 1.3 vs TLS 1.2 handshake comparison

Feature	TLS 1.2	TLS 1.3
Handshake round trips	2-RTT	1-RTT / 0-RTT
Cipher suites	Multiple options	Reduced to 5 suites
Forward secrecy	Optional	Enabled by default
Compression	Supported	Disabled
Custom algorithms	Supported	Disabled

A quick look at the handshake state diagram shows that TLS is far more complex than QUIC. TLS is a relatively reliable, mature protocol, but due to many version iterations and a large amount of legacy baggage, its architecture, interfaces, and use cases are extremely complex. Without compatibility concerns and historical constraints, a more elegant “TLS” could have been designed.

Key derivation

QUIC key material is generated using the HMAC-SHA256 key derivation function (HKDF). HKDF uses an extract-then-expand design: it first converts the input into a fixed-length pseudorandom value, then expands it into several pseudorandom keys. In QUIC’s implementation, the DH key produced during key agreement serves as the input to HKDF.

HKDF-Extract

Using the raw key material, a cryptographically strong pseudorandom key is derived. HKDF-Extract takes the client and server nonces plus the key agreement output (pre-master key) as input, and outputs a pseudorandom key that serves as the master key, 32 bytes in length (assuming SHA-256 is used as the digest algorithm).

HKDF-Expand

The pseudorandom key extracted by HKDF-Expand is then expanded to a key of the desired length (while preserving randomness). The pre-master key generated by HKDF-Extract and the following information are used as input to generate the forward-secret key:

QUIC key expansion
Connection GUID
client hello message
server config
DER-encoded certificate

In summary, the client hello message obtains the server config and generates a DH key, which serves as input to HKDF-Extract to produce the pre-master key, which is then expanded via HKDF-Expand into the forward-secret key, the key actually used to encrypt application data.

CETV Tag

Unlike TLS, which transmits the client certificate in plaintext, QUIC’s client hello includes a CETV flag that marks the client certificate, channel ID, and other non-public data in the hello message. CETV is protected with AEAD encryption, and the key is generated in a manner similar to the forward-secret key. Since the client hello is sent only once, the nonce used for AEAD encryption can be 0.

Certificate Compression

TLS certificate chains are transmitted at their original file size, making up the bulk of the handshake. To simplify the exchange, QUIC compresses certificates before sending them, does not transmit the CA root certificate, and instead includes a digest of the locally cached certificate in the exchange to confirm whether both parties share the same certificate chain.

References

QUIC Crypto

QUIC Protocol Deep Dive: Handling Initial Packets

The Transport Layer Security (TLS) Protocol Version 1.3 draft-ietf-tls-tls13-28

QUIC: A UDP-Based Multiplexed and Secure Transport draft-ietf-quic-transport-27

QUIC Crypto and simple state machines

The Illustrated TLS 1.3 Connection