The 27th DNSSEC root-signing ceremony took place yesterday, on 27 October. This ceremony is special because a new root key has been generated and that will have operational impact for everybody running a secure recursive nameserver. More on that below.
As one of the 7 ‘key-holders’ at the east-coast facilities in Culpeper, Virginia, I have two responsibilities:
- Help open the safe deposit box that contains the smart cards needed to operate or perform maintenance on the hardware-signing machine that contains the actual private root key. There are seven of those safe deposit boxes (tier 7) inside a safe (tier 6), inside a highly secured cage (tier 5) that is in a secured room (tier 4) with dedicated access control gate (tier 3 and tier 2) that lives in a secure and guarded facility (tier 1). At least three key-holders are needed to open at least three safe deposit boxes, to get at least three of those smart cards to access the HSM, which is kept in another safe. There are different sets of people needed to gain access at any tier. The odds that they collude are minimal.
- Witness the whole process and attest publicly to what I’ve seen. This blog post serves as that attestation.
Root Key Rollover
The root keys were generated during ceremony 1 in 2010 and will be replaced for the first time over the next year. The first step of that process happened yesterday: the generation of the new key. It is important for anybody who operates a validating recursive nameserver to verify if their nameserver is configured to support the RFC5011 rollover mechanism. If it doesn’t, you have to pay particularly good care to configure a new trust anchor in Q4 of 2017 when the actual rollover takes place. See ICANN’s KSK rollover web resources for more information.
Alain Aina pressing the key to generate the new root key.
I attest that Root Key Ceremony 27 took place according to the script with only one exception: In step 17, we discovered that the USB keys that needed to be reformatted were not formatted in the first place; the commands in that step (and steps 18-23) were not followed to the letter (no unmount needed before the formatting took place, and a confirming mount and unmounts added after the formatting of the thumb drives).
During Act 2, steps 6-11 of the ceremony, the Operating System DVD was replaced and the old OS DVD copies (release 20160503) where discarded, conform step 11 of the script. I took one of the DVDs and using the MacPorts version of OpenSSL version 1.0.2.H, I verified the SHA256 checksum of the disk. That checksum is exactly the same as the checksum recorded during ceremony 25 – Act 2 – Step 6:
There have been two disks used during the ceremonies; I only took one.
The reasons for the OS replacement were that: the signer needed to be able to deal with the change in the signature validity date on the keyset going to 21 days; the organization unit name in X509 certificates (only used in a CSR that doesn’t go anywhere) was changed from “ICANN/IANA” to “PTI”; there was some software added to perform PGP wordlist checks, and; some minor typos in the audit were fixed. I have not performed any audits or reviews of the code or the changes.
The SHA256 over the new root key is:
The private key still needs to be transferred to the west coast facilities before we can be certain that it will be used to sign the root next year. Only after IANA has published the key is it safe to configure this hash. There are very few circumstances under which the key we generated yesterday will not be used in production; each of those circumstances would be an important exception that would need to be announced and explained in the most transparent way.
The ceremony involved 23 men and no women. That should change.
[Photos courtesy of Olaf Kolkman.]