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. 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
