Hiya,
On 06/07/2025 01:14, Eric Rescorla wrote:
I'm confused. Backend servers already know they are backend servers, as in S 7.2. The only new code here is that they must reject anything with ECH.type == outer.
Let me posit an example. Say we have CFS setup as a frontend and BE setup as a backend, with e.g. some VPN in between. As BE is ECH-aware, but has no ECH private keys, it knows how to produce an ECH-acceptance signal when it gets an inner CH. CFS and BE also need to know how to handle cases where the client is not ECH enabled, which will happen quite often, for some years at least. The current text seems to require the CFS to route connections to BE differently if ECH decryption worked or not, e.g. to a different port on BE, whereas it seems more natural to route those connections to the same BE port based on the inner SNI when ECH decryption worked, or the outer SNI if ECH wasn't attempted. (That's what the haproxy and nginx split-mode CFS code we've done can do, albeit that code hasn't been upstreamed.) If the current text requires the CFS to route connections differently based on whether or not ECH decryption worked, I'm not seeing why that's a win. But maybe I'm missing something that'd mean that BE needs to be configured differently based on whether ECH decryption worked, or whether ECH wasn't attempted. If the CFS routes connections to the same port on BE regardless, that seems ok, so I'm also not seeing a security problem if that's allowed. So, am I missing something? (Which happens often:-) Cheers, S. PS: I'm not arguing that the current text can't work, only that I don't understand why it's wise.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
