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<m...@lowentropy.net> 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
