On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre <say...@gmail.com> wrote:
> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin <david...@chromium.org> > wrote: > >> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson <ietf= >> 40dennis-jackson...@dmarc.ietf.org> wrote: >> >>> To make sure I've understood correctly, we're trying to solve three >>> problems: >>> >>> - Some servers don't tolerate large Client Hellos >>> - Some servers don't implement HelloRetryRequest correctly >>> - Some servers prefer fewer round trips and accept an offered key >>> share even if both client and server would prefer a different group (for >>> which no key share was sent). This is especially troubling if we have to >>> migrate between PQ KEMs since we can't afford multiple key shares in the >>> ClientHello. >>> >>> >> First and third, yeah. I was mostly focused on the third one, but yeah >> we'll also need this if the first can't be cleared. (I hope we can just >> clear through it though. Even if we solve the downgrade problem, >> compatibility hacks for the large ClientHello will be bad for the ecosystem >> and very hard to remove later. But if we need it, we need it.) >> > > The impression I got in reading the various PQ experiment reports (and I > think David Benjamin did some of them...) was that the issues with large > Client Hellos *will* arise with PQ Client Hello messages. So... if a server > adds support for PQ, they will have to fix any underlying issues with large > Client Hello messages as a prerequisite, right? Can we cross the first > point off the list here? I'm a little confused about that point. > No, issues with large ClientHellos cannot be crossed off so simply. Keep in mind we cannot update the internet all at once. The client does not have a priori knowledge that the server implements PQ, but it needs to construct a ClientHello. It can choose to either: a) Send a ClientHello with Kyber in key_shares b) Send a ClientHello without Kyber in key_shares If it picks (a), any *non-Kyber-supporting* servers that break with large ClientHellos will break. If there are sufficiently few of these, we can maybe clear through it, but it is a compatibility risk we need to deal with. But the important thing is that we are precisely concerned with the non-Kyber servers here. It's not as simple as saying you fix that when you deploy Kyber. If it picks (b), non-Kyber-supporting servers behave as before, buggy or not. However, Kyber-supporting servers not only suffer a round-trip but also may not even pick Kyber. For example, if you were to add Kyber to OpenSSL today, it would pick X25519 when presented with (b). See https://github.com/openssl/openssl/issues/22203. BoringSSL will behave correctly, because we anticipated this issue when we first implemented TLS 1.3. I think NSS also knows about group preferences? But clearly the spec wasn't clear enough here. Thus this draft exists to resolve this. *This* server fix *can* be done as servers add Kyber support, but only if we remember to tell them that. Now, I'm hoping we can just make (a) work. Sending (b) also makes the preferred option (Kyber) take a round-trip and more complex schemes like fallbacks have a tendency to overstay their welcome. But different folks will have different risk preferences and deployment strategies, so I think it is worth making sure strategies involving (b) remain viable. And, of course, there's still the third problem.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
