On Fri, 29 Sept 2023 at 15:45, Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote:
> We have been investigating turning on post-quantum key agreement for > connections from Cloudflare to origin servers. In testing, we found that > 0.34% of origins will fail to establish a connection if we send > X25519Kyber768Draft00 keyshare directly (while still advertising support > for classical keyshares.) As expected, a significant portion of failures > seem to be caused by the large ClientHello. Interestingly though, the > majority of these failures don't seem to be specific to the size of the > ClientHello, but are rather caused by the origin not supporting > HelloRetryRequest correctly. We're still digging into it, and will share > our findings later on. > > Anyway, even though it's a small fraction of origins, we cannot send a PQ > keyshare immediately and completely break the websites in front of those > few origins. Instead, we are going [1] for the following approach: we send > a X25519 keyshare, but advertise support for Xyber. > If the client is happy with either X25519 alone or X25519Kyber768, why not send shares for both in the first ClientHello? Yes, that adds more bloat there (but it's already large) but it need not require any additional computation (because the prefix of a X25519Kyber768 share is a valid X25519 share, and the server can only proceed with one). Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a blessed implementation choice, or conversely disrecommends it and explains why. Thanks, Joe
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
