>From the server operator side, I feel strongly that the multi-CDN example should show a selected CDN setup not a merged CDN setup. The "Automation is required to keep these records consistent with the original records in the CDN providers' zones." mentioned in the current example is outside of the scope of this draft and is not something that I see being operationally viable. Having this example would be worse than having no examples as it provides a misleading perception that this is straightforward, but this is far outside how multi-CDN setups integrate with customers today and is not something that I can see CDN operators being willing to support.
Beyond that it would be helpful to hear from implementers on the client side if these examples help, especially from those who were confused before. Again, see here for the diff (with discussion): https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18/files Erik On Wed, Oct 16, 2024 at 4:54 PM Ben Schwartz <bem...@meta.com> wrote: > 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
