Re: [DNSOP] KSK rollover

[Mark Andrews <[e-mail]>]

In message <44C21CD9EE514B039EAFEAFA707A2DA1@local>, "George Barwood" writes:
> 
> ----- Original Message ----- 
> From: "Patrik Wallstrom" <[e-mail]>
> To: "George Barwood" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, May 13, 2010 9:06 AM
> Subject: Re: [DNSOP] KSK rollover
> 
> 
> 
> >On May 13, 2010, at 9:56 AM, George Barwood wrote:
> 
> >> I have been thinking about KSK rollover in my DNSSEC implementation, and i
> t seems
> > that there is currently no  specification for KSK rollover within the DNSSE
> C protocol.
> >> 
> >> There is this expired requirements draft
> >> 
> >> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/
> >> 
> >> but that's all I found.
> >> 
> >> Have I missed something? It seems to me that this is a rather vital compon
> ent if
> >> DNSSEC is to be widely deployed.
> >> 
> >> Are there any plans to revive and/or implement these requirements?
> 
> > You probably want to read the Key Timing Considerations draft:
> > http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02
> 
> That is certainly relevant to rollover, but it doesn't specify any means by
> which the new DS records can be placed in the parent zone.
> 
> http://tools.ietf.org/html/rfc5011 "Automated Updates of DNS Security
> (DNSSEC) Trust Anchors"
> 
> has some relevance, but doesn't provide for parent notification, or for
> publishing a DS record *before* the key is published in the zone, which
> is I think desirable.

	RFC5011 really isn't applicable to this case.
 
> The mechanism that occurs to me is to have a new RRtype, say "CDS", with
> identical format to the DS record, but placed in the child zone ( and 
> signed by the child zone). The parent, at regular intervals, or on
> receiving a notification from the child, would retrieve the contents of
> the CDS RRset, and use it as the new DS RRset ( of course after validating
> it using the old DS RRset ).

	There are lots of way to do this.
	* Use UPDATE to update the delegation records in the parent.
	  This would work today it only requires a willingness to do so.
	  This can be done securely (TSIG) and will scale.
	  UPDATE was designed to support this.
	* Try to guess which keys should have DS's based on SEP bits.
	* Use a different RR type (DLV does this).  poll/notify to
	  incorporate.  (Ed the daily delegation check could do this. :-))
	* Use some epp extension.
	* Use a modified UPDATE which accepts and forwards to the
	  registrar for inclusion in the zone rather than immediately
	  updates the zone.  When a registrar is not involved it is
	  handled as a plain UPDATE.
	* ....

> There probably needs to be consideration of how the system can recover after
> a KSK is compromised, maybe there should be some minimum time interval
> before a new DS record is fully trusted. I have not thought that through.
> 
> Well, that's just my immediate thoughts, there may be a better way.
> 
> I'm somewhat puzzled that thre is no specification, and apparently no
> activity on this.

	There is plenty of activity.  Most of it has been people
	looking at how to fit this into the registry/registrar model
	and worries about patent infringement that are claimed to
	have been filed for some of the above.  I doubt that any
	thing we do in this area is truly novel but the USPO grants
	patents on such trivial things that its become a issue.

	Mark

> KSK rollover is probably a fairly rare event (maybe once every few years), so
> possibly the feeling is that manual procedures will be sufficient. I think a
> standardized, automated in-protocol mechanism would be advisable though.
> Maybe I'm wrong.
> 
> Best regards,
> George
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]