Re: [dns-privacy] DOTPIN, TLSA, and DiS
On Mon, Nov 23, 2020 at 12:49:25PM +0100, Peter van Dijk wrote: > On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote: > > > > In retrospect I see that what I wrote is very similar to Manu's > > "Do9" except for replacing WebPKI by TLSA, with all their pros > > and cons: > > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > WebPKI has excellent latency properties compared to TLSA. In more > words: a parent-side signal that does not pin keys, but does > authenticate names, would allow WebPKI based DoT with zero extra > queries compared to current non-DoT operations. The WebPKI folks would really hate that, due to the serious ossificiation concerns it would pose to WebPKI. And by history of DNS, those concerns are very much warranted (DNSSEC root key rollover was the most obvious example). There have been number of incidents where non-web use of WebPKI has caused significant headaches for WebPKI folks. On the other side, there are very real concerns about security of WebPKI. Some of the approved validation methods are downright scary. Then security of WebPKI fundamentially based on DNS (despite it managing to collect more single points of failure), so using it in DNS would cause cyclic dependency with non-obvious implications. Then WebPKI can not do service authentication (it is not needed for the Web). Then what should the contents of the trust store be? While in theory, TLS is capable of negotiation here, in practice that does not work (because clients have too many trusted CAs, and servers have no room to manover in). So one would likely get interop issues. Then this would cause issues if there are ever two incompatible transports, e.g., DNS over TLS and TLS over QUIC. The server operators would prefer not to have involve zone owners in what transports they offer. If one has secure capability advertisment from server operators, one could just put the authentication data into that (but there would be some concerns about many queries to various servers, even if the advertisment is just one rrset). If there is DNSSEC, stapling the chain would offer the same latency properties. Of course, that turns out to hit some layer-9 issues to specify (there was draft about that that got kicked out of TLS WG for being too toxic), alongside with above-noted issues with incompatible transports. -Ilari ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DOTPIN, TLSA, and DiS
On Fri, 2020-11-20 at 12:14 -0800, Brian Dickson wrote: > > I think we (the three of us and maybe Tony Finch, if not the whole DNS > community) may be converging on a design that will, I believe, work. This is not the first time that design has been proposed. It is the first time it was not met with only criticism, however! > I just checked on something that was nagging at me: > Is there a way to secure the NS set without requiring the delegated zone to > be signed? > I believe the answer is "yes", at least assuming implementers follow RFC 4035 > correctly. > In section 5.2, the Nth paragraph reads: > " If the validator does not support any of the algorithms listed in an >authenticated DS RRset, then the resolver has no supported >authentication path leading from the parent to the child. The >resolver should treat this case as it would the case of an >authenticated NSEC RRset proving that no DS RRset exists, as >described above." > > So, using a new algorithm for whatever we do, should be 100% backward > compatible. > The assumption is any resolver supporting the new algorithm does so > correctly, and > that any resolver that does not support the new algorithm does the right > thing (treat like unsigned). In early 2019, Knot Resolver and 8.8.8.8 had trouble with this. They've both been fixed a long time ago now. < https://mailarchive.ietf.org/arch/msg/dns-privacy/HiqLSzeWRgwseOh6JiNBkScSq_o/ > > This means the design can be as simple as "put stuff in an apex DNSKEY record > with a new algorithm)", > plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the > parent zone, is sufficient. > Note that for TLDs, the mechanism for this would be EPP sending of DS (or > DNSKEY), and/or using > the CDS/CDNSKEY mechanisms. Yes - I don't think the data functionally needs to even appear in the child's apex DNSKEY, it just needs a delivery mechanism into the parent. (In DiS, the delivery mechanism is "the parent's zone signer software"; that would just leave open the question of delivering the policy flag that Vladimir mentioned). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DOTPIN, TLSA, and DiS
On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote: > On 11/19/20 2:05 PM, Peter van Dijk wrote: > > 1. auth operators publish TLSA records for their NSes > > 2. the registry, while generating zone files, queries for those TLSA records > > 3. from the found TLSA records, the registry generates DOTPIN DSes > > 4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, > > and perhaps the DiS > > Intriguing but isn't it unnecessarily complicated? Yes, it is complicated. It is an exercise in ticking -all- the boxes (incremental deployment, low latency, scalable management) - by moving all the pain into the registry operation. > If we assume that > DiS-like is possible, I'd rather replace the DOTPIN-related parts by > some simple flag that tells if the zone's policy is to avoid cleartext. > > I.e., in comparison with today, the parent side would additionally sign: > (a) the NS set - e.g. via DiS; that's because signing certs directly has > those scalability issues > (b) and this "policy flag" in some way (say, yet another DS alg like > DiS, but there are other ways). Yes, I believe (and have said before) that this is how a TLSA-based deployment would make sense. > In retrospect I see that what I wrote is very similar to Manu's "Do9" > except for replacing WebPKI by TLSA, with all their pros and cons: > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 WebPKI has excellent latency properties compared to TLSA. In more words: a parent-side signal that does not pin keys, but does authenticate names, would allow WebPKI based DoT with zero extra queries compared to current non-DoT operations. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DOTPIN, TLSA, and DiS
On 11/20/20 9:14 PM, Brian Dickson wrote: > So, using a new algorithm for whatever we do, should be 100% backward > compatible. Yes, it should be. A few different proposals have been relying on that already, for DS or DNSKEY. It is possible that some validators still have bugs around this, but hopefully they would be manageable. For signers there's a possible caveat that a zone must be fully signed by *all* the present DNSKEY algorithms, but my point of view is that redefining that it relatively easy on deployment (as only zones wanting the feature get affected). See last paragraph of https://tools.ietf.org/html/rfc4035#section-2.2 > I think we (the three of us and maybe Tony Finch, if not the whole DNS > community) may be converging on a design that will, I believe, work. So far I can't clearly see that direction of convergence, but I'll be looking forward to such design proposals. --Vladimir ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DOTPIN, TLSA, and DiS
On Fri, Nov 20, 2020 at 11:47 AM Vladimír Čunát wrote: > On 11/19/20 2:05 PM, Peter van Dijk wrote: > > 1. auth operators publish TLSA records for their NSes > > 2. the registry, while generating zone files, queries for those TLSA > records > > 3. from the found TLSA records, the registry generates DOTPIN DSes > > 4. the DOTPIN DSes are published alongside the domain owner's NSes, > DSes, and perhaps the DiS > > Intriguing but isn't it unnecessarily complicated? If we assume that > DiS-like is possible, I'd rather replace the DOTPIN-related parts by > some simple flag that tells if the zone's policy is to avoid cleartext. > > I.e., in comparison with today, the parent side would additionally sign: > (a) the NS set - e.g. via DiS; that's because signing certs directly has > those scalability issues > (b) and this "policy flag" in some way (say, yet another DS alg like > DiS, but there are other ways). > The reasons are that I believe we want a possibility of downgrade > resistance. > > More details: the rest of the trust chain could be TLSA or something > similar on those NSs, looked up separately by a supporting resolver, > assuming these can again be DNSSEC-validated (for now let me avoid > trying to define the case when they can't). Maybe this "policy flag" > could be more than binary, too, e.g. allowing to indicate that the NSs > may support DoT but it's OK if the supporting resolver isn't strict - > and a third case might mean that resolvers shouldn't even attempt a > secure transport (as optimization). Of course, it's still not as nice > as I'd like it (but maybe no perfect solution exists anyway), e.g.: > - the TLSA lookup would add latency (at least I expect its TTL high > enough to amortize for larger NSs), and > - there are edge cases like privacy being hard for zones containing > those TLSA records (circular dependencies; I expect we can sacrifice > privacy of those TLSAs at least), and > - it again assumes abusing DS - that's avoidable in theory but it may be > too difficult to make the parent-side sign and return the necessary > information in other ways (soon-ish). > > In retrospect I see that what I wrote is very similar to Manu's "Do9" > except for replacing WebPKI by TLSA, with all their pros and cons: > > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > I think we (the three of us and maybe Tony Finch, if not the whole DNS community) may be converging on a design that will, I believe, work. I just checked on something that was nagging at me: Is there a way to secure the NS set without requiring the delegated zone to be signed? I believe the answer is "yes", at least assuming implementers follow RFC 4035 correctly. In section 5.2, the Nth paragraph reads: " If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above." So, using a new algorithm for whatever we do, should be 100% backward compatible. The assumption is any resolver supporting the new algorithm does so correctly, and that any resolver that does not support the new algorithm does the right thing (treat like unsigned). This means the design can be as simple as "put stuff in an apex DNSKEY record with a new algorithm)", plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the parent zone, is sufficient. Note that for TLDs, the mechanism for this would be EPP sending of DS (or DNSKEY), and/or using the CDS/CDNSKEY mechanisms. There is likely use cases for separate new algorithms for protected delegation items NS, A, and , all of which would be non-authoritative (and thus not signed by the parent, but if encoded this way in a DNSKEY, hashed as a DS, and signed indirectly by the parent, achieve equivalency on protection). Time to test some stuff and do some POC coding, and collaborate on a draft with some folks. Yay! Brian ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DOTPIN, TLSA, and DiS
On 11/19/20 2:05 PM, Peter van Dijk wrote: > 1. auth operators publish TLSA records for their NSes > 2. the registry, while generating zone files, queries for those TLSA records > 3. from the found TLSA records, the registry generates DOTPIN DSes > 4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and > perhaps the DiS Intriguing but isn't it unnecessarily complicated? If we assume that DiS-like is possible, I'd rather replace the DOTPIN-related parts by some simple flag that tells if the zone's policy is to avoid cleartext. I.e., in comparison with today, the parent side would additionally sign: (a) the NS set - e.g. via DiS; that's because signing certs directly has those scalability issues (b) and this "policy flag" in some way (say, yet another DS alg like DiS, but there are other ways). The reasons are that I believe we want a possibility of downgrade resistance. More details: the rest of the trust chain could be TLSA or something similar on those NSs, looked up separately by a supporting resolver, assuming these can again be DNSSEC-validated (for now let me avoid trying to define the case when they can't). Maybe this "policy flag" could be more than binary, too, e.g. allowing to indicate that the NSs may support DoT but it's OK if the supporting resolver isn't strict - and a third case might mean that resolvers shouldn't even attempt a secure transport (as optimization). Of course, it's still not as nice as I'd like it (but maybe no perfect solution exists anyway), e.g.: - the TLSA lookup would add latency (at least I expect its TTL high enough to amortize for larger NSs), and - there are edge cases like privacy being hard for zones containing those TLSA records (circular dependencies; I expect we can sacrifice privacy of those TLSAs at least), and - it again assumes abusing DS - that's avoidable in theory but it may be too difficult to make the parent-side sign and return the necessary information in other ways (soon-ish). In retrospect I see that what I wrote is very similar to Manu's "Do9" except for replacing WebPKI by TLSA, with all their pros and cons: https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 --Vladimir ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
