I agree with your points. Our only difference of opinion seems to be about how much one should trust a TRR. I still prefer to need to trust them the least possible, meaning I would want DNSSEC validation to at least detect tampering at the TRR. With more ECH deployed, and less visibility of SNI, there will be increase pressure on TRRs to do so.
But this discussion is not really in scope for the ECH SVCB draft, other than that I am concerned about the illusion of ECH privacy being lost because of a "trusted by the network via ADD" resolver being used. Paul On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla <e...@rtfm.com> wrote: > 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
