Skip to main content

Last Call Review of draft-ietf-tls-svcb-ech-06
review-ietf-tls-svcb-ech-06-genart-lc-pardue-2024-10-26-00

Request Review of draft-ietf-tls-svcb-ech
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-11-15
Requested 2024-10-22
Authors Benjamin M. Schwartz , Mike Bishop , Erik Nygren
I-D last updated 2024-10-26
Completed reviews Dnsdir Early review of -01 by Ted Lemon (diff)
Artart Last Call review of -06 by Barry Leiba
Genart Last Call review of -06 by Lucas Pardue
Dnsdir Last Call review of -06 by James Gannon
Assignment Reviewer Lucas Pardue
State Completed
Request Last Call review on draft-ietf-tls-svcb-ech by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/EJnL8b1UWqTHadcj5vBH-vJ7ACc
Reviewed revision 06
Result Ready
Completed 2024-10-26
review-ietf-tls-svcb-ech-06-genart-lc-pardue-2024-10-26-00
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.