Root KSK roll delayed

[Matt Larson <matt.larson () icann org>]

(Please pardon the repetition if you've seen this message on another list)

ICANN has decided to postpone the root KSK roll previously scheduled for 11 October 2017 for at least one quarter. This 
message gives some background and explanation for that decision.

Historically there has been no way to determine which trust anchors DNSSEC validators have configured, making it 
difficult to assess the potential impact of the root KSK rollover. "Signaling Trust Anchor Knowledge in DNS Security 
Extensions (DNSSEC)" (defined in RFC 8145) is a recent protocol extension that allows a validator to report which trust 
anchors it has configured for a zone to that zone's name servers. The protocol was only finalized in April, 2017, and 
only the most recent versions of BIND (9.10.5b1 and 9.11.0b3 and later) and Unbound (1.6.4 and later) support it. This 
protocol was not expected to have sufficient deployment to provide useful information for the first root KSK rollover.

However, initial research by Verisign and then by ICANN has found a growing number of validators reporting trust anchor 
configuration to the root servers. Based on data from six root server addresses, approximately 12,000 unique source IP 
addresses have sent trust anchor configuration reports so far in September 2017. The number reporting is growing and 
now approaches 1400 unique addresses per day. Significantly, approximately 5% of the total validators and about 6%-8% 
on any given day report only KSK-2010, the root zone KSK currently signing the root's DNSKEY RRset. These validators 
would not resolve correctly after the planned root KSK roll.

There are various reasons a validator might report only KSK-2010. One reason is an old configuration with a statically 
configured trust anchor (e.g., BIND's "trusted-key" statement). ICANN has always known that a small percentage of 
validators would not be ready for the rollover because they had manually configured their trust anchor, and that 
operators of those validators would need to take action when the root KSK rollover happened.

Another reason is a failure to automatically update the trust anchor using the RFC 5011 automated update protocol 
because of a software defect, operator error or other reason. Based on our research and preliminary investigation, we 
also believe it is possible that some operators believe that they are ready for the rollover because they configured 
their validator to use RFC 5011 automated updates, but will not trust KSK-2017 when the rollover happens due to 
configuration issues or software defects.

Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to better 
understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of resolvers 
reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting 
these systems.

Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and 
have proceeded cautiously and without haste. The decision to postpone was taken in that spirit of caution because there 
is no operational pressure to proceed given our continued confidence in the security of KSK-2010.

We appreciate the community's understanding and we look forward to your assistance in gathering the information 
necessary to move forward with the root KSK roll.

Matt
--
Matt Larson, VP of Research
ICANN Office of the CTO

Attachment: signature.asc
Description: Message signed with OpenPGP