TLS 1.3 introduces Early Data, also known as zero round-trip time (0-RTT) data. It allows clients resuming a session to send application data during the TLS handshake, eliminating the need for an additional round trip.

📘
The Early Data behavior supports both QUIC-based traffic and Transmission Control Protocol (TCP).

How it works

Establishing a secure connection between a client and server consists of a series of messages to exchange cryptographic information and communication parameters before sending actual data. Before TLS version 1.3, establishing a secure channel after the handshake typically required two round trips (2-RTT). With the introduction of TLS 1.3, the TLS handshake has been reduced to one round trip (1-RTT) in most cases.

To further reduce Time To First Byte in TLS 1.3 connections, you can enable the Early Data behavior to allow clients that had previously connected to an edge server to send application data alongside the Client Hello, before performing a full TLS handshake. For more details, see RFC 8470 and RFC 8446. Currently, Akamai supports this behavior only with GET requests that don’t include any additional query string parameters.

Before you begin

Early Data requires a secure (HTTPS) connection between the requesting client and the Akamai edge network. To get this you can:

Create a Domain Validation (DV), Organization Validation (OV), or a third-party certificate and assign it to a property hostname.
Use the Akamai shared certificate in a property hostname.

You need TLS 1.3 support

To use Early Data, your certificate needs to have transport layer security (TLS) 1.3 enabled in its deployment settings. If you create a new DV or OV certificate and use Standard or Enhanced TLS with Akamai's Certificate Provisioning System (CPS), or you use the Akamai Shared Certificate, this is automatically enabled.

To ensure TLS 1.3 is enabled in your certificate, you can take a look at it in CPS:

In Akamai Control Center, select ☰ > CDN > Certificates.
Locate the applicable certificate. In the Actions column, select … > View and Edit Certificate.
Return to the landing page.

👍
If you’re limited on the number of certificates you can create, and this certificate isn’t active in a property hostname, select … > Delete to remove the certificate.

Click … > View and Edit Deployment settings for the certificate.
In the SNI Advanced Configuration panel, click Edit.
In the TLS Protocol Versions options, ensure that either of the following options is selected:
- Enable all TLS versions.
- Disable specific TLS versions. If you enable this, select each version you want left out, but ensure that TLS 1.3 is deselected.
If you made a change here, click Submit. If you didn't need to change anything, click Cancel.

Implementation

Add the Early Data (0-RTT) behavior and set the Enable slider to On.

🚧
You can only have one instance of the Early Data behavior in your property.

You can add the behavior to these rules in your property:

The Default Rule. All requests processed by this property will support Early Data.
A custom rule. You can add it in a custom rule, but you need to use specific match criteria:

Match	Description
Hostname	Include one or more hostnames that have been set up to use a compatible certificate, as discussed above. All requests that use the hostnames will use HTTP/3 for transfer.
Percentage of Clients	Set a percentage of the HTTP/3 requests that should be honored. This is considered a temporary implementation. For example, you could initially use these match criteria to limit HTTP/3 traffic to test it, or if you're looking to slowly roll out support. Then, you could progressively edit your property to increase this percentage.
Hostname and Percentage of Clients	Combine the two options into a single rule: Include one or more hostnames that have been set up to use a compatible certificate and set a percentage of the HTTP/3 requests to be honored.

Caveats and known issues

Consider the following points when adding the Early Data behavior to your property:

Early Data and Enforce mTLS settings. Early Data (0-RTT) is not supported with the Enforce mTLS settings behavior. Remove either of these behaviors from the rule tree, as your property can't include both.
Reduced forward security. Early Data is encrypted with keys derived from a session key. If an attacker gets access to this key, they could decrypt the early data. This only applies to the early data being sent.
Replay attacks. Since Early Data is sent before the TLS handshake completes, the server cannot determine if the request is legitimate. An attacker could capture packets containing early data and replay them against the server. This is why Akamai restricts this behavior only to GET requests without query parameters.
HTTP 425 Too Early Response. As per the RFC8470 standard, any request that originates from Early Data and goes forward to the origin server will include the Early-Data: 1 HTTP header. Seeing this header, the origin server can respond with a 425 Too Early status code, which indicates the client should resend the request after completion of the TLS handshake.