In message <44c21cd9ee514b039eafeafa707a2...@local>, "George Barwood" writes:
>
> ----- Original Message -----
> From: "Patrik Wallstrom" <[email protected]>
> To: "George Barwood" <[email protected]>
> Cc: <[email protected]>
> 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: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
