Dear authors, I could finally find some time to make a more thorough personal (chair-hat off) preliminary review on this document. Here are my comments:
First of all, I think everyone knows I’m a big fan of automating DNS provisioning processes and I would very much like this effort to succeed, so thank you to the authors for this attempt. However: Abstract: "When the domain uses DNSSEC it necessary to make regular” Nit: I think the word "is” is missing here? " This document describes a simple protocol that allows a third party DNS operator to update DS records for a delegation, in a trusted manner, without involving the Registrant for each operation. This same protocol can be used by Registrants.” This sounds dubious. Is the registrant involved or not? I would say: " This document describes a simple protocol that allows any DNS-operator to update DS records for a delegation, in a trusted manner, without involving any intermediate administratieve entities between the DNS-operator and the parent.” 1. Introduction: "After a domain has been registered, one of three parties will maintain the DNS zone loaded on the "primary" DNS servers: the Registrant, the Registrar, or a third party DNS operator.” I object to this phrasing, as it suggest an entity performs it’s role as DNS-operator as part of another role he might play. It’s always the DNS-operator and only the DNS-operator that maintains the DNS zone. An entity can act as both registrant AND DNS-operator, registrar AND DNS-operator, or as a standalone DNS-operator, but an entity never maintains a zone in any other role than as DNS-operator. They should be clearly separated to keep roles and entities clearly defined. This whole section need a thorough review on definitions of roles and entities performing multiple roles. 2.1. Definitions: "After a domain has been registered, one of three parties will maintain the DNS zone loaded on the "primary" DNS servers: the Registrant, the Registrar, or a third party DNS operator.” Again, BY DEFINITION a registrar NEVER IS a DNS-operator, and a registrant NEVER IS a DNS-operator. A DNS-operator is a role that may be performed by an entity that ALSO acts in an administrative role as registrar, registrant, or neither. Registrars and registrants are administrative roles, not technical and not entities. The only way to solve this is to make a DNS-operator an administrative role as well, separate from any other RRR role. I can probably help with some text here. Please read section II-B of this whitepaper for inspiration: https://www.sidnlabs.nl/downloads/wp_2013_EPP-keyrelay_v1.en.pdf 3.2 Establishing a Chain of Trust: This is the section where I have most problems with. The bootstrapping of a secure delegation can never be done over an insecure channel such as DNS without a chain of trust for polling the initial key. Unfortunately, I have not followed the discussions for RFC8078, but when I read that now, I think paragraph 3.3 and 3.5 from RFC8078 are a terrible mistake security wise, and a downgrade from previous practice. I believe that insertion of the first key at the parent should always have been over a secure channel, or confirmed over a secure channel, and in the absence of a chain of trust in DNS prior to a secure delegation, the only way to do that is over the secure administrative channel such as EPP or another proven secure channel which DNS without DNSSEC validation is not. I challenge RFC8078 that it probably had too little review from security folks, and I don’t want to make the same mistake here, which makes it even less secure by saying "Once the Registrar sees these records it SHOULD start acceptance processing.” No way. It should never accept a security proof or security inception process over an insecure channel. Also, the introduction of this document only states "Update DS records” which I agree with, but Establishing a Chain of Trust is not updating but bootstrapping. 4.1 Authentication This chapter starts correctly with mentioning of publication of CDS/CDNSKEY records, but continues from section 4.2 onwards only mentioning CDS ignoring explanation what happens with CDNSKEY. Other comments: There are still some sections in this document that contain placeholders for text. In it’s current form, I challenge the intended status of "standards track”. I would say it reads more like a problem statement with it’s proposed processes to solve issues of inconvenience rather than a document that defines a BCP or makes definitions. I’d say there is still work to do, and I can probably help with some definitions, but let’s first start the discussion on what this document wants to define. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
