On Fri, Nov 20, 2020 at 11:47 AM Vladimír Čunát <[email protected]> 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 AAAA, 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 [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
