On the 27th of April 2017, the 29th DNSSEC root-signing ceremony took place.
A good description of the ceremony is written by Ólafur Guðmundsson. Perhaps you want to skim that blog first, as I will refer to it a few times below. You may also want to refer to my previous blog posts about the 25th, and 27th ceremonies – this blog post is remarkably similar to those because all these ceremonies are remarkably uneventful.
As one of the 7 ‘key-holders’ at the east-coast facilities in Culpeper, Virginia (USA) I have two responsibilities:
1. Help open the safe deposit box that contains smart-cards that are needed to operate or perform maintenance on the hardware signing machine that contains the actual private root key. There are 7 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 inside a secure and guarded facility (tier 1). At least 3 key-holders are needed to open at least 3 safe deposit boxes, to get at least 3 of those smart cards to access the HSM, that 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.
2. Witness the whole process and attest publicly to what I’ve seen. This blog post serves as that attestation.
Attestations
Attestation one: I attest that Root Key Ceremony 29 took place according to the script with no exceptions whatsoever.
Attestation two: During Act 2 of the the ceremony the Operating System DVD was replaced and the old OS DVD copies (release release 20161014 ) were discarded, conform step 11 of the script. I took one of the DVDs and using the macports version of OpenSSL version 1.0.2k verified the SHA256 checksum of the disk. That checksum is exactly the same as the checksum recorded during ceremony 27 – Act 2 – Step 6 and the checksum over the image that has been published for ceremony 27, 28, and 29:
991f7be8cfbc3b4bdb6f5e5f84092486755a08a3c36712e37a26ccd808631692
There have been two disks used during the ceremonies; I only took one.
I make this attestation because having an independent SHA implementation calculate the checksum validates that the checksum on the OS DVD is functioning as expected.
The reason for the OS replacement is that 3-sets of keyset signatures needed to be changed during this ceremony – having to do with the pre-publication of the new key signing key, and possible roll-back scenarios, in addition minor improvements and fixes were made. I have not performed any audits or reviews of the code or the changes. The new OS DVD image is published here.
Root Key rollover
Let me use the opportunity to give a heads up about the root key rollover that is happening this year. If you are responsible for running a DNSSEC enabled recursive name server you must understand that you have to take action and when.
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 in October: the generation of the new key. The hash over that key has been published on the IANA website in February. The SHA256 hash of that key as it would show in the DS record is: E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
You can already configure your recursive name server to validate using that key so that you are future-proof. Just realize it is not yet in production; you MUST NOT remove the anchor that you have currently configured as signatures with the new key will only be generated as of October 2017.
Better just verify if your nameserver is configured to support the RFC5011 rollover mechanism. If it doesn’t you have to still check whether the ‘good thing’ happens. 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.