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

Reply via email to