Good for me Arnaud Taddei Global Security Strategist | Enterprise Security Group
mobile: +41 79 506 1129 Geneva, Switzerland arnaud.tad...@broadcom.com <mailto:arnaud.tad...@broadcom.com> | broadcom.com > On 30 Oct 2024, at 22:18, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > wrote: > > 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 > <https://www.google.com/url?q=https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/20&source=gmail-imap&ust=1730927988000000&usg=AOvVaw0ueyeUdjcs-FPnto51YIT8> > > --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 -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
