> I do not, however, think that we should have a SHOULD for using DNSSEC as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU WON'T)".
I agree On Mon, Sep 30, 2024 at 6:43 AM Eric Rescorla <e...@rtfm.com> wrote: > > > > On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters <paul.wouters= > 40aiven...@dmarc.ietf.org> wrote: > >> Hi, >> >> I have done my AD review of draft-ietf-tls-svcb-ech. Some history was >> well summarized by the Document >> Shepherd: >> >> Please note that the text in this I-D was initially developed in the DNSOP >> WG, >> went through IETF LC, and IESG review. The result of the IESG review was to >> take >> the text in this I-D out of RFC 9460 >> <https://datatracker.ietf.org/doc/rfc9460/> (was draft-ietf-dnsop-svcb-http) >> and run the >> new I-D through the TLS WG. The text in this I-D is essentially the same text >> taken from -11 of draft-ietf-dnsop-svcb-http. >> >> >> This is why I sent this review to both the TLS and DNSOP list. I have a >> few minor issues in the draft that I think >> need fixing: >> >> These downgrade attacks can prevent a client from being aware that >> "ech" >> is configured which could result in the client sending the ClientHello >> in cleartext. >> >> However, when DNSSEC is used and the TLS client can see the errors at the >> DNS layer, >> it can detect this downgrade attack is happening, and decide whether or >> not to continue with >> starting a TLS connection. I think the text should explain the difference >> in attack scenario in the >> presence and absence of DNSSEC. It might even be worth it to RECOMMEND >> DNSSEC, or recommend >> a DoH / DoT / DoQ connection to a DNSSEC supported DNS service. When >> referring to "DNSSEC", please >> use a normative reference to RFC9364. >> > > TBH, this whole section is kind of confusing, but I think it actually > is noting exactly what you are suggesting: > > An attacker who can prevent SVCB resolution can deny clients any > associated security benefits. A hostile recursive resolver can > always deny service to SVCB queries, but network intermediaries can > often prevent resolution as well, even when the client and > recursive resolver validate DNSSEC and use a secure > transport. These downgrade attacks can prevent a client from being > aware that "ech" is configured which could result in the client > sending the ClientHello in cleartext. To prevent downgrades, > Section 3.1 of [SVCB] recommends that clients abandon the > connection attempt when such an attack is detected. > > This section is kind of confusing, but I *think* what it's saying > is that the attacker permits resolution of the A/AAAA records > but blocks resolution of SVCB (it's not clear to me how it does > this in the case where you are using secure transport, is the > idea that it's an intermediary between the recursive and the > authoritative? If so, probably say so). As you say, this is > observable when DNSSEC is in place, and S 3.1 of SVCB recommends > abandoning the connection, just as you ask. > > If DNS responses are cryptographically protected (e.g., using DNSSEC > or TLS [DoT] [DoH]) and SVCB resolution fails due to an > authentication error, SERVFAIL response, transport error, or timeout, > the client SHOULD abandon its attempt to reach the service, even if > the client is SVCB-optional. Otherwise, an active attacker could > mount a downgrade attack by denying the user access to the SvcParams. > > A SERVFAIL error can occur if the domain is DNSSEC-signed, the > recursive resolver is DNSSEC-validating, and the attacker is between > the recursive resolver and the authoritative DNS server. A transport > error or timeout can occur if an active attacker between the client > and the recursive resolver is selectively dropping SVCB queries or > responses, based on their size or other observable patterns. > > If the client enforces DNSSEC validation on A/AAAA responses, it > SHOULD apply the same validation policy to SVCB. Otherwise, an > attacker could defeat the A/AAAA protection by forging SVCB responses > that direct the client to other IP addresses. > > If DNS responses are not cryptographically protected, clients MAY > treat SVCB resolution failure as fatal or nonfatal. > > I do not, however, think that we should have a SHOULD for using DNSSEC > as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU > WON'T)". > > It's worth noting at this point that ECH is a somewhat special case in > that if the attacker is able to observe the DNS request (e.g., if they > are on the local network and secure transport is not used) then much > of the value of ECH is lost, as the attacker learns the DNS name at > resolution time, so it would be appropriate to stress that clients > should use secure transport. > > -Ekr > > > > > >> I think referring to DNS as RFC1034 is a mistake. It would be much better >> to refer to RFC9499 >> >> See Section 7.2.2 >> <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20#section-7.2.2> >> of [ECH <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20>] >> for more details about the public name. >> >> This section does not exist (anymore?). I am not sure what it was trying >> to point to? The public_name text in Section 4 ? >> >> Note that the ECH document defines the public_name as not ending in a >> dot, which technically prevents the root from ever >> using SVCB ECH records. This is probably okay, but I'll raise it again as >> part of the ECH document AD review. >> >> Paul >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- t...@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
