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.