What Is 0-RTT

Content on WhatAnswers is provided "as is" for informational purposes. While we strive for accuracy, we make no guarantees. Content is AI-assisted and should not be used as professional advice.

Last updated: April 11, 2026

Quick Answer: 0-RTT (Zero Round Trip Time) is a TLS 1.3 feature specified in RFC 8446 (March 2018) that allows clients to send application data during the initial handshake without waiting for server confirmation, eliminating one round trip. It can improve performance for approximately 40% of HTTPS connections that are session resumptions. However, 0-RTT data lacks forward secrecy and is vulnerable to replay attacks, requiring careful application-level design to prevent state-changing requests from being replayed.

Key Facts

RFC 8446 (TLS 1.3) published in March 2018 introduced 0-RTT as a session resumption optimization
0-RTT can reduce connection latency by eliminating one round trip for ~40% of HTTPS connections
0-RTT data is encrypted using PSK (Pre-shared Key) from previous sessions, not the ServerRandom value
0-RTT is vulnerable to replay attacks since encrypted early data can be captured and replayed without server detection
0-RTT provides no forward secrecy; if the PSK is compromised, all captured early data becomes readable

Overview

0-RTT (Zero Round Trip Time) is a performance optimization feature introduced in TLS 1.3, standardized in RFC 8446 published in March 2018. It allows a client resuming a previous session to send application data (called "early data") in the first message to the server without waiting for the server's response, thereby eliminating one round trip time in the connection establishment process.

This feature specifically targets session resumption scenarios, which account for approximately 40% of HTTPS connections. By reducing the number of network round trips required to establish a secure connection and begin transmitting application data, 0-RTT can significantly improve perceived performance for end users, particularly those on high-latency networks or mobile connections. However, this performance benefit comes with important security trade-offs that developers must understand and mitigate.

How It Works

The 0-RTT mechanism operates through a carefully orchestrated exchange between client and server during the TLS handshake:

Client Hello with Early Data: The client packages application data together with its ClientHello message. This early data is encrypted using a Pre-shared Key (PSK) that was established during a previous TLS session or provided through out-of-band mechanisms. The client sends this in the first network packet to the server.
PSK-Based Encryption: Unlike standard TLS 1.3 data, which is encrypted using keys derived from both the ClientRandom and ServerRandom values, 0-RTT data is encrypted solely using keys derived from the PSK. This one-directional key derivation is what enables the client to encrypt data without waiting for the server's random contribution.
Server Reception and Processing: Upon receiving the ClientHello with early data, the server immediately begins processing the application data without sending intermediate responses. If the server has knowledge of the PSK, it can decrypt and process the early data while simultaneously conducting the standard TLS handshake with the client.
Completion of Handshake: After processing the 0-RTT data, the server completes the TLS 1.3 handshake by sending its ServerHello and other necessary messages. The client can then send additional application data using the standard 1-RTT protection, which provides stronger security guarantees.
State and Idempotency: The server must maintain state about which 0-RTT data it has already processed to defend against simple replays. Applications must design their early data to be idempotent or safe to replay without causing unintended consequences.

Key Comparisons

Feature	0-RTT (Early Data)	1-RTT Standard TLS 1.3	Pre-TLS 1.3 Session Tickets
Handshake Rounds	Zero additional rounds	One round trip required	One round trip required
Forward Secrecy	No (PSK only)	Yes (ServerRandom included)	No (ticket only)
Replay Protection	Vulnerable (same PSK)	Protected (ServerRandom unique)	Vulnerable (same ticket)
Typical Latency Reduction	~25-50% for resumptions	Baseline	Baseline
Security Level	Weaker; requires app-level mitigation	Strongest; recommended for all data	Moderate; better than 0-RTT

Why It Matters

Performance for Mobile Users: Mobile devices frequently experience high latency and packet loss. By eliminating one round trip for resumptions, 0-RTT can reduce page load times by 25-50%, significantly improving user experience on slower networks.
Adoption Across CDNs: Major content delivery networks including Cloudflare, Akamai, and AWS CloudFront have implemented 0-RTT support. Wide adoption indicates the performance benefit justifies the security trade-offs for many use cases.
Replay Attack Risk: The primary security concern with 0-RTT is its vulnerability to replay attacks. An attacker who captures a client's early data packet can resend it to the server, potentially causing the same action to be performed twice. This is particularly dangerous for state-changing operations like fund transfers, form submissions, or account modifications.
Safe vs. Unsafe Operations: Applications should restrict 0-RTT to idempotent and read-only operations (such as GET requests, session tokens, or cache lookups). State-changing operations (POST, PUT, DELETE) should never be sent as 0-RTT data unless the application can guarantee idempotency or implements server-side deduplication.

Understanding 0-RTT's capabilities and limitations is essential for modern web developers. While it offers measurable performance improvements for session resumptions, its security properties require thoughtful application design. Organizations must evaluate whether the latency reduction justifies the complexity of protecting against replay attacks. Many recommend enabling 0-RTT but educating development teams on its constraints, or using it selectively for genuinely safe operations only.