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. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
