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.