Hiya,
On 01/04/2021 19:13, Christopher Patton wrote:
But let me ask a question meanwhile - how often does HRR actually happen and could we not just let ECH fail in a bunch of situations that would otherwise require all this new complexity?One way HRR is used is in case the client's and server's cipher suite preferences don't intersect. This feature is an essential part of TLS, as there's no a priori reason why the client and server will initially advertise overlapping preferences. (They usually do, hence the claim thatHRR is rare.)
I've seen that claim and kinda suspect it's valid but my question was whether anyone had measured it?
I don't think aborting the handshake instead of HRR is an acceptable solution, as this would mean there are deployments with which TLS couldn't be used.
No. At worst it might mean that there are places that need to do some config before TLS+ECH will work, but that's true already - they'll need to publish an ECHConfig anyway. I really wonder if we could not achieve as good an outcome much more easily with some guidance on checking your front- end's choice of curves and failing when some of the HRR cases get out of whack. (There'd still be some work to do for ECH as we can't as you say get rid of HRR, but there might be a lot less work/complexity.) Cheers, S.
Chris P.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
