Hmm, these MUSTs puzzle me too. I recall a ton of fuss during ECH's design in ensuring that frontend -> backend communication in split mode didn't require any special channels (e.g. how the ECH acceptance signal depends only on ClientHelloInner and not the HPKE secret). Having a backend server know it is a backend server seems slightly inconsistent with this; if backend servers are special entrypoints, then we could have avoided all those constraints.
I had assumed the intended design was that TLS servers would just treat the type=inner ClientHello as a "please swizzle your server random" marker but otherwise not care too much about whether it received it internally (shared mode) or somewhere over the network. (Presumably from some client-facing server, but if not, nothing bad really happens.) On Sat, Jul 5, 2025 at 9:40 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > 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. > > > _______________________________________________ > 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
