I've written up adjusted references based on Paul's recommendations [1]. (I haven't deleted the reference to RFC 1034, as I believe it remains the authoritative RFC on what DNS is all about.)
Regarding Section 3.1 of SVCB (RFC 9460) [2], we imagine the client uses DoT to issue AAAA and SVCB queries for the destination domain. The attacker observes each response as an encrypted TLS record. It drops the second one, and all subsequent TLS data. This gives the attacker at least 50/50 odds of dropping only the SVCB response. The client might then observe successful resolution of the AAAA record, and a timeout for the SVCB response. Similar attacks apply to DNSSEC. If the client proceeds with non-SVCB connection, it forfeits the possibility of ECH and reveals the SNI to this attacker. Section 3.1 of SVCB says "don't do that". Instead, ECH-capable clients have to fail hard in this situation. Trusted, DNSSEC-validating resolvers and confidential query transport are important for ECH to achieve its privacy aims. Stub DNSSEC is not helpful for ECH: whether or not they validate DNSSEC, ECH clients must trust their resolver to protect the privacy of their queried names. We could add a recommendation like "Clients using ECH SHOULD select a DNS resolver that they trust to preserve the confidentiality of their queries and return authentic answers, and communicate using an authenticated and confidential transport", but this draft seems like an odd place for that text. --Ben [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/15 [2] https://datatracker.ietf.org/doc/html/rfc9460#section-3.1 ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Monday, September 30, 2024 6:40 AM To: Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org> Cc: draft-ietf-tls-svcb-ech.auth...@ietf.org <draft-ietf-tls-svcb-ech.auth...@ietf.org>; <tls@ietf.org> <tls@ietf.org>; dn...@ietf.org WG <dn...@ietf.org> Subject: Re: [DNSOP] AD review draft-ietf-tls-svcb-ech On Sun, Sep 29, 2024 at 7: 34 PM Paul Wouters <paul. wouters=40aiven. io@ 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 On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org<mailto: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://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc9460/__;!!Bt8RZUm9aw!_bVTIvowMUu2SuVe7KviuiVa81BDfzXfXzxDNEO3Ox5LDst6b59soqeSBEeOO7mUHSFQ$> (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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20*section-7.2.2__;Iw!!Bt8RZUm9aw!_bVTIvowMUu2SuVe7KviuiVa81BDfzXfXzxDNEO3Ox5LDst6b59soqeSBEeOO_45f2Bl$> of [ECH<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20__;!!Bt8RZUm9aw!_bVTIvowMUu2SuVe7KviuiVa81BDfzXfXzxDNEO3Ox5LDst6b59soqeSBEeOO6K_wM_o$>] 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<mailto:dn...@ietf.org> To unsubscribe send an email to dnsop-le...@ietf.org<mailto:dnsop-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
