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 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 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 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 wrote:
>
> On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla 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
