OK. Erik, Mike, Paul: Let me know if you have any further comments on #18.
--Ben ________________________________ From: Sean Turner <s...@sn3rd.com> Sent: Wednesday, October 16, 2024 3:06 PM To: draft-ietf-tls-svcb-ech.auth...@ietf.org <draft-ietf-tls-svcb-ech.auth...@ietf.org> Cc: dn...@ietf.org WG <dn...@ietf.org>; TLS List <tls@ietf.org> Subject: Re: [TLS] [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech Authors (Ben, Mike, and Eric), Thank for the PR with some examples: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18 Once you’ve settled the debate (hopefully before Monday), please go ahead and merge so that Paul can get the IETF LC started. Cheers, spot > On Oct 9, 2024, at 09:38, Sean Turner <s...@sn3rd.com> wrote: > > 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
