This is a useful and very timely draft — I would like to see it adopted. I'll argue it's more urgent than sketched by David.
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. A server that supports Xyber can then use HelloRetryRequest for a post-quantum connection. Undoubtedly due to GREASE (thanks David), we did not see any issues with this approach. [2] This comes at the cost of an extra roundtrip. To get rid of it, we're scanning key agreement support of origins, and in the future will send Xyber immediately if we see the origin supports it without failing. Now we come to the usefulness of this draft: without it we cannot guarantee that we will negotiate PQ even if both the client and server are configured to prefer it. The problem is that many TLS servers are content with a supported keyshare, and will not HRR even if a more preferred key agreement is available. Indeed: a MitM can break our PQ test connections, which will make us send X25519, while advertising support for Xyber. Despite advertising support for Xyber, many TLS servers will now be content with X25519. Best, Bas [1] https://blog.cloudflare.com/post-quantum-to-origins/ [2] Of course, when a server that can't handle large ClientHello or HRR adds Xyber, it will still need to fix those issues, but importantly they don't block the rest anymore. PS. We have also included some stats on classical key agreement support and preference of origins in [1]. On Tue, Sep 26, 2023 at 6:46 PM David Benjamin <david...@chromium.org> wrote: > Hi all, > > A while back, we discussed using a DNS hint to predict key shares and > reduce HelloRetryRequest, but this was dropped due to downgrade issues. In > thinking through post-quantum KEMs and the various transitions we'll have > in the future, I realized we actually need to address those downgrade > issues now. I've published a draft below which is my attempt at resolving > this. > > We don't need a DNS hint for the *current* PQ transition—most TLS > ecosystems should stick to the one preferred option, and then clients can > predict that one and move on. However, I think we need to lay the > groundwork for it now. If today's round of PQ supported groups cannot be > marked "prediction-safe" (see document for what I mean by that), > transitioning to the *next* PQ KEM (e.g. if someone someday comes up with > a smaller one that we're still confident in!) will be extremely difficult > without introducing downgrades. > > Thoughts? > > David > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Mon, Sep 25, 2023 at 6:56 PM > Subject: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > To: David Benjamin <david...@google.com> > > > A new version of Internet-Draft > draft-davidben-tls-key-share-prediction-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-key-share-prediction > Revision: 00 > Title: TLS Key Share Prediction > Date: 2023-09-25 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction > > > Abstract: > > This document clarifies an ambiguity in the TLS 1.3 key share > selection, to avoid a downgrade when server assumptions do not match > client behavior. It additionally defines a mechanism for servers to > communicate key share preferences in DNS. Clients may use this > information to reduce TLS handshake round-trips. > > > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
