On 16 June 2017 at 10:03, Antoin Verschuren <i...@antoin.nl> 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 that a registration entity needs to carefully consider before implementation.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
