Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
> Working group - are there any other comments or review of this document. I am working on a review for this document. I hope to be able to send it tomorrow. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
Matt - do you have an update of the document or to your comments below? Working group - are there any other comments or review of this document. We need additional review before we can go to working group last call. Thanks! Jim On 14 Sep 2017, at 13:36, Matthew Pounsett wrote: On 16 June 2017 at 10:03, Antoin Verschuren wrote: 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: Hi Antoin. My apologies for taking so long to getting around to replying. :) I think we've addressed most of your notes either in Jacques's reply or in the latest update, but I wanted to discuss a couple of things independently. " 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.” I agree that the wording in the current draft is a bit awkward. However, your suggestion isn't quite correct either, since we're expecting this draft to be implemented by registrars in a gTLD environment, and they are not the parent. The intent of the current wording is to point out that this was developed to allow third-party operators to update their customers' DNS without having to involve the customer, but then to also note that advanced registrants who want to automate their own DS updates can also use it (it's not limited to third-party operators). What the API and processes described in the draft really allow is for the registrant or their DNS operator to avoid the *authenticated* web UI of their "Registration Entity", whether that be the registrar or the registry, because nobody implements a way for a regsitrant to add credentials for their DNS operator and we have no reason to expect anyone ever will. Even if they did, there's still a scaling problem for the operator. I'm going to think about a better way to word this paragraph which doesn't encourage the reader to think we're setting up something that is entirely unauthenticated or unvalidated. If you have any other suggestions I'm glad to hear them. 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. Does this work better? After a domain has been registered, the DNS operator for the child zone on the "primary" DNS servers might be the registrant, the registrar, or a third party. 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. I think we're going to have to continue to disagree, here. Not only has 8078 been
Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
On 16 June 2017 at 10:03, Antoin Verschuren wrote: > 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: > Hi Antoin. My apologies for taking so long to getting around to replying. :) I think we've addressed most of your notes either in Jacques's reply or in the latest update, but I wanted to discuss a couple of things independently. " 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.” > I agree that the wording in the current draft is a bit awkward. However, your suggestion isn't quite correct either, since we're expecting this draft to be implemented by registrars in a gTLD environment, and they are not the parent. The intent of the current wording is to point out that this was developed to allow third-party operators to update their customers' DNS without having to involve the customer, but then to also note that advanced registrants who want to automate their own DS updates can also use it (it's not limited to third-party operators). What the API and processes described in the draft really allow is for the registrant or their DNS operator to avoid the *authenticated* web UI of their "Registration Entity", whether that be the registrar or the registry, because nobody implements a way for a regsitrant to add credentials for their DNS operator and we have no reason to expect anyone ever will. Even if they did, there's still a scaling problem for the operator. I'm going to think about a better way to word this paragraph which doesn't encourage the reader to think we're setting up something that is entirely unauthenticated or unvalidated. If you have any other suggestions I'm glad to hear them. > > > 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. > > Does this work better? After a domain has been registered, the DNS operator for the child zone on the "primary" DNS servers might be the registrant, the registrar, or a third party. > 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. > I think we're going to have to continue to disagree, here. Not only has 8078 been published, but there are already registries implementing security bootstrapping via CDS. We've updated the text to be more explicit about this, and I intend to strengthen the security considerations statement more that this is a risk
Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
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 > 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 pro
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. 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.o
[regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions of the IETF. Title : Third Party DNS operator to Registrars/Registries Protocol Authors : Jacques Latour Olafur Gudmundsson Paul Wouters Matthew Pounsett Filename: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt Pages : 14 Date: 2017-03-12 Abstract: There are several problems that arise in the standard Registrant/Registrar/Registry model when the operator of a zone is neither the Registrant nor the Registrar for the delegation. Historically the issues have been minor, and limited to difficulty guiding the Registrant through the initial changes to the NS records for the delegation. As this is usually a one time activity when the operator first takes charge of the zone it has not been treated as a serious issue. When the domain uses DNSSEC it necessary to make regular (sometimes annual) changes to the delegation, updating DS record(s) in order to track KSK rollover. Under the current model this is prone to delays and errors, as the Registrant must participate in updates to DS records. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnsoperator-to-rrr-protocol-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
