On Mon, Jul 7, 2025 at 8:23 AM David Benjamin <[email protected]> wrote:
> 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). > Yes, that's correct. > 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. > Hmm... I don't think knowing you are a back-end server is really the same as a special channel. -Ekr 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 <[email protected]> > 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
