[Opendnssec-user] KSK rollover

[Antoin Verschuren]

Dear Antti,

Although I believe double signatures is a good method for KSK rollovers in theory, I believe it will not become the BCP at registries.
The BCP at registries will become pre-publish, since that's the only method that also allows for NS changes at the time of the rollover, i.e. transfers, or change of dns-operators.

If the dns-operator for a zone changes, the only method where the zone remains secure is when the new public keys are included at the old operator, and signed by the old key only, (since the new private key is not available), and the zone at the new operator only signed with the new private key. (private keys will not be exchanged!).

Since this method will require coordination, multiple DS'es at the parent, and have timing issues, but needs to be deployed at the parent registry anyway, I believe this will be the BCP for regular KSK rollovers as well. No need for a registry to implement different scenarios when pre-publish is a scenario that will work for all situations.

The timing issues and coordination will be integrated in the registry processes, allowing a coordinated rollover to take place.

I believe double signatures should be possible for KSK rollovers in OpenDNSSEC as an option for proprietary scenarios, but I think the default for communication with registries will become pre-publish.

Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschuren at sidn.nl  xmpp:antoin at jabber.sidn.nl  http://www.sidn.nl/



> -----Original Message-----
> From: opendnssec-user-bounces at lists.opendnssec.org [mailto:opendnssec-
> user-bounces at lists.opendnssec.org] On Behalf Of Antti Ristimäki
> Sent: Friday, December 11, 2009 7:41 AM
> To: Rickard Bellgrim
> Cc: opendnssec-user at lists.opendnssec.org
> Subject: Re: [Opendnssec-user] KSK rollover
> 
> 
> On Thu, 2009-12-10 at 16:01 +0200, Rickard Bellgrim wrote:
> 
> > > Still worried about the KSK rollover process...
> > >
> > > I guess that the purpose of the "ksk-roll" command is to tell the
> > > signer
> > > that the new DS record is now uploaded to the parent zone and the
> > > retirement of the old KSK can be started? When tested, it seems that
> > > the
> > > signer replaces the active KSK immediately when the enforcerd runs for
> > > the
> > > next time and the "ksk-roll" command has been given. I tested this by
> > > giving "ksk-roll" command and then "ods-control stop && ods-control
> > > start"
> > > command, which presumably has the same effect as waiting for the
> > > enforcerd run for the next time?
> > >
> > > The problem is that when giving the "ksk-roll" command, the signer
> > > should
> > > wait for the DS TTL before replacing the active KSK - otherwise the
> > > user
> > > must take care that the new DS record has been propagated to resolver
> > > caches. Now the signer signs the DNSKEY RRset with the new KSK even
> > > though the DS TTL has not elapsed. For users, it would be much more
> > > convenient to just tell the signer that the DS record has been
> uploaded
> > > and let the signer take care of the timings.
> >
> > Since we are so close to the release, we will continue with the current
> solution. But we will update the documentation, where we make it clearer
> on what is happening and why. Currently you must only give the ksk-roll
> command when you have seen the new DS out on the nameservers.
> >
> > Version 1.1 will have an option for the type of KSK rollover procedure.
> 
> The possibility to use double signature method for KSK rollovers in
> version 1.1 would be nice.
> 
> The problem with the current ksk-roll command is that it doesn't seem to
> take the parent zone DS TTL into account. Thus, an administrator has to
> first publish the new DS record in the parent zone and then remember to
> wait for the DS TTL before issuing the ksk-roll command. In the current
> solution, the following possibility exists:
> 
> 1. The user initiates the rollover with ods-ksmutil key rollover...
> 2. The user publishes the new DS record in the parent zone
> 3. The user sees the new DS in the parent zone and gives the ksk-roll
> command. The DNSKEY RRset is now signed with only the new KSK.
> 4. A validator has still the old DS in its cache and queries for the
> child zone DNSKEYs. The DNSKEY RRset can't be validated with the old DS.
> 
> This problem does not exist if the user remembers to make sure that the
> DS TTL has elapsed. However, it would be nice if OpenDNSSEC took care of
> this.
> 
> I'm also wondering what the meaning of the DS TTL statement in the
> kasp.xml is, if it's not used by the ksk-roll?
> 
> 
> Antti
> 
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user