[Opendnssec-user] KSK rollover issue
Emil Natan
shlyoko at gmail.com
Thu May 22 08:57:30 UTC 2014
Hi Siôn,
Thank you very much for the reply. One small detail I missed in my initial
post is that I have manual rollover configured for the KSKs for that
policy. Does it change anything, I mean is that key still marked as
compromised? It should be just regular rollover (and not emergency
rollover) in that case.
Anyway I can share the configuration for that policy in a private message
to help you reproduce the issue. I'm also trying to reproduce it myself and
helpfully understand what exactly happened.
I'm particularly interested in using Stand-by KSK for that zone for one
simple reason. As a TLD zone it takes up to 48 hours to update the DS
records for that zone in the root and having the the hashes for additional
(Stand-by) key already in the root zone can significantly speed up the
process of taking care of certain operational problems.
Emil
On Thu, May 22, 2014 at 10:45 AM, Siôn Lloyd <sion at nominet.org.uk> wrote:
> Hi Emil,
>
> When a key is marked as compromised (i.e. you ask for an out-of-sequence
> rollover) the enforcer tries to get a new key in as quickly as possible. I
> would hazard a guess that because the time to get the standby ready and the
> time to get a brand new key ready are the same it got confused and tried to
> do both? (I'll see if I can reproduce the behaviour you saw.)
>
> The reason it is marked as experimental is two-fold. Firstly it gets less
> testing than other code paths (sorry). Mainly though because the standby
> key will be held in the same HSM as the active key we would have to assume
> that a compromise of one is a compromise of both. So we felt that the
> current implementation of standby keys was not really providing the extra
> security that it could.
>
> Sion
>
>
> On 20/05/14 15:16, Emil Natan wrote:
>
> Hello,
>
> I'm testing the KSK rollover process and got into something I fail to
> understand. For my zone I have one stand-by KSK. Before starting the
> rollover here is how my keys list looked:
>
> ods-ksmutil key list --keytype ksk -v 2> /dev/null
> Keys:
> Zone: Keytype: State: Date of next
> transition (to): Size: Algorithm: CKA_ID:
> Repository: Keytag:
> tld KSK active 2015-06-07
> 18:59:50 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c
> Keyper 62557
> tld KSK dsready When required
> (keypub) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1 Keyper
> 58075
>
> Then I used "ods-ksmutil key rollover --zone tld --keytype KSK" to start
> the KSK rollover process. Here is the keys list after that step:
>
> ods-ksmutil key list --keytype ksk -v 2> /dev/null
> Keys:
> Zone: Keytype: State: Date of next
> transition (to): Size: Algorithm: CKA_ID:
> Repository: Keytag:
> tld KSK publish 2014-05-20
> 19:18:53 (ready) 2048 8 336a0d8ebb714fe38eff8abc3fcd9c98
> Keyper 39757
> tld KSK active 2014-05-20
> 15:13:53 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c
> Keyper 62557
> tld KSK keypublish 2014-05-20
> 19:18:53 (active) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1
> Keyper 58075
>
> Because I'm still testing and try various options, I have restarted the
> ods-enforcerd process and that introduced additional KSK for that zone:
>
> ods-ksmutil key list --keytype ksk --zone tld -v 2> /dev/null
> Keys:
> Zone: Keytype: State: Date of next
> transition (to): Size: Algorithm: CKA_ID:
> Repository: Keytag:
> tld KSK keypublish 2014-05-20
> 19:18:53 (active) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1
> Keyper 58075
> tld KSK publish 2014-05-20
> 19:18:53 (ready) 2048 8 336a0d8ebb714fe38eff8abc3fcd9c98
> Keyper 39757
> tld KSK active 2014-05-20
> 15:13:53 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c
> Keyper 62557
> tld KSK dssub waiting for
> ds-seen (dspub) 2048 8 997358542f04e0f34dcf70d47a5dc22a
> Keyper 18944
>
> What I do not understand is why the key with Keytag 39757 was introduced
> for that zone and why with state "publish"? It looks more like a stand-by
> ZSK which are introduced in "publish" state. When signing the zone 3 KSKs
> are added to the DNSKEY record (62557, 58075, 39757). When creating the DS
> record for that zone, hashes for the following 3 keys are created
> - 62557, 18944, 58075, which actually makes sense. Just for the record, I
> also have stand-by ZSK set in kasp.xml.
>
> The logfile first says:
> May 20 15:26:02 catwoman ods-enforcerd: 1 zone(s) found on policy "TLD"
> May 20 15:26:02 catwoman ods-enforcerd: No new KSKs need to be created.
> May 20 15:26:02 catwoman ods-enforcerd: No new ZSKs need to be created.
> May 20 15:26:02 catwoman ods-enforcerd: Purging keys...
>
> and then:
> May 20 15:26:02 catwoman ods-enforcerd: zonelist filename set to
> /usr/local/ods/etc/opendnssec/zonelist.xml.
> May 20 15:26:02 catwoman ods-enforcerd: Zone tld found.
> May 20 15:26:02 catwoman ods-enforcerd: Policy for tld set to TLD.
> May 20 15:26:02 catwoman ods-enforcerd: Policy TLD found in DB.
> May 20 15:26:02 catwoman ods-enforcerd: Config will be output to
> /usr/local/ods/var/opendnssec/signconf/tld.xml.
> May 20 15:26:02 catwoman ods-enforcerd: KSK key allocation for zone tld: 1
> key(s) allocated
> May 20 15:26:02 catwoman ods-enforcerd: WARNING: KSK rollover for zone
> 'tld' not completed as there are no keys in the 'ready' state;
> ods-enforcerd will try again when it runs next
> May 20 15:26:02 catwoman ods-enforcerd: No change to:
> /usr/local/ods/var/opendnssec/signconf/tld.xml
> May 20 15:26:02 catwoman ods-enforcerd: DSChanged
> ...
>
> ods-ksmutil --version
> opendnssec version 1.4.5
>
> Any ideas what went wrong or what I'm missing?
>
> A comment in the configuration file states that the Stand-by feature is
> experimental? Does it mean it should not be used in production environments?
>
> Thanks.
> Emil
>
>
> _______________________________________________
> Opendnssec-user mailing listOpendnssec-user at lists.opendnssec.orghttps://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>
>
>
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20140522/600a71de/attachment.htm>
More information about the Opendnssec-user
mailing list