On Mon, Oct 28, 2024 at 09:37:27PM +0000, Ben Schwartz wrote: > This Message Is From an External Sender > This message came from outside your organization. > > On ALPNs - Yes, this is something of an open question. There are some > hints about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that > treats this context as sensitive SHOULD NOT send context-specific values > in ClientHelloOuter.". > I've occasionally wondered if we would define an ECHConfig extension that > indicates a recommended "wire image" for the outer ClientHello, to > mask differences between clients, but we don't have anything like that > yet. > Interaction with QUIC version is also a fun question, and goes to the ALPN > vs. transport distinction. This is also as-yet-undetermined, but might > involve a new SVCB parameter for supported QUIC versions, and/or perhaps > some notion of "compatible" and "incompatible" QUIC versions. > On 1/K anonymity - The upshot of this is "large K is better", i.e. "ECH > helps more if your service shares hosting with lots of other services > whose access patterns are similar.". But that's a decision that must be > weighed against many other factors, from consolidation pressure to > infrastructure budget, so it seemed best to just mention the math and let > the operator choose as they will.
I agree that there's going to be a tradeoff between larger K's privacy benefit and other considerations, but it seems to me that even the framing as "1/K" is misleading. When the sites behind a given fronting service are of differingi popularity, the attacker can do better than 1/K at guessing. If I'm fronting for a site that gets 900k hits/day and ten that get 10 hits/day, the attacker can just guess that all requests are for the popular site and they'll get the right answer 99.9% of the time. I do see the disclaimer about "idealized deployment" at the start of the paragraph but I think we could do more to highlight just how idealized this portrayal is. -Ben _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
