📘

This behavior is Limited Availability. To enable it, contact your Akamai account team.

To protect your data and address the privacy and security goals, Akamai can use Post Quantum Cryptography (PQC) to protect transport layer security (TLS) communications. We align with the industry standard and offer the ML-KEM based hybrid key exchange.

How it works

The Post Quantum Cryptography to Origin behavior allows you to enable Post Quantum Cryptography (PQC) key exchanges with your origin. We recommend enabling PQC for enhanced security. You may disable PQC if you observe high latency or increased error rate at the origin.

• This behavior is compatible only with Media Service Live and custom origins.
• To use Post Quantum Cryptography to Origin (PQC), your Origin TLS version needs transport layer security (TLS) version 1.3 and support for PQC (X25519MLKEM768 key exchange).
• Post Quantum Cryptography to Origin applies only to Enhanced TLS hostnames. Standard TLS hostnames in your property won't be affected by this change.
• The multiple instances of the behavior can exist in the same configuration with a last-match-win approach.
• The behavior could be placed in the default rule to change the property behavior or under a particular match.
• When you enable FIPS, it disables PQC to Origin.

Persistent Connections

Changing the value of Post Quantum Cryptography to Origin doesn’t impact existing Persistent Connections (PCONNs). Existing PCONNs opened without PQC key exchanges will not be closed and requests will continue to use it.

After enabling the behavior, the new connections offer PQC key exchange. The opened PCONN will be used for subsequent requests even if the origin chose not to negotiate a PQC key exchange.

Features

• Enabling or disabling PQC under a match doesn’t cause Akamai Edge Server to close existing PCONNs.
• Open PCONNs will continue to be used.
• An origin could simultaneously have both PCONNs that performed PQC key exchange and PCONNs that didn't.
• If no PCONN is available, the match’s PQC status will be honored.

Given the rules above, a property may set PQC off in the default rule and enable PQC under a match for the path /foo. A request to /foo will only open a PQC PCONN if there are no existing PCONNs. The recommendation is to add this behavior in the same place as the Origin Server behavior.

Features and options

Origins not supporting X25519MLKEM768

By default, the behavior contacts the origin offering a non-PQC key (currently X25519). This works best for origins that don’t support X25519MLKEM768 yet, as it minimizes the number of roundtrips required for a successful TLS handshake.

The default behavior of offering the classic X25519 key in ClientHello means that origins that do support PQC need to initiate HelloRetryRequest to request the X25519MLKEM768 key share from the client. This adds one more roundtrip to complete the handshake.

Origins supporting X25519MLKEM768

An origin that supports PQC should enable the PQC Keys in First ClientHello option for Akamai to immediately offer X25519MLKEM768 in the ClientHello. Then an origin that doesn’t support PQC would initiate HelloRetryRequest to request the classic X25519 key share at the cost of one additional roundtrip.

So if you know that your origin supports PQC, enable the PQC Keys in First ClientHello option, but if you are unsure, leave that setting disabled. In either scenario, a PQC connection will be established if it is supported.