Authors (Ben, Mike, and Eric), It looks like we haves some agreement here. There’s some agreement that the PR [1] addresses the concern and there’s some agreement to agree to disagree on other points. Please go ahead and merge the PR [1].
spt [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 > On Oct 8, 2024, at 21:38, Eric Rescorla <e...@rtfm.com> wrote: > > 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 > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
