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. --Ben ________________________________ From: Lucas Pardue via Datatracker <[email protected]> Sent: Saturday, October 26, 2024 4:29 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
