Skip to main content

Early Review of draft-ietf-tls-svcb-ech-01
review-ietf-tls-svcb-ech-01-dnsdir-early-lemon-2024-03-29-00

Request Review of draft-ietf-tls-svcb-ech
Requested revision No specific revision (document currently at 06)
Type Early Review
Team DNS Directorate (dnsdir)
Deadline 2024-04-12
Requested 2024-03-29
Requested by Sean Turner
Authors Benjamin M. Schwartz , Mike Bishop , Erik Nygren
I-D last updated 2024-03-29
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
Comments
While this is a TLS WG I-D, it's about DNS RRs and HTTP Alt-svc.
Assignment Reviewer Ted Lemon
State Completed
Request Early review on draft-ietf-tls-svcb-ech by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/ZKpIOpWb7-hbVcPKmdnU48xXpPM
Reviewed revision 01 (document currently at 06)
Result Almost ready
Completed 2024-03-29
review-ietf-tls-svcb-ech-01-dnsdir-early-lemon-2024-03-29-00
This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.

Section 4.1 advises disabling fallback, but does not talk about DNSSEC, which
is surprising given that the draft proposes privacy properties for SVCB
responses containing ECH data. I would think that it would make sense to say
that the SVCB querier should attempt to validate the response, and then talk
about what to do for bogus, insecure and valid positive and negative responses.

For example, I would think that a /bogus/ response should be taken to mean that
the SVCB record must be assumed to exist and should be treated the same as if
the list of destinations were not reachable. An /insecure/ NXDOMAIN or NODATA
response would not provide this assurance, and so what is currently described
in the document makes sense for this case. A /valid/ NXDOMAIN would assure that
no SVCB record existed, and hence ECH is not available.

I don't think it's reasonable to specify the privacy properties of SVCB and
/not/ talk about DNSSEC validation.

I could see that there might be an objection that if DNSSEC isn't working at a
particular site because of a broken DNS resolver, this would prevent connecting
to perfectly acceptable destinations simply because of general DNSSEC breakage,
not a specific attack on this specific domain. The problem is that there's no
way to distinguish this from an attack. So if this exception is allowed, the
security considerations section should talk about what the risks are of
allowing it. E.g. if we succeed in validing the root and com, but can't
validate the zone containing the SVCB (or determine that it's not signed), that
would be a clear indication of an attack, but if we can't validate the root, it
could just be brokenness, and an attacker would do well to just prevent all
validation so that we can't distinguish.