Early Review of draft-ietf-tls-svcb-ech-01
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.