<div dir="ltr">Hi Siôn,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Emil</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 22, 2014 at 10:45 AM, Siôn Lloyd <span dir="ltr"><<a href="mailto:sion@nominet.org.uk" target="_blank">sion@nominet.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Emil,<br>
<br>
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.)<br>
<br>
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.<br>
<br>
Sion<div><div class="h5"><br>
<br>
On 20/05/14 15:16, Emil Natan wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hello,
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<div>ods-ksmutil key list --keytype ksk -v 2> /dev/null</div>
<div>Keys:</div>
<div>Zone: Keytype: State:
Date of next transition (to): Size: Algorithm: CKA_ID:
Repository:
Keytag:</div>
<div>tld KSK active
2015-06-07 18:59:50 (retire) 2048 8
a2b2155affee6c67ec546222443bb35c Keyper
62557</div>
<div>tld KSK dsready
When required (keypub) 2048 8
a0ad6883be22eb83506f6eed1ad01ab1 Keyper
58075</div>
</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<div>ods-ksmutil key list --keytype ksk -v 2> /dev/null</div>
<div>Keys:</div>
<div>Zone: Keytype: State:
Date of next transition (to): Size: Algorithm: CKA_ID:
Repository:
Keytag:</div>
<div>tld KSK publish
2014-05-20 19:18:53 (ready) 2048 8
336a0d8ebb714fe38eff8abc3fcd9c98 Keyper
39757</div>
<div>tld KSK active
2014-05-20 15:13:53 (retire) 2048 8
a2b2155affee6c67ec546222443bb35c Keyper
62557</div>
<div>tld KSK keypublish
2014-05-20 19:18:53 (active) 2048 8
a0ad6883be22eb83506f6eed1ad01ab1 Keyper
58075</div>
</div>
<div><br>
</div>
<div>Because I'm still testing and try various options, I have
restarted the ods-enforcerd process and that introduced
additional KSK for that zone:</div>
<div><br>
</div>
<div>
<div>ods-ksmutil key list --keytype ksk --zone tld -v 2>
/dev/null</div>
<div>Keys:</div>
<div>Zone: Keytype: State:
Date of next transition (to): Size: Algorithm: CKA_ID:
Repository:
Keytag:</div>
<div>tld KSK keypublish
2014-05-20 19:18:53 (active) 2048 8
a0ad6883be22eb83506f6eed1ad01ab1 Keyper
58075</div>
<div>tld KSK publish
2014-05-20 19:18:53 (ready) 2048 8
336a0d8ebb714fe38eff8abc3fcd9c98 Keyper
39757</div>
<div>tld KSK active
2014-05-20 15:13:53 (retire) 2048 8
a2b2155affee6c67ec546222443bb35c Keyper
62557</div>
<div>tld KSK dssub
waiting for ds-seen (dspub) 2048 8
997358542f04e0f34dcf70d47a5dc22a Keyper
18944</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The logfile first says:</div>
<div>
<div>May 20 15:26:02 catwoman ods-enforcerd: 1 zone(s) found
on policy "TLD"</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: No new KSKs need
to be created.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: No new ZSKs need
to be created.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: Purging keys...</div>
</div>
<div><br>
</div>
<div>and then:</div>
<div>
<div>May 20 15:26:02 catwoman ods-enforcerd: zonelist filename
set to /usr/local/ods/etc/opendnssec/zonelist.xml.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: Zone tld found.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: Policy for tld
set to TLD.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: Policy TLD found
in DB.</div>
<div>
May 20 15:26:02 catwoman ods-enforcerd: Config will be
output to /usr/local/ods/var/opendnssec/signconf/tld.xml.</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: KSK key
allocation for zone tld: 1 key(s) allocated</div>
<div>
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</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: No change to:
/usr/local/ods/var/opendnssec/signconf/tld.xml</div>
<div>May 20 15:26:02 catwoman ods-enforcerd: DSChanged</div>
</div>
<div>...</div>
<div><br>
</div>
<div>
<div>ods-ksmutil --version</div>
<div>opendnssec version 1.4.5</div>
</div>
<div><br>
</div>
<div>Any ideas what went wrong or what I'm missing?</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Thanks.</div>
<div>Emil</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Opendnssec-user mailing list
<a href="mailto:Opendnssec-user@lists.opendnssec.org" target="_blank">Opendnssec-user@lists.opendnssec.org</a>
<a href="https://lists.opendnssec.org/mailman/listinfo/opendnssec-user" target="_blank">https://lists.opendnssec.org/mailman/listinfo/opendnssec-user</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Opendnssec-user mailing list<br>
<a href="mailto:Opendnssec-user@lists.opendnssec.org">Opendnssec-user@lists.opendnssec.org</a><br>
<a href="https://lists.opendnssec.org/mailman/listinfo/opendnssec-user" target="_blank">https://lists.opendnssec.org/mailman/listinfo/opendnssec-user</a><br>
<br></blockquote></div><br></div>