Re: [DNSOP] CDS RRtype - automated KSK rollover

["George Barwood" <[e-mail]>]

----- Original Message ----- 
From: "Stephen Morris" <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop