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, so if you send a large key share you are out of luck. This doesn't mean the implementation is not attempting to implement HRR, it's just the bugs effectively mean if you hit the problem case, you lose. While hopefully ecosystem pressure eventually gets fixed versions deployed, the number of these in the wild is far from zero today. > > Are you concerned that this sort of coddling removes some useful incentive > to implement HRR? > > I've held this concern for a while, particularly for QUIC. If we have a > very homogeneous profile of support for primitives, we're risking having > the negotiation mechanisms fail when we need them. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
