diff options
Diffstat (limited to 'chromium/docs/website/site/cecpq2/index.md')
| -rw-r--r-- | chromium/docs/website/site/cecpq2/index.md | 57 |
1 files changed, 0 insertions, 57 deletions
diff --git a/chromium/docs/website/site/cecpq2/index.md b/chromium/docs/website/site/cecpq2/index.md deleted file mode 100644 index 3572b02d838..00000000000 --- a/chromium/docs/website/site/cecpq2/index.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -breadcrumbs: [] -page_name: cecpq2 -title: CECPQ2 ---- - -CECPQ2 is the name given to the combination of -[X25519](https://tools.ietf.org/html/rfc7748) and a post-quantum key-agreement -based on [NTRU-HRSS-KEM](https://ntru-hrss.org/). 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](https://blog.cloudflare.com/the-tls-post-quantum-experiment/). - -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
\ No newline at end of file |