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://wiki.ietf.org/en/group/gen/GenArtFAQ>. 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
