[Opendnssec-user] KSK rollover issue

Siôn Lloyd sion at nominet.org.uk
Thu May 22 09:45:25 CEST 2014


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 list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20140522/3305a2fa/attachment.html>


More information about the Opendnssec-user mailing list