I agree that you can't trust a resolver that you only know about from ADD. -Ekr
On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters <paul.wout...@aiven.io> wrote: > 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
