Paul, I don't understand your threat model here.
1. As already noted upthread, ECH inherently leaks the name you are resolving to the resolver. This leak doesn't depend on the resolver tampering with the response, so DNSSEC verification on the client doesn't help here [0]. 2. If the client accepts the network resolver, as opposed to requiring a TRR, then a malicious network will always be able to force the user into leaking their browsing history on that network. Thus, as you say, if you want ECH to guarantee privacy you need to use encrypted transport to a TRR. 3. As Ben observed, if the client caches the response from the recursive, then an ECH record from malicious resolver A (e.g., in the airport) might allow A to continue to learn the SNI even when you are using non-malicious resolver B (e.g., at your house). But the only way to get into this hole is to use the network provided (potentially malicious) resolver. 4. The specific attack in (3) can be prevented if the client only cached ECH records when they were DNSSEC signed, but this still leaves you leaking to the malicious network's resolver whenever you try to retrieve an uncached value, so it's much better to just insist on using a TRR, which protects against this attack entirely, at which point DNSSEC provides limited value. If you think this analysis is wrong, please explain the attack which is prevented by client-side DNSSEC validation, remembering that it can only be done reliably when the client already is using a TRR. -Ekr [0] DNSSEC validation at the recursive might help, but that's not what we're talking about. On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters <paul.wout...@aiven.io> wrote: > > On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters <paul.wout...@aiven.io> >> wrote: >> >>> >>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla <e...@rtfm.com> wrote: >>> >>>> This is explicitly prohibited rfc9460 as it would provide linkability. >>>>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is >>>>>> partitioned for each local network, or flushed on network changes, to >>>>>> prevent a local adversary in one network from implanting a forged DNS >>>>>> record that allows them to track users or hinder their connections after >>>>>> they leave that network." >>>>>> >>>>> >>>>> Not if the ECH record is DNSSEC signed. >>>>> >>>> >>>> Except that no browser client does DNSSEC validation and there is no >>>> realistic prospect of that changing. >>>> >>> >>> If you have a TRR configured that does DNSSEC, you can send the DO bit >>> and still have the advantage of the >>> upstream DNSSEC without doing the work in the browser. >>> >> >> If you do encrypted DNS to a TRR, then you're not subject to attack by >> resolvers on the local network, regardless of whether they do DNSSEC. >> > > But still you should verify your trusted resolver where you can. Zerotrust > mentality. > > Of course even better is using RFC 7901 Chain Query and run the few >>> signature validations yourself. It only costs >>> 1RTT, just like a regular DNS lookup. >>> >> >> The issue with local DNSSEC validation isn't primarily performance; it's >> breakage by nonconforming intermediaries. >> > > There are no intermediaries if you connect to proper functioning TRRs > (like 1.1.1.1., 8.8.8.8, 9.9.9.9) > > >> Actually, as I read RFC 7901, the situation is even worse because there >> are going to be valid non-RFC 7901 >> implementing resolvers, and so the attacker -- who, recall, controls the >> local network -- can just refuse >> the discovery process described in S 5.1. >> > > The local network can only block the DoH HTTPS connection to your TRR, > they can't selectively block DNS queries within it. > > I agree with not using locally assigned DNS resolvers (via DHCP or ADD) > for anything if you value privacy. Obviously, DNSSEC > can't help you for privacy here anyway. > > Paul >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
