On Mon, Jul 7, 2025 at 12:11 PM Eric Rescorla <e...@rtfm.com> wrote:
> On Mon, Jul 7, 2025 at 8:23 AM David Benjamin <david...@chromium.org> > 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. > I think the MUST requirements imply a special channel. It's specifically knowing that the channel for ClientHelloInner will *only* receive ClientHellos from a client-facing server. If you accept general client traffic, you'll break. If nothing else because of this rule, in combination with GREASE: > Similarly, in split mode, a backend server which receives a ClientHello with ECHClientHello.type of outer MUST abort with an "illegal_parameter" alert. If you already had to configure your serving infrastructure to listen on this port and speak TLSForECHBackend, we didn't have any compatibility requirement to make it take a ClientHello. It could have passed whatever was convenient. Not that that would be a broken protocol. I don't know how much I personally buy the non-coordinating client-facing and backend server theory. But if the WG wanted a protocol that supported this theory, the MUSTs are a bit inconsistent with that. David > -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 <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
