Hi Ben, I've proposed a text change to strengthen the warning in that paragraph: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/20
--Ben Schwartz ________________________________ From: Benjamin Kaduk <bkaduk=40akamai....@dmarc.ietf.org> Sent: Monday, October 28, 2024 6:26 PM To: Ben Schwartz <bem...@meta.com> Cc: Lucas Pardue <lu...@lucaspardue.com>; draft-ietf-tls-svcb-ech....@ietf.org <draft-ietf-tls-svcb-ech....@ietf.org>; tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06 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
