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 [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
