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. This behavior aligns with industry standards and turns on ML-KEM based hybrid key exchange by default when enabled.

How it works

The Post Quantum Cryptography to Origin behavior allows you to enable Post Quantum Cryptography (PQC) key exchanges with your origin, while remaining fully backwards compatible with origins that do not yet support PQC. We recommend enabling PQC for enhanced security.

• This behavior is only compatible with Media Services Live and Origin Type “Your Origin”. See Custom origin prerequisites.
• To use Post Quantum Cryptography to Origin, your Origin TLS version needs transport layer security (TLS) version 1.3 and support for PQC (X25519MLKEM768 key exchange).
• To use TLS 1.3, enable the SNI TLS Extension option in the Origin Server behavior
• Post Quantum Cryptography to Origin applies only to Enhanced TLS hostnames. Standard TLS hostnames in your property won't be affected by this change.

  📘

  We support Enhanced TLS in this behavior only for some users. Contact your Akamai representative to check your options.

• Multiple instances of this behavior can exist in the same configuration with a last-match-win approach.
• You can place this behavior in the default rule to change your property behavior. It can also be used or under a particular match.
• When you enable Post Quantum Cryptography to Origin, connections to origins that don't support PQC transparently negotiate a classic X25519 key exchange if the origin supports it.

Features

• Enabling or disabling PQC under a match doesn’t cause Akamai edge servers to close existing PCONNs.
• Open PCONNs will continue to be used.
• An origin can simultaneously have PCONNs that perform PQC key exchange and PCONNs that don't.
• If no existing PCONN is available, the match’s PQC status will be honored for new requests.

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.

Key share without PQC

In a default TLS 1.3 handshake without PQC, the ClientHello message includes the classic, X25519 key share. X25519 keys provide a standard level of security using public and private key pair recognition and shared secrets. If an origin supports PQC and X25519MLKEM768 key sharing, but the Post Quantum Cryptography to Origin behavior isn’t enabled, the origin completes handshakes over the X25519, or similar, key exchange.

Key share with PQC enabled

Enabling Post Quantum Cryptography to Origin turns on PQC and instructs Akamai to immediately include a X25519MLKEM768 key share in the ClientHello message in the TLS 1.3 handshake. X25519MLKEM768 keys are used to establish an encrypted connection based on the derived shared secret. If an origin doesn't support PQC, it initiates a HelloRetryRequest to request the classic X25519 key share, adding one additional roundtrip.

Features and options

Implementation

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, any new connections start offering PQC key exchange. The opened PCONN will be used for subsequent requests even if the origin chooses not to negotiate a PQC key exchange.

Origin control over TLS negotiation

While the Post Quantum Cryptography to Origin behavior allows Akamai to offer key exchange options, your origin server makes the final decision on the key exchange used.

With PQC enabled, Akamai includes key exchange options, such as X25519MLKEM768, in the ClientHello message, but your origin has full control over the TLS negotiation parameters and can choose a different key exchange option if Akamai supports it. For example, if your security requirements mandate enforcing a specific key exchange, like only allowing X25519MLKEM768, you need to configure the enforcement at your origin.