27th DNS Root Key Ceremony Thumbnail
Building Trust 28 October 2016

27th DNS Root Key Ceremony

By Olaf KolkmanPrincipal - Internet Technology, Policy, and Advocacy

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.

good description of the ceremony is written by Ólafur Guðmundsson. Perhaps you want to skim that post first. You may also want to refer to my previous blog post about the 25thceremony.

As one of the 7 ‘key-holders’ at the east-coast facilities in Culpeper, Virginia, I have two responsibilities:

  1. 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.
  2. 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.

Attestations

Attestation one:

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).

Attestation two:

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:

6cabb3c146aa13fbc9a9d61488b2c6f8c7e9e723a89b8574b0288578a65cc0f5

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.

Attestation three:

The SHA256 over the new root key is:

E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

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.

Attestation four:

The ceremony involved 23 men and no women. That should change.

[Photos courtesy of Olaf Kolkman.]

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related Posts

Building Trust 21 February 2020

NDSS 2020: The Best in Security Research – For the Good of the Internet

On 23 February, the 27th consecutive Network and Distributed System Security Symposium (NDSS) kicks off in San Diego, CA....

Building Trust 11 February 2020

Every Day Should Be Safer Internet Day

Safer Internet Day is an opportunity for people and organizations around the world to join forces in a series...

Building Trust 28 January 2020

This Data Privacy Day It’s the Little Things That Count

Today we’re celebrating Data Privacy Day, which is all about empowering people and organizations to respect privacy, safeguard data,...