See inline; Thanks Antoin or the feedback.
> -----Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin > Verschuren > Sent: Friday, June 16, 2017 1:03 PM > To: Registration Protocols Extensions <regext@ietf.org> > Subject: Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr- > protocol-03.txt > > Dear authors, > > I could finally find some time to make a more thorough personal (chair-hat > off) preliminary review on this document. Thank you > 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? Will fix. > > " 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." It should say "... that allows a third party DNS operator to create, update and remove a DS records for a delegation ..." I think the word "party" differs from "role". A registrant party (entity) can have the DNS Operator role. It's in this context we use the definition. Party/entity not equal to role. > > 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. > I think that's what we're saying, that an entity that like a registrar can have a DNS operator role, we're not saying anything different I think. The third party DNS Operator is an entity that only has one role, the role of DNS operator. > > 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 > I see where you're going, but I'm curious, where are administrative and technical roles and entities defined? I think we want the "third party DNS-operator" to be an acknowledged entity because it's not closely associated to a Registrant, Registrar or Registry entity. > > 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. I believe otherwise, that for domains that cannot use normal RRR channels to bootstrap, an alternate method is required. See "3.5. Acceptance Processing", " SHOULD run a series of tests to ensure that updating the parent zone will not create or exacerbate any problems with the child zone.", and there are various techniques proposed such as ensuring all child name servers respond consistently over TCP. > 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. I disagree. We had tons of arguments on all sides (Registrant, Registrar, Registry, DNS Operator, bad actor) for bootstrapping a domain without a secure administrative channel such as EPP... > > 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. > The proposed restful interface is only specified for CDS records. I doubt we'll ever see this protocol and API with CDNSKEY. If future demand requires the implementation of CDNSKEY support then it can implemented then? > > 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 > > > > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
