On Tue, Jun 4, 2024 at 8:36 AM Bob Beck <bbe=40google....@dmarc.ietf.org> wrote:
> > > On Tue, Jun 4, 2024 at 7:24 AM Martin Thomson <m...@lowentropy.net> wrote: > >> On Mon, Jun 3, 2024, at 14:34, Bas Westerbaan wrote: >> > [...] We're scanning origins so that we can send a >> > supported keyshare immediately and avoid HRR (not rolled out yet.) >> > That's not just for performance, but also to deal with origins that >> > don't support HRR. >> >> Whoa. Are you saying that there are TLS 1.3 implementations out there >> that don't send HRR when they should? I get that you might want to >> optimize a little if you have to connect to a server often. >> >> Optimization is a very different thing to the origin not supporting HRR >> at all. > > > There are most certainly situations where you do not get an HRR when you > should. There is more than one implementation of buggy middleware out > there that mishandles large client hellos > Yes, that's what I've noticed. The more packets the ClientHelllo spans, the worse it gets. The Google folks did a few studies on this problem, but I'm not sure which paper is best to cite. thanks, Rob
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
