On Wed, 3 Jun 2020, Peter van Dijk wrote:
We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So flags are out. I think it would be simplest to allocate one 'algorithm' number per protocol. This would also allow protocols other than DoT to perhaps use the various DNSKEY/DS fields for different semantics.
I had a discussion with Viktor Dukhovni about the concepts of the draft. We kind of came to the following conclusion: If you need EPP and/or Registry and Registrar support for new things, this is not really going to get deployed at scale. (and we need scale to hide) Syncing between domain owner and nameserver operator for public keys is basically impossible. While it might work manually for one domain, imagine GoDaddy or Cloudflare wanting to change their DoT key. They have to get all their domain DS records updated. We can hope for CDS, but is that realistic? All of the draft (storing DoT signal plus pubkey in DS record) is basically the same as storing this in a TLSA record at the nameserver name, except it saves a few RTTs. But saving those RTTs is really not that important if you do this at the large nameserver hosters, for which a recursive presumbly already has a working DoT connection open because it is serving so many more other domains. It really makes much more sense to signal the capability of nameservers with nameservers, and not with the domains they serve. Then if someone uses ns0.nohats.ca, ns1.cloudflare.com and ns2.godaddy.com, those hosters can all maintain their keys themselves and update their nameservers without needing to inform or get consent from their millions of domain name owners. So we kind of concluded this was a neat hack, but we shouldn't really think it leads to realistic at scale stable deployments. Let's just use TLSA records on the nameservers. It is logically where this information is authoritative for. Paul and Viktor _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
