----- Original Message ----- From: "Stephen Morris" <sa.morr...@googlemail.com> To: <dnsop@ietf.org> Sent: Thursday, June 30, 2011 3:32 PM Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover
> On 12/06/2011 20:50, George Barwood wrote: >> I have updated the draft >> >> http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt >> >> I have added an appendix with an exampler KSK rollover, and made >> various generally minor changes. >> >> IANA have now assigned type code 59 for the CDS RRtype. >> >> I'd like to request that the WG adopt this document. > > Before calling for adoption of this draft or any other similar proposal, > I think we should step back a minute and take a look at the context. > > There was quite a discussion on the subject of "automatic update of DS > records" in this mailing list during February and March last year (the > thread started by Tony Finch at at > http://www.ietf.org/mail-archive/web/dnsop/current/msg08079.html). I'd like to also reference this thread http://www.ietf.org/mail-archive/web/dnsop/current/msg08424.html which references an earlier requirements document from 2004, that is http://tools.ietf.org/html/draft-ietf-dnsop-key-rollover-requirements-02 I think that requirements document is reasonably clear, and I think the earlier thread indicates a reasonable consensus to move forward with satisfying the requirements. > Early on in the discussion, Ed Lewis said: > > "My concern - if the IETF produces a solution for transferring DS > records in-band to the DNS protocol we will repeat a mistake made in > pushing EPP to Full Standard. Pushing EPP to Full Standard is in itself > a true accomplishment and there is no controversy, the process was > followed faithfully. The problem is, once it was Full Standard it was > found to not be applicable to the general population that it was > designed to serve. The protocol works and is interoperable; the > requirements didn't grow as the use cases grew." > > I agree with Ed and think that we before adopting a solution, we > should step back and ask some basic questions such as: > > 1. Is there a problem? > 2. If so, do we agree on the nature of the problem? > 3. If we agree, is the IETF (and in particular, DNSOP) the place to > develop a solution? > > Last year's discussion thread covered a number of issues: at the risk of > missing ones and losing some of the nuances of the discussion, the ones > that stood out when I reviewed it were: > > * Do we need to automatically update DS records? > Current manual procedures were cited as being error-prone (i.e. people > are less likely to notice a mistake in cutting and pasting a DS record > into a web form than doing the same with an NS record), and there was > the suggestion that DS records are likely to need more frequent updating > than NS records. > > * Who is the target audience? > Should the operator/registrant-registrar-registry ecosystem be the > primary or only target audience or should this approach focus on other > parent/child relationships? I believe it's best to leave out discussion of registrars etc, because I think the problem can be properly solved and standardised in a generalised parent/child model. > > * How should we update DS records? > There was some discussion as to whether the update channel should be > from child zone to parent zone, or whether the update should go through > the registrant->registrar->registry path (or variation thereof). With > the latter, EPP was suggested. > > * If we automatically update DS records, why not NS records? > Delegations are frequently broken - if we have a mechanism for > automatically updating DS records, can we use the same mechanism to > update NS records as well? > > * What sort of security issues will arise? > If you use an in-band (i.e. DNS) solution to transfer information from > the child to the parent, how does it cope if the child zone has been > compromised? Well if the child zone ( the secret keys, I assume you mean) are compromised then all security is lost in any case, and I'm not sure much more can be said. Maybe I'm missing some subtlety here. > * What sort of out-of-band communication should exist between parent and > child zones? > It was felt that some form of non-DNS communication needs to exist > between the operators of the parent and child zones to handle initial > zone configuration and to resolve emergencies and the like. That's true. In general it's necessary to have an out-of-band bootstrap mechanism for initial configuration and for reset if the child private keys are lost. That said, it may be possible to have "insecure/opportunistic" auto-configuration in situations where the child has responsibility to verify the parent data. I leave that open in the draft by saying it is parent policy : If the result is insecure, extra checks MAY be performed according to the parent zone policy. > * Does this raise any issues with regards to transferring secure domains > between registrars? > The problems associated with these types of transfers have been > discussed to great extent elsewhere, but they may have a bearing on the > solution. I think that is a distinct issue, although a general in-band mechanism to update the parent DS RRset may well be useful in that situation. In the draft I focus mainly on key rollover, but algorithm rollover is of course also covered, and any other situations that require changes to the parent DS RRset. > So it seems to me that the first step would be to write a draft that > defines the problem and the requirements for a solution. (The > requirements should include real-world requirements, e.g. how do we > assess the potential bypassing of a registrar in changing registry > data?) Solutions can then be measured against that. > Does this sound a reasonable way for the WG to proceed? Is the earlier requirements draft from 2005 (linked above) substantially incomplete in some way? I think that would be a reasonable basis to measure, I would claim that the CDS record is capable of satisfying the requirements expressed there in a natural way. I also think the requirement is actually fairly clear - when implementing KSK rollover, you reach a point where it's clear that something is needed ( other than asking the operator to start cutting and pasting / interfacing with some out-of-band system / whatever). I doubt another cycle of requirements would be productive - we might be here again in 6 years time! Kind regards, George > Stephen > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
