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 -- t...@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to