Hey Ben, Responding in line:
On Mon, Oct 28, 2024, at 21:37, Ben Schwartz wrote: > 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. I guess it's a bit open and up to the client, that's a bit outside my wheelhouse so I can't provide much more useful commentary. I'll trust the authors have considered things and made the best call for this draft. > > 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. Yeah. martin Duke and I put out a draft a while ago for a "quicv" SvcParamKey [1]. It's been on ice since there's not been much of a problem to solve and around the same time the HTTP WG had been discussing killing Alt-Svc so we wanted to see how the wind blew. We could always defrost the work if there's problems to solve. I think this draft is fine to proceed in its current state. > > 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. That seems OK. I have no inspiration for any additional text you could add. Cheers Lucas [1] - https://datatracker.ietf.org/doc/draft-duke-httpbis-quic-version-alt-svc/ > --Ben > > > *From:* Lucas Pardue via Datatracker <nore...@ietf.org> > *Sent:* Saturday, October 26, 2024 4:29 PM > *To:* gen-...@ietf.org <gen-...@ietf.org> > *Cc:* draft-ietf-tls-svcb-ech....@ietf.org > <draft-ietf-tls-svcb-ech....@ietf.org>; last-c...@ietf.org > <last-c...@ietf.org>; tls@ietf.org <tls@ietf.org> > *Subject:* Genart last call review of draft-ietf-tls-svcb-ech-06 > > > > Reviewer: Lucas Pardue > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!Bt8RZUm9aw!5Vbb4B9O46eZuQM48z8XO1c6odOeIpcoW2a3aFtoAXAxZBQf7D93P4nG_tzb9Awuw4lwGqWT-SE$ > >. > > Document: draft-ietf-tls-svcb-ech-06 > Reviewer: Lucas Pardue > Review Date: 2024-10-26 > IETF LC End Date: 2024-11-15 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document defined how TLS Encrypted ClientHello (ECH) connections can be > bootstrapped via the DNS. ECH provides privacy for client by encrypting > information that can identify the service they are connecting to (the SNI) but > furthermore any other information that needs to go in the ClientHello, such as > QUIC transport parameters. ECH is one of the final missing pieces for protocol > designers that want to leverage client-offers without trading off user > privacy. > Having the means for clients to discover and correctly configure ECH is > essential. While many mechanisms could work, the DNS offers a widely > distributed and immediately available option. > > The document clearly defines the wire format for distributing ECH information > to clients. It also takes care to detail considerations related to complex but > realistic deployments, such as multi CDN, that could cause operational issues > if misconfigured. It is my opinion that this document provides a solution to > the stated problem and is ready to go. > > I have 3 comments on the draft that sit somewhere between minor and editorial. > These are just comments, and might reveal my lack of familiarity with the > subject matter more than any issue with the document. If the authors wish to > respond I'd appreciate it but there is no expectation for them to retread > explanation or details that may have already been resolved during the WG > phase. > > Comment 1 - Section 5.2 ClientHello construction > > To paraphrase the text, my read is "when ECH is in use, the HTTPS alpn > svcparam > is only used for the inner ClientHello, not the outer". This immediately made > me wonder how the outer ClientHello is constructed. I read Section 10.5 of > draft-ietf-tls-esni-22 but I'm still not sure. For example, if I provide an > HTTP/2 only service and advertise that, the client has to attempt to connect > with ECH containing an ALPN extension of "h2" no? Or should it stick an > "http/1.1" in there, even though it knows it won't do anything, for the > purpose > of defeating on-path observers of the outer ECH? > > I didn't spend much time thinking about this but I'm having some weird visions > about where this might go if add new QUIC versions and need new ALPNs for > mappings on those. For example, HTTP/X over QUIC version Y, advertised via a > SVCB would necessitate the client connect using QUIC version Y and send an > outer ECH with what ALPNs? > > Maybe this is just something we punt on for now, or state that QUIC version > negotation could solve it or something. I'm just left with a feeling of not > being sure what to do here and it feels like a security consideration that > isn't highlighted with a back ref in the security considerations. > > Comment 2 - Section 6 Interaction with HTTP Alt-Svc > > I had not really considered the interactions of ECH with Alt-Svc. This section > is good. It's beyond the scope of this I-D to comment on, but wonder if this > is > another death knell for Alt-Svc because its a major footgun. > > Comment 3 - 2nd paragraph of Security Considerations > > > In an idealized deployment, ECH protects the SNI with an anonymity set > consisting of all the ECH-enabled server domains supported by a given > client-facing server. Accordingly, an attacker who can enumerate this set can > always guess the encrypted SNI with probability 1/K, where K is the number of > domains in the set. In practice, this probability may be increased via traffic > analysis, popularity weighting, and other mechanisms. > > The statement is clear in and of itself. However, it feels a bit unsatisfying. > What am I supposed to do with this as a client or server operator? Maybe > there's nothing I can do? To put it another way, this just seems like a > statement about ECH itself and not necessarily something specific about with > respect to the SVCB ech parameter? Or perhaps you're highlighting that putting > things in the DNS actually makes it a bit easier to enumerate the anonymity > set > because I can just scrape names and look at their ECH configs and do some > calculations with that. > > I'm getting a sense of "you're doomed no matter what tricks you might think > you > can do to avoid this happening". If that's the reality I think its ok but > maybe > the doc could add a sentence to state it plainly. >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
