(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
signature.asc
Description: Message signed with OpenPGP
