> 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.
i don't believe that this working group, or the ietf as a whole, ought to make a recommendation of this kind. ECH will be widely nonfunctional due to enterprise, family, and personal filtering. preventing an endpoint from seeing the ECH metadata in DNS may be a secure edge network operator's chosen method of avoiding errors that would otherwise affect their local end users. see also: https://www.linkedin.com/feed/update/urn:li:activity:7246554223226560512/ note, i'm not asking for balance of political views to be expressed in the document. rather, i'm asking that no political view be expressed in the document, but my fallback will be to prevent a balance of political views to be expressed if any political view at all is expressed. -- P Vixie On Monday, September 30, 2024 3:40:44 AM PDT Eric Rescorla 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 -- dn...@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
