tldr.fail
The migration to post-quantum cryptography is being held back by buggy servers<br>that do not correctly implement TLS. Due to a bug, these servers reject<br>connections that use post-quantum cryptography, instead of negotiating<br>classical cryptography if they do not support post-quantum cryptography.
What is the bug?
The Internet is currently beginning a migration to quantum-resistant<br>cryptography. This migration is important because large-scale quantum computers<br>will be powerful enough to break most public-key cryptosystems currently in use<br>and compromise digital communications on the Internet and elsewhere. It is<br>important to migrate to cryptography that cannot be broken by a quantum computer<br>before quantum computers exist.
Unfortunately, some buggy servers are not prepared for clients to start<br>supporting post-quantum-secure cryptography. The TLS protocol contains a<br>mechanism for the server and client to negotiate the cryptographic algorithms<br>used for the connection based on which algorithms are mutally supported by both.<br>This means that correctly-implemented servers that have not yet added support<br>for the draft post-quantum algorithms should silently ignore the post-quantum<br>option, and select a different classical algorithm.
TLS ClientHello messages that offer post-quantum cryptography are larger than<br>classical ClientHello messages, and exceed the threshold for transmission in a<br>single packet. This means that a single call to TCP read() might not return<br>the entire ClientHello packet. This has always been possible in TCP, but it is<br>exacerbated by the larger ClientHello messages. Most buggy servers are not<br>prepared to have to call read() more than once to read the entire ClientHello.<br>This is still a bug even prior to the post-quantum migration, however, the bug is<br>much more commonly exposed when the larger post-quantum cryptography is in use.
What is post-quantum-secure cryptography?
Modern public-key cryptography is secure in the face of a classical computer,<br>but can be broken by a quantum computer. Luckily, quantum computers don't exist<br>yet!
Post-quantum-secure cryptography (also shortened to post-quantum cryptography)<br>is cryptography that is resistant to quantum computers. Due to the power of<br>math, we can design, build, and verify this cryptography using only classical<br>(non-quantum) computers.
NIST recently ran a competition to find the best<br>post-quantum cryptographic algorithms, and is in the process of standardizing<br>the winners. Some of the winning post-quantum cryptographic algorithms include<br>Kyber for key exchange and key encapsulation, and<br>Dilithium for digital signatures. The IETF is<br>standardizing how to integrate this cryptography into TLS.
Why is this happening now?
Future quantum computers pose a risk to current Internet traffic through<br>store-then-decrypt attacks, in which attackers harvest encrypted sensitive<br>information now, and then decrypt it later, once quantum computers exist.<br>Mitigating this threat requires deploying a post-quantum key exchange mechanism<br>now.
To start mitigating the store-then-decrypt attack, Chrome is in the<br>process of rolling out a post-quantum key exchange.
What is the status of post-quantum cryptography in browsers?
Post-quantum key exchange is rolling out in browsers. See<br>Deployment.
What about authentication?
Quantum computers are capable of breaking the digital signature algorithms used<br>for authenticating digital communications today. Post-quantum signature<br>algorithms exist, but still have performance issues that make them difficult to<br>integrate into existing authentication systems, such as HTTPS certificates<br>(X.509). Luckily, unlike key exchange, the risk to authentication from a quantum<br>computer requires a sufficiently powerful quantum computer to actually exist,<br>since connections are authenticated in realtime. The store-then-decrypt attack<br>does not apply to authentication algorithms.
This means the migration to post-quantum secure authentication algorithms is less<br>urgent than key exchange. Due to the slow moving nature of the authentication<br>ecosystems on the Internet, such as the Web PKI, it is important to start this<br>migration soon. However, there is no urgent threat to authentication, like<br>there is with key exchange.
Does this bug apply to classical cryptography?
Servers that are not prepared for a ClientHello may incorrectly reject any<br>connection, especially if it split over two packets. This is less likely with<br>classical cryptography, but can happen. You can test for this by sending "half"<br>a ClientHello, and then waiting before sending the rest, and seeing if the<br>server correctly handles the connection, or if it resets the connection. This<br>bug is not specific to post-quantum cryptography, but is exacerbated by it.
How does this affect the migration to post-quantum cryptography?
TLS contains a mechanism for negotiating the cryptographic algorithms used for<br>the connection. If things were working correctly, servers that don't...