[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nanog
Subject:    Root KSK roll delayed
From:       Matt Larson <matt.larson () icann ! org>
Date:       2017-09-28 18:12:47
Message-ID: FFF8EAB1-23DB-4E3F-BE49-1DB61D35DE26 () icann ! org
[Download RAW message or body]

(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" (signature.asc)]

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZzTuaAAoJEDMjmkOGxWHg0KkP/jvNljmFktVhT104/MK2fF6a
lZ+2n3oqn0p+ws4S+LiiHIpc/bcm72+q7UaTRyivB7nY8bTw9IVoa7Pt+R8NQILU
uurKQTTIUsVCrZdGlus1LGrLtcddyeul21gVqzLz8MIvYA6z/DzZyow9X+cn/Pk7
1DrR42fMM/BPP46xsPfaLvxyE9vxJ5ApKE5L51/qfSh4Q6d9S3pbXrzLAjcm31OD
66diTXhE+lqCVPQf1ItUEkZMOc4rm0LXW+ce6jF3zuUlmeeVIfXEjznG2omv4cpI
ypJ6wDDlwsCgYNIGG0ph2xR28jIGlsOeQgY4kUiCAK2ljcI8xjx6WOLjC13wnyni
QsismX3oXvmK/IVisB4A/yX+FR9sxXhqXAnLMvjdffjoaFLtgreRPW2KEU5wEJJG
sPQd3UO7RHCwwgixZqxUFaIMoV5XHXJfBnnBh4HnJkuTlHkmNCm3QucQKVam2qmO
XdGT/CG8HKyfI+Ys4D4YwaWPCcDQnGA4AjSj+5iF5RGGRwlKuCoPkmeOkDuVQc4A
1BJj6VzoUYdWzYNVmawbgI6MiGPNIe3FvOVToMGSdeaHW2+DM49XpQCt6iMqjZnF
qHzGwNBjo79YgfLI/5M/MNrGwUdm9R2MIT//PPzApsFDNDKpFdbyde59OGgt8Ab/
SLXB1PaIKka4VmWWhiuN
=B4cc
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]