On Fri, May 30, 2025, at 09:04, David Schinazi wrote: > On Thu, May 29, 2025 at 3:39 PM Martin Thomson <[email protected]> wrote: >> The question is whether there is any value you might prefer go in the inner >> CH only. > > ^ This is the premise that I don't understand. Maybe let me list all my > assumptions: > * the client is a Web browser that supports ECH and queries HTTPS RRs > to get the ECH config > * not all websites support ECH, meaning some have ECH configs in the > HTTPS RR and some don't > * the client connects to both ECH-enabled sites (with real ECH) and > non-ECH-enabled sites (with GREASE ECH) > * the client sends the same TLS extensions to all websites > > If those assumptions all hold, then a passive observer will see the > value that in the real ECH case is only sent in the inner client hello, > because it will be sent in the outer client hello in the case where the > site doesn't support ECH. So that information is already leaked - and > the passive observer can tie all these connections together by linking > on the client IP address. > > So I don't see the value of trying to put this value only in the inner > client hello. Am I missing something?
Perhaps. I'm thinking about new use cases that could use "secret"/inner transport parameters only. Those features would not be available when ECH isn't supported. Maybe those use cases are just performance optimizations, but we all know how those are not "just" anything.
