Add split ClientHello and HRR workaround to pqc-to-origin

Author: RebeccaTamachiro

src/content/docs/ssl/post-quantum-cryptography/pqc-to-origin.mdx

@@ -8,3 +8,16 @@ head: []
 description: Learn about post-quantum cryptography in connections from Cloudflare to your origin servers.
 ---
 
+As explained in [About PQC](/ssl/post-quantum-cryptography/), Cloudflare has deployed support for hybrid key agreements, which include both the most common key agreement for TLS 1.3, X25519, and the post-quantum secure ML-KEM.
+
+However, while with X25519 the [ClientHello](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) almost always fits within one network packet, with ML-KEM the ClientHello has to be split over two network packets.
+
+This poses a question of how the origin servers - as well as other middleboxes (routers, load balancers, etc) - will handle this behavior. Although allowed by the TLS standard, a split ClientHello risks not being handled well due to [protocol ossification](https://en.wikipedia.org/wiki/Protocol_ossification) and implementation bugs. Refer to our [blog post](https://blog.cloudflare.com/post-quantum-to-origins/) for details.
+
+## ClientHello from Cloudflare
+
+To reduce the risk of any issues when connecting to servers that are not ready for hybrid key agreements, Cloudflare leverages HelloRetryRequest. This means that, instead of sending [X25519MLKEM768](/ssl/post-quantum-cryptography/#hybrid-key-agreement) immediately as a keyshare [^1], Cloudflare will only advertise support for it.
+
+If the origin supports ML-KEM, it can use HelloRetryRequest to request it from Cloudflare.
+
+[^1]: When, to remove a round trip, a client makes a guess of what the server supports.