On Tue, Oct 10, 2023 at 10:01 AM David Benjamin <david...@chromium.org> wrote:
> 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. > OK, I see. It's worse than a compatibility risk, though, isn't it? If you just let them break in case (a), and then maybe try again with (b), that opens up a downgrade attack. Intermediaries can observe the size of the Client Hello and make it break. I understand it now, thanks for taking the time to explain. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
