Hi, I am against changing the suggestion in Section 4.3.2, even though you provide practices that in one legitimate case DNSKEY is preferred over DS. Such a change would in my opinion have to go through the working group and reach consensus there and I am afraid it is way too late for that. I would not be surprised that after publication, we come up with even more considerations that are also legit and could have been in the incorporated into the document. But at this moment I would not like to discuss changes that delay publication, unless there is detected something fundamentally wrong with the document.
Also note that this is to be an informational RFC, not a BCP. The document is not claiming that one approach is better than the other. It merely provides considerations and provides arguments that can help operators to make a well-thought decision. Best regards, Matthijs On 10/23/2012 01:32 PM, Antoin Verschuren wrote: > On 16-10-12 16:03, Matthijs Mekking wrote: >> Hi all, > >> The document draft-ietf-dnsop-rfc464bis-13 has seen some issues >> while being in AUTH and RCF-EDITOR state. This e-mail will list all >> the suggested changes to address those issues. > > While reading the proposed changes and the whole document again, I > noticed another paragraph that is no longer desired. > My question is that now that we do make some changes, it is advised > that this paragraph is also adjusted to fit current day practices. > > The paragraph is 4.3.2. > The advice in this paragraph, which hasn't changed since 2009 when it > was first written down, has been overtaken by new insight and practices. > It advises registries to store only DS in stead of DNSKEY material in > their database. This has proven to be impractical when deploying > DNSSEC on a large scale: > > 1. Current practice proves that the majority of DNSSEC domains in the > world today is provisioned by sending a DNSKEY record to te registry, > and not DS. Running code for the majority of DNSSEC domains uses DNSKEY. > > 2. The old advice is based on the assumption that less errors are > being made when cutting and pasting a DS in a webinterface or reading > it since it is smaller than a DNSKEY. Current practice today however > is that this is all automated, and while provisioning 1.3 M DNSSEC > domains, we have not seen such errors. > > 3. With more algorithms used for DNSSEC today, and some no longer > advised, registries want to hash the DNSKEY to DS themselves so they > don't need to go through a "contacting every child" nightmare when an > algorithm is no longer supported. The DS is owned by the parent, not > the child. Our practice shows that hashing is a minor operation by the > parent. It takes no real effort whatsoever in computation or time. > > 4. The most important motivation for us to use DNSKEY is consistancy > with new processes that did not exist in 2009. DNSSEC secure transfers > (http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt) > is the most important one. In a DNS-operator change, the operator > initiating the change needs to send his new KSK (DNSKEY/DS) to the > registry AND needs to relay his ZSK (DNSKEY). It is confusing that in > bootstrapping a delegation a DS needs to be sent, but when transfering > a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in > both processes so a child operator is never burdened with calculating > a DS or having to think about 2 different fields in EPP that do not > have the same meaning. So our advise is to use DNSKEY syntax for both > KSK and ZSK when transfering to your parent. > > So my advise is to either delete paragraph 4.3.2 since it is bad > advice (there is no convincing motivation given in this paragraph > anyway), or use the motivation given above to advise for using DNSKEY > over DS. > > If needed, I'm willing to write text. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
