Deploy360 10 October 2014

Background Information For The DNSSEC Root KSK Rollover Workshop At ICANN51

By Dan YorkDirector, Internet Technology

ICANN 51 Los AngelesAs I mentioned yesterday, there is a great amount of DNSSEC-related activity happening at ICANN 51 in Los Angeles next week.  One of the new items is the Root KSK Rollover Workshop on Thursday, October 16, 2014, from 9:00-12noon US Pacific time (UTC-7).  This workshop will be accessible remotely from links off of this page:

The point of this session is to publicly discuss what potential impact we see might happen with a change of the Root Key Signing Key (KSK) that is at the heart of the DNSSEC “global chain of trust”. What impacts might there be on people using DNSSEC validation in their daily operations?  And how do we help mitigate those potential issues?

If we change the Root KSK, all the DNSSEC-validating DNS resolvers out there might update their local trust anchors to the new Root KSK and everything will be perfectly fine.  Or… they might not and so when the old Root KSK disappears those DNS resolvers might start failing to return valid DNSSEC-signed records… effectively breaking Internet usage for many people and giving DNSSEC a very bad reputation (and slowing/reducing deployment).  How do we prevent that?

It is a very important discussion!

ICANN Public Consultation

For some background on this whole issue, you can go back to the public consultation ICANN performed about the KSK rollover back in early 2013:

A report summarizing the public comments is available here:

That document also contains the list of “ICANN Recommendations” that were given to the ICANN Board.

The public comments themselves are available individually here:

They include the comments that Andrei Robachevsky and I submitted on behalf of the Internet Society which could effectively be summarized as: we believe the Root KSK should be rolled as soon as possible and as frequently as possible.

SSAC Report

Additionally, SSAC released SAC063 with their advice on DNSSEC Key Rollover in November 2013:

All of these documents  (the comments and the SSAC report) do provide some background information into the views of various people and organizations into the implications of a KSK rollover and also motivation for the views of most that we need to roll the KSK sooner rather than later.

ICANN Board Resolution

I would also note that on November 21, 2013, the ICANN Board adopted a resolution directing ICANN’s President and CEO to evaluate the SSAC advice and provide a recommendation to the board regarding the acceptance of that advice within 90 days:

That process started… but then stalled when the larger “IANA Transition” issue was injected by the NTIA last year.  This workshop next week, as well as the private interop testing, is, in my view, an effort by ICANN’s new CTO, David Conrad, to try to get this effort back on track and make some actions happen.

Going Forward

A key point about this workshop on Thursday, October 16, is that most people are not talking about IF the Root KSK will be rolled, but rather HOW the Root KSK can be rolled most effectively and how we can mitigate any potential issues that arise.  It is also interesting to note that some of the discussion has changed from the need to roll the key for cryptographic/security reasons to talking about the need to change the Root KSK to, for instance, utilize a better and faster encryption algorithm.

Ksk-rollover Mailing List

Much of this discussion is happening on the ksk-rollover mailing list hosted by ICANN. This list is open to the public and anyone can join.  The ksk-rollover list archives provide additional background info for the meeting on Thursday.

This public workshop should be an interesting discussion next Thursday.  I do encourage anyone interested in this important issue to join in and participate.

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

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...