[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
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. This would be fine for preconfigured trusted DNS servers, but I would not trust anything obtained via the ADD protocol as those are network dictated and not user trusted. 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 arguments for not doing this are pretty weak (and if they are not, I'd love to see an explanation in the Security Considerations why to not use a security control other than, "we didn't like how it worked 20 years ago" ) Paul ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
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. > 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. 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. -Ekr ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
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'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] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
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'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] I-D Action: draft-ietf-tls-hybrid-design-11.txt
Internet-Draft draft-ietf-tls-hybrid-design-11.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Hybrid key exchange in TLS 1.3 Authors: Douglas Stebila Scott Fluhrer Shay Gueron Name:draft-ietf-tls-hybrid-design-11.txt Pages: 24 Dates: 2024-10-07 Abstract: Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-11.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-11 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
