Quic Protocol - Learning Module

Loading content...

0/228

0-RTT Connection

The Quest for Zero Latency

Every round trip matters. On a mobile network with 100ms latency, a traditional HTTPS connection requires 200-300ms just for TCP and TLS handshakes—before any application data flows. For a user clicking a link, this represents perceptible delay. For an application making many API calls, it accumulates into seconds of wasted time.

0-RTT (Zero Round Trip Time) is QUIC's answer to this latency tax. When a client reconnects to a server it has visited before, 0-RTT allows the client to send encrypted application data in its very first packet. The server can respond with data before the handshake completes. From the client's perspective, the connection is instantaneous.

This isn't magic—it's the culmination of careful cryptographic design inherited from TLS 1.3 and integrated deeply into QUIC's architecture.

What You Will Learn

By the end of this page, you will understand how 0-RTT builds on TLS 1.3 session resumption, the cryptographic mechanisms that enable sending encrypted data in the first packet, the security tradeoffs of 0-RTT (particularly replay attacks), how servers protect against 0-RTT replay, and when 0-RTT should and shouldn't be used.

Understanding Round-Trip Latency

Before diving into 0-RTT, let's quantify the latency problem QUIC solves.

Traditional TCP+TLS Connection:

A new HTTPS connection requires multiple round trips:

TCP Handshake — SYN → SYN-ACK → ACK: 1 RTT
TLS 1.3 Handshake — ClientHello → ServerHello...Finished: 1 RTT
First HTTP Request — Request → Response: 1 RTT

Total: 3 RTT before first byte of response

For TLS 1.2, the handshake is 2 RTT, making the total 4 RTT.

Latency Impact of Round Trips
RTT Latency	TCP+TLS 1.3 (3 RTT)	TCP+TLS 1.2 (4 RTT)	QUIC 1-RTT	QUIC 0-RTT
20ms (datacenter)	60ms	80ms	20ms	0ms*
50ms (good mobile)	150ms	200ms	50ms	0ms*
100ms (typical mobile)	300ms	400ms	100ms	0ms*
300ms (satellite/remote)	900ms	1200ms	300ms	0ms*

*0-RTT latency is "0ms" in the sense that no round trips are required before application data is sent. The actual latency is approximately the one-way propagation time; the response arrives after 1 RTT from the client's perspective, but the request-response cycle begins immediately.

QUIC's Improvement:

New connection (1-RTT): QUIC combines transport and crypto handshake into a single round trip. Client sends ClientHello with transport parameters; server responds with complete handshake and can include response data. 1 RTT to first response data.
Resumption (0-RTT): Client sends ClientHello AND application data encrypted with previously established keys. Server can process the request immediately and send response before handshake completes. 0 RTT to first request transmission; 1 RTT to first response.

The 0-RTT Mindset Shift

Think of 0-RTT not as eliminating all latency, but as eliminating added latency. With 0-RTT, reconnecting to a server costs no more than sending a single UDP packet. The only latency is the inherent network propagation time—the absolute physical minimum.

TLS 1.3 Session Resumption Foundation

QUIC's 0-RTT builds directly on TLS 1.3's session resumption mechanism. Understanding TLS 1.3 resumption is essential for understanding QUIC 0-RTT.

Pre-Shared Keys (PSK):

After a successful TLS 1.3 handshake, the server can send the client a NewSessionTicket message containing a Pre-Shared Key (PSK). This PSK is derived from the connection's master secret and can be used to resume the session later.

The PSK is essentially a "remember me" token:

Server encrypts session state (or a lookup key) into the ticket
Client stores the ticket locally
On reconnection, client presents the ticket
Server recovers session state and derives keys without full handshake

TLS 1.3 Session Ticket Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
TLS 1.3 Session Ticket Flow:
============================
 
Initial Connection:
-------------------
Client                              Server
   |                                   |
   |------- ClientHello ------------->|
   |<------ ServerHello --------------|
   |<------ EncryptedExtensions ------|
   |<------ Certificate ---------------|
   |<------ CertificateVerify ---------|
   |<------ Finished ------------------|  
   |------- Finished ----------------->|
   |                                   |
   |<=== Application Data Flows =====>|
   |                                   |
   |<------ NewSessionTicket ----------|  (Server issues PSK ticket)
   |<------ NewSessionTicket ----------|  (May issue multiple)
   |                                   |
 
Ticket contents (encrypted by server):
{
  "session_id": "uuid...",
  "creation_time": 1705312800,
  "expiry_time": 1705399200,      # Valid for 24 hours (configurable)
  "resumption_master_secret": "...",  # Key derivation material
  "sni": "example.com",           # Server Name Indication
  "alpn": "h3",                   # Application Protocol
  "max_early_data_size": 16384    # How much 0-RTT data allowed
}
 
Client stores:
- Ticket blob (opaque)
- Associated server identity
- Max early data size
- Creation timestamp

Converting Mermaid diagram...

Ticket Encryption is Server-Controlled

The session ticket is encrypted with a key only the server knows. The client cannot read or modify it—it's opaque. This means the server controls what state it stores and how long tickets remain valid. Servers can issue tickets that are self-contained (all state encrypted in ticket) or that reference server-side state (ticket contains only a lookup key).

QUIC 0-RTT Mechanism

QUIC integrates TLS 1.3's 0-RTT into its packet structure, allowing early data to be sent in the very first UDP datagram. Let's trace through the complete 0-RTT handshake.

Client's First Packet:

When a client with a valid session ticket connects:

Initial Packet (Long Header, Initial encryption)
- CRYPTO frame with ClientHello
- ClientHello includes PSK identity (ticket reference)
- ClientHello includes early_data extension
0-RTT Packet (Long Header, 0-RTT encryption)
- STREAM frames with application data
- Encrypted with PSK-derived 0-RTT keys
- Can include multiple streams of early data

These packets are coalesced into a single UDP datagram, sending both handshake initiation and application data atomically.

QUIC 0-RTT Packet Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
QUIC 0-RTT Connection: First UDP Datagram
==========================================
 
UDP Datagram (coalesced packets):
┌─────────────────────────────────────────────────────────────┐
│                     Initial Packet                          │
│  Long Header: Type=Initial, Version, DCID, SCID, Token      │
│  Payload (Initial Keys):                                    │
│    CRYPTO Frame: ClientHello                                │
│      - Supported versions                                   │
│      - Cipher suites                                        │
│      - PSK identity (session ticket)                        │
│      - early_data extension (requesting 0-RTT)              │
│      - Key share (for 1-RTT keys)                           │
│    PADDING Frame: (to reach 1200 byte minimum)              │
├─────────────────────────────────────────────────────────────┤
│                     0-RTT Packet                            │
│  Long Header: Type=0-RTT, Version, DCID, SCID               │
│  Payload (0-RTT Keys, derived from PSK):                    │
│    STREAM Frame: Stream 0, HTTP/3 request                   │
│      "GET /api/user/profile HTTP/3..."                      │
│    STREAM Frame: Stream 4, another request                  │
│      "GET /api/notifications HTTP/3..."                     │
└─────────────────────────────────────────────────────────────┘
 
0-RTT Key Derivation:
  PSK               →  HKDF-Extract  →  Early Secret
  Early Secret      →  Derive-Secret →  client_early_traffic_secret
  client_early_traffic_secret  →  HKDF-Expand  →  0-RTT Key + IV
 
Note: 0-RTT data is encrypted, but the encryption comes from
the PSK (known from previous connection), not from this handshake.
This is what makes the "0 round trips" possible—and also what
creates the replay vulnerability.

Server's Response:

The server, upon receiving the coalesced datagram:

Decrypts Initial packet using Initial keys (derived from DCID)
Processes ClientHello, validates PSK, extracts early_data extension
Decrypts 0-RTT packet using PSK-derived 0-RTT keys
Processes application requests immediately (before handshake completes)
Sends response containing:
- ServerHello + handshake completion
- Response data encrypted with 1-RTT keys

The client receives the response in approximately 1 RTT, with the request having been processed at the server immediately upon receipt—no waiting for handshake completion.

0-RTT is Unidirectional

Only the client can send 0-RTT data. The server cannot send 0-RTT data to the client because the server doesn't have a PSK for the client (the relationship isn't symmetric). Server responses use 1-RTT keys, which are established during the handshake. This asymmetry reflects the typical client-initiated request pattern.

The Replay Attack Problem

0-RTT's latency advantage comes with a fundamental security limitation: replay attacks. Understanding this tradeoff is essential for safe 0-RTT usage.

The Replay Vulnerability:

In a full handshake, both parties contribute fresh randomness that's mixed into the key derivation. An attacker can't replay an old connection—the new random values would produce different keys, and the replayed data wouldn't decrypt.

0-RTT data, however, is encrypted using keys derived entirely from the PSK (which doesn't change between connections). An attacker who captures a 0-RTT packet can replay it later:

Attacker captures client→server Initial+0-RTT packet
Attacker sends identical packet to server (hours/days later)
Server accepts PSK, decrypts 0-RTT, processes request
If request has side effects (purchase, transfer), they execute again

0-RTT Replay Attack Scenario
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
0-RTT Replay Attack Example:
=============================
 
Original client request:
Client → Server:
  Initial + 0-RTT Packet
  0-RTT Data: POST /api/transfer
             {"from": "alice", "to": "bob", "amount": 100}
 
Server processes: Transfers $100 from Alice to Bob
Server → Client: 200 OK, transfer complete
 
Attacker captures the encrypted packet...
 
Later replay by attacker:
Attacker → Server:
  [Exact copy of captured packet]
  0-RTT Data: (same encrypted bytes)
             POST /api/transfer ...
 
If server has no replay protection:
  Server processes: Transfers another $100 from Alice to Bob!
  Server → ???: 200 OK, transfer complete
  (Response goes to attacker's IP, but damage is done)
 
Key insight:
- Attacker doesn't need to decrypt the 0-RTT data
- Attacker doesn't need the PSK
- Attacker only needs to capture and resend the packet
- The encrypted data is the same, so it decrypts the same way

Replay is Cryptographically Unavoidable

This is not a bug or oversight—it's a fundamental tradeoff. To send encrypted data in zero round trips, the encryption must use pre-existing keys (the PSK). Pre-existing keys can be used by replayers. There is no cryptographic trick that provides 0-RTT encryption without replay vulnerability. The solution must be at the application layer.

Why 1-RTT Data Isn't Replayable:

For comparison, 1-RTT data (the normal case after handshake) uses keys derived from:

PSK (if resuming) or certificate exchange (if new)
Client's random value in ClientHello
Server's random value in ServerHello
Ephemeral key exchange (ECDHE)

Because each handshake includes fresh random values and a new key exchange, the 1-RTT keys are unique to each connection. Replaying a captured packet from a previous connection would fail—the keys don't match.

Replay Protection Strategies

Since replay protection can't be achieved cryptographically for 0-RTT, it must be achieved through other means. TLS 1.3 and QUIC define several strategies, each with tradeoffs.

Strategy 1: Single-Use Tickets

Each session ticket is valid only once. The server tracks used tickets and rejects duplicates.

✅ Prevents replay: Second use of ticket fails
❌ Requires server-side state (ticket database)
❌ Distributed systems need synchronized state
❌ Legitimate retransmissions might fail

Server-Side Replay Protection Mechanisms

•Single-Use Tickets — Mark tickets as used in a distributed cache (Redis, Memcached). Reject tickets seen before. Simple but requires state synchronization across server instances.
•Ticket Age Validation — Tickets include creation timestamp. Server rejects 0-RTT if observed ticket age doesn't match expected (client-reported) age within tolerance. Detects delayed replays.
•Strike Register (Google) — Bloom filter-like structure tracking recently-seen client_random values. Rejects duplicates within a time window. Probabilistic but low-overhead.
•Unique Token Binding — Ticket bound to specific client identifier (IP, client certificate). Replay from different source fails validation. Provides partial protection.
•Time-Limited Tickets — Short ticket lifetime (minutes to hours). Replay window limited to ticket validity period. Defense in depth with other mechanisms.

Strategy 2: Application-Layer Idempotency

The most robust approach: design APIs so that repeating a request has no additional effect. This pushes replay protection to where it can be done correctly—the application.

Idempotent operations (safe for 0-RTT):

GET /api/user/profile — Reading data multiple times is harmless
PUT /api/user/settings — Setting to same value is equivalent to setting once
DELETE /api/session/{id} — Deleting already-deleted is no-op

Non-idempotent operations (avoid in 0-RTT):

POST /api/order — Creates new order each time
POST /api/transfer — Moves money each time
POST /api/message/send — Sends duplicate message

For non-idempotent operations, applications can add idempotency keys:

POST /api/transfer
Idempotency-Key: 7f3d9a2e-...
{"from": "alice", "to": "bob", "amount": 100}

Server stores completed idempotency keys and returns cached response on replay.

QUIC Cannot Enforce Idempotence

QUIC has no visibility into application semantics. It cannot distinguish a GET from a POST, or a read from a write. The responsibility for 0-RTT safety lies with the application layer. Applications MUST NOT send non-idempotent operations as 0-RTT data unless they implement their own replay protection.

0-RTT Rejection and Fallback

Servers can reject 0-RTT data, and clients must handle this gracefully. Rejection can occur for various reasons:

Reasons for 0-RTT Rejection:

0-RTT Rejection Scenarios
Rejection Reason	Server Behavior	Client Recovery
Ticket expired	Ignore 0-RTT, proceed with 1-RTT handshake	Receive new ticket, retry as 1-RTT
Ticket decryption failed	Ignore 0-RTT, proceed with full handshake	Fallback to full handshake
Replay detected	Ignore 0-RTT, may continue handshake	Retry without 0-RTT; investigate if intentional
Server config changed	Incompatible ALPN/params, reject 0-RTT	Receive new config, retry with 1-RTT
0-RTT disabled	Server policy doesn't allow 0-RTT	Always use 1-RTT for this server
Anti-replay window expired	Too old for strike register	Retry with 1-RTT, get fresh ticket

0-RTT Rejection and Fallback Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
0-RTT Rejection Flow:
=====================
 
Client sends:
┌─────────────────────────────────────┐
│ Initial Packet                      │
│   CRYPTO: ClientHello with PSK      │
├─────────────────────────────────────┤
│ 0-RTT Packet                        │
│   STREAM: GET /api/data             │
└─────────────────────────────────────┘
 
Server decides to reject 0-RTT (ticket expired):
 
Server sends:
┌─────────────────────────────────────┐
│ Initial Packet                      │
│   CRYPTO: ServerHello               │
│     - NO early_data extension       │  ← 0-RTT rejected
│     - Continue with 1-RTT handshake │
├─────────────────────────────────────┤
│ Handshake Packet                    │
│   CRYPTO: Encrypted Extensions      │
│   CRYPTO: Finished                  │
├─────────────────────────────────────┤
│ (No 1-RTT response data yet)        │
└─────────────────────────────────────┘
 
Client detects rejection:
  - ServerHello lacks early_data extension
  - 0-RTT data was NOT processed
  - Client MUST retransmit request as 1-RTT
 
Client retransmits:
┌─────────────────────────────────────┐
│ 1-RTT Packet                        │
│   STREAM: GET /api/data             │  ← Same request, now 1-RTT
│   CRYPTO: Finished                  │
└─────────────────────────────────────┘
 
Server processes 1-RTT request normally.
 
Total cost: 1 RTT extra (same as if 0-RTT never attempted)
Client has new valid ticket for future 0-RTT attempts.

0-RTT Rejection is Not Failure

0-RTT rejection is a normal part of the protocol, not an error. Clients should always be prepared for rejection and fall back gracefully. The connection still succeeds—just with 1-RTT latency instead of 0-RTT. Applications shouldn't assume 0-RTT will succeed.

0-RTT Implementation Considerations

Implementing 0-RTT correctly requires careful attention to several protocol and security details.

Transport Parameters and 0-RTT:

QUIC transport parameters (like max_stream_data, initial_max_data) are negotiated during the handshake. For 0-RTT, the client uses transport parameters stored with the session ticket—the parameters from the previous connection.

This creates a compatibility requirement: if the server's parameters change, 0-RTT might be rejected or constrained. For example, if the server previously allowed 64KB initial window but now allows only 32KB, the client cannot send more than 32KB of 0-RTT data.

Key Parameters for 0-RTT:

0-RTT Transport Parameter Considerations

•max_early_data_size — Maximum bytes of 0-RTT data allowed. Client must not exceed this. Servers set based on risk tolerance and buffer capacity.
•initial_max_data — Connection-level flow control. Client's 0-RTT data must respect the stored value. Server can increase it in handshake.
•initial_max_stream_data_** — Per-stream limits. 0-RTT streams must respect stored limits or risk rejection.
•ALPN (application protocol) — Application protocol must match stored value. HTTP/3 ticket can't be used for different protocol.
•Server name (SNI) — Ticket is bound to specific server identity. Cannot be reused for different domains.

Stored 0-RTT Parameters Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Session Ticket Stored Parameters:
==================================
 
When client receives NewSessionTicket after initial connection:
 
Ticket = Encrypt_ServerKey({
  psk_identity: random_bytes(32),
  resumption_secret: derived_from_handshake,
  ticket_nonce: unique_per_ticket,
  
  # Stored transport parameters (0-RTT uses these)
  saved_transport_params: {
    initial_max_data: 65536,
    initial_max_stream_data_bidi_local: 32768,
    initial_max_stream_data_bidi_remote: 32768,
    initial_max_stream_data_uni: 32768,
    initial_max_streams_bidi: 100,
    initial_max_streams_uni: 100,
    max_idle_timeout: 30000,
    max_udp_payload_size: 1472,
  },
  
  # Application layer requirements
  alpn: "h3",
  server_name: "example.com",
  
  # Validity
  creation_time: 1705312800,
  expiry_time: 1705399200,  # 24 hours later
  max_early_data_size: 16384,
})
 
Client stores this ticket along with:
- Server address
- Server certificate chain (for verification)
- Creation timestamp (for age calculation)
 
On 0-RTT attempt:
- Client uses saved_transport_params for flow control limits
- Client sends at most max_early_data_size bytes
- If server's current params differ, server may reject 0-RTT
- After handshake, new parameters from ServerHello apply

Ticket Lifetime Considerations

Servers must balance ticket lifetime against security and freshness. Longer lifetimes improve 0-RTT hit rate (users returning after days still have valid tickets) but increase replay window and may use stale parameters. Typical production lifetimes range from 1 hour to 7 days, depending on risk tolerance.

0-RTT and HTTP/3

HTTP/3 extends 0-RTT to the application layer with specific guidance on safe usage. Not all HTTP methods are safe for 0-RTT, and HTTP/3 provides mechanisms for safe early data.

HTTP Method Safety for 0-RTT:

HTTP Methods and 0-RTT Safety
Method	Idempotent	0-RTT Safe	Notes
GET	Yes	✅ Safe	Read-only, naturally idempotent
HEAD	Yes	✅ Safe	Same as GET without body
OPTIONS	Yes	✅ Safe	Discovery, no side effects
PUT	Yes	⚠️ Careful	Idempotent by spec, but check impl
DELETE	Yes	⚠️ Careful	Deleting twice should be safe
POST	No	❌ Unsafe	Creates resources, not replayable by default
PATCH	No	❌ Unsafe	Partial update may not be idempotent
CONNECT	N/A	❌ Unsafe	Establishes tunnel, not early data

HTTP/3 Early Data Handling:

HTTP/3 clients should:

Only send GET, HEAD, OPTIONS in 0-RTT by default
For other methods, use application-specific knowledge of idempotence
Be prepared to retry any 0-RTT request if rejected
Use Early-Data header to signal 0-RTT to application

The Early-Data Header:

When a request is sent as 0-RTT, intermediaries (proxies) may add:

GET /api/data HTTP/3
Early-Data: 1

This header tells the origin server that the request arrived as early data. The server can then make informed decisions:

Accept if request is safe
Reject with 425 (Too Early) if replay risk is unacceptable
Process tentatively and confirm after handshake

HTTP/3 0-RTT Request Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
HTTP/3 0-RTT Example:
=====================
 
Client with valid session ticket for api.example.com:
 
First packet contains:
  Initial: ClientHello with PSK
  0-RTT: 
    STREAM 0: HTTP/3 control stream setup
    STREAM 4: HEADERS frame
              GET /api/user/profile
              Host: api.example.com
              Accept: application/json
 
Server processes 0-RTT:
  - Validates PSK, accepts early data
  - Decrypts HEADERS frame
  - Sees safe GET request
  - Processes request while completing handshake
 
Server response (1-RTT encrypted):
  STREAM 4: HEADERS frame
            HTTP/3 200 OK
            Content-Type: application/json
  STREAM 4: DATA frame
            {"name": "Alice", "email": "..."}
 
Timeline:
  T=0:      Client sends first packet
  T=10ms:   Server receives, processes GET immediately
  T=15ms:   Server sends response (includes handshake)
  T=25ms:   Client receives data
 
Without 0-RTT (1-RTT):
  T=0:      Client sends ClientHello
  T=10ms:   Server receives, sends ServerHello
  T=20ms:   Client receives, sends Finished + GET
  T=30ms:   Server processes GET, sends response
  T=40ms:   Client receives data
 
Savings: 15ms (1 RTT) in this example.
On 100ms mobile RTT: 100ms savings.

Real-World 0-RTT Usage

Major deployments use 0-RTT extensively. Google reports 0-RTT success rates of 70-85% for return visitors, with significant latency improvements for mobile users. Cloudflare and Fastly enable 0-RTT for HTTP/3 by default, with application-layer safety ensured by method filtering.

Summary: 0-RTT Connection

We've explored QUIC's 0-RTT connection establishment in depth. Let's consolidate the key concepts:

Key Takeaways

•0-RTT eliminates handshake latency for return visitors — Clients with valid session tickets can send encrypted application data in their first packet, without waiting for any response.
•0-RTT builds on TLS 1.3 PSK resumption — Session tickets provide the pre-shared key material that enables immediate encryption. This is inherited directly from TLS 1.3 specification.
•Replay attacks are cryptographically unavoidable — The same property that enables 0-RTT (pre-existing keys) enables replay. There is no cryptographic fix; solutions must be at the protocol or application layer.
•Servers must implement replay protection — Single-use tickets, strike registers, or application-layer idempotence are necessary to prevent replay abuse.
•Only idempotent operations should use 0-RTT — GET requests are generally safe; POST/PATCH requests with side effects are dangerous without additional protection.
•0-RTT rejection is normal and graceful — Clients must be prepared for rejection and retry as 1-RTT. The connection still succeeds, just with one additional round trip.
•HTTP/3 provides method-based safety — Safe methods (GET, HEAD, OPTIONS) are appropriate for 0-RTT by default. The Early-Data header signals early data usage to origins.

What's next:

With 0-RTT understood, we'll complete our QUIC exploration with HTTP/3 Foundation—examining how QUIC serves as the transport layer for the next generation of HTTP. We'll see how HTTP/3 leverages QUIC's streams, eliminates head-of-line blocking, and represents the culmination of lessons learned from HTTP/1.1 and HTTP/2.

Page Complete

You now understand how QUIC's 0-RTT enables immediate data transmission for returning connections, the security tradeoffs involved, and the strategies for safe 0-RTT usage. You've seen how this integrates with TLS 1.3 session resumption and how HTTP/3 provides application-layer guidance for safe early data. Next, we'll explore HTTP/3 and how it builds on QUIC's capabilities.