Ah I see. Thanks for clarifying. OK, if the use case is limited to extensions that are only used when ECH is supported, then it won't be used with GREASE ECH, so it won't facilitate differentiating GREASE ECH from real ECH. But if the extension is sent in the outer CH when ECH is not supported, then might as well always send it in the outer CH, even when real ECH is in use.
David On Fri, May 30, 2025 at 10:09 PM Christian Huitema <[email protected]> wrote: > > On 5/29/2025 5:12 PM, Martin Thomson wrote: > > 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. > > There is at least one such case: do not support SCONE if the peer does > not support ECH. > > -- Christian Huitema > >
