It’s coming towards the end of 2021 already, which means it’s nearly time again for one of my favourite Internet quirks: A DNSSEC Key Signing Key (KSK) Ceremony, number 43 to be exact.
What is a DNSSEC KSK Ceremony? I covered it in it in detail in this post, but here’s a shorter version:
The domain names we’re all familiar with (like google.com, twitter.com, and so on.) are recorded in and distributed via the Domain Name System (DNS). The DNS is a hierarchy of servers, each responsible for one zone. A zone is essentially a list of information for all the domain names with a given suffix. For example, in the domain name google.com.au, there is the au zone, the com.au zone, and the google.com.au zone.
There’s also the most important zone, the root zone. The root zone is the top of the hierarchy and contains information about all the top-level domains, such as com, net, org, au, xyz, and so on.
From the early days of the Internet until around the 2000s, there was no way to verify the authenticity of DNS data, meaning for example, that anyone between your computer and Google’s DNS servers, could tamper with DNS responses and make you think you were visiting Google, while leading you somewhere else entirely.
Many of the risks caused by this lack of authenticity have now been mitigated via the deployment of encryption standards like TLS, but there are still merits in ensuring DNS data can be authenticated.
Enter Domain Name System Security Extensions, or DNSSEC. DNSSEC allows for a chain of authenticity to be built from any domain name all the way back to the root zone. I won’t go into the specifics of DNSSEC, as I covered it in my earlier series, but the long and short of it is that something needs to be the final ‘anchor’ of this chain of authenticity. This anchor is the Root Key Signing Key (Root KSK).
Because the Root KSK is the anchor of authenticity for the whole of the DNS, it of course needs to be handled both very securely and very transparently, so that the Internet community at large can be sure it is trustworthy. This transparency manifests primarily through quarterly ‘ceremonies’, which are the only times that the Root KSK can be accessed and are when digital signatures for the upcoming three months of DNSSEC operation are generated.
Where did we leave off at the last ceremony?
Before we get to the upcoming Ceremony 43, we’ve got to cover a few details going back to Ceremony 40 in February 2020, which was the last pre-COVID ceremony.
During Ceremony 40, the lock on one of the safes at the California DNSSEC facility wouldn’t open and it took a locksmith around 20 hours to drill it open. Due to the massive delay this caused, one of the scheduled tasks for Ceremony 40, the destruction of a Hardware Security Module (HSM), HSM3, was postponed until the next ceremony scheduled to happen at the California facility, Ceremony 42.
But that would soon go even more pear-shaped with the outbreak of COVID-19 around the world. People travelling from around the globe and gathering in a small room for a few hours was just about the best way to guarantee spread of COVID-19 and would also be difficult or impossible due to travel restrictions. So, ceremonies 41 and 42 were drastically modified to make them as safe as possible.
The main modifications were that most participants participated remotely, both ceremonies were held at the California facility instead of alternating with the Virginia facility, only critical tasks were performed, and nine months’ worth of digital signatures were generated instead of three to allow the ceremonies to happen less frequently.
With all that, HSM3 in California is still currently pending destruction, but that won’t happen at this ceremony either, as now that we’re moving towards COVID-19 normality, Ceremony 43 is being held at the Virginia facility.
Ceremony 43 is happening on Thursday, 14 October (17:00 UTC) at the Virginia DNSSEC facility. It will be the first ceremony to happen there since 39 in November 2019, so hopefully we won’t have any issues with safes having stubborn locks!
Spoiler alert — both safes at the Virginia facility were opened back in June to allow locks and combinations to be changed, so they should (fingers crossed) open fine during the ceremony next week. HSM4 and 5E were also booted up (but not activated/unlocked) to ensure they’re still functioning normally.
Most of the COVID-19 alterations present in Ceremony 41 and 42 won’t be used for Ceremony 43; only the standard three months’ worth of signatures will be generated, and three Crypto Officers (COs) will attend in-person. Participating remotely will be representatives from Verisign, external auditors, and a fourth CO as a backup, who has sent their safe deposit box key to IANA in a tamper-evident bag, as all required COs did for ceremonies 41 and 42.
Besides the standard signature generation, there is one additional task at 43 — the commissioning of a new HSM, designated HSM6E.
You can find the proposed script for the ceremony on IANA’s website, along with records from the Administrative Ceremonies in June when the Virginia safes were last opened.
Cameron Steel is a tech enthusiast with interests in networking and security, particularly in advancing the adoption of IPv6, DNSSEC and HTTPS.
This post was originally published at Cam’s blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.