CECPQ2

CECPQ2 is the name given to the combination of X25519 and a post-quantum key-agreement based on NTRU-HRSS-KEM. This combination provides at least the security of X25519, combined with the likelihood of resistance to future, large quantum computers that can otherwise decrypt all existing TLS connections.

Chrome optionally supports CECPQ2 in TLS 1.3 connections. The results of previous experiments with CECPQ2, and an isogeny-based key agreement, are detailed here.

CECPQ2 makes some TLS messages larger. Some non-compliant network middleware doesn't correctly handle these larger messages and can cause unexpected connection failures or timeouts. While quantum computers are still in the future, it's important to start the process of making the internet workable for quantum-resistant algorithms today so that it'll be ready.

Starting with Chrome 91 we plan on restarting a previous rollout of CECPQ2 support that was paused due to the pandemic. Initially CECPQ2 will be enabled for a deterministic subset of domains: those whose eTLD+1 begins with "aa". Since the errors caused by bad network middleware are ambiguous and varied, we are hoping that this distinctive pattern will help us categorize bug reports and identify those that might be related.

(The eTLD+1 of a domain is the effective TLD plus one label. For example, the eTLD of "www.example.co.uk" is "co.uk", so the eTLD+1 is "example.co.uk".)

Starting with Chrome 92, this rollout was expanded to all domains where the eTLD+1 beings with just a single 'a'. This uncovered bugs in Fortigate and (possibly) Palo Alto Networks devices which we are currently investigating.

With Chrome 93 and 94, this will be disabled by default.

CECPQ2 can be enabled for all domains by enabling chrome://flags/#post-quantum-cecpq2.

There are two ways in which bad middleware can cause problems with CECPQ2: Firstly, buggy middleware close to a specific site will cause that site to fail to work globally when CECPQ2 is enabled for it. Secondly, buggy middleware in a local network can cause all sites to fail when CECPQ2 is enabled for them, but only when the client is on that network. It's important to categorize the type of failure because it determines who can fix it: the first case is the sites' failure, the second must be fixed by local network administrators.

If CECPQ2 is suspected of causing problems then administrators can disable it by setting the CECPQ2Enabled policy to false. It is automatically disabled if ChromeVariations has a non-default value. If the failure is of the second kind, i.e. in the local network, then this should be considered a temporary workaround as, eventually, everything will very likely deploy some form of post-quantum security and thus use larger TLS messages. We are interested in collecting information about known-bad middleware