[ksk-rollover] Plan documents for root KSK roll project now available

[Matt Larson]

On Friday, July 22, in the interests of transparency and to notify the DNS operational community, ICANN posted plans<https://www.icann.org/resources/pages/ksk-rollover#operational-plans> to roll the root zone key signing key (KSK).  These plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator.  The plans incorporate the March 2016 recommendations<https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf> of the Root Zone KSK Rollover Design Team, after it sought and considered public comment<https://www.icann.org/news/announcement-2013-03-08-en> on a proposed rollover process.

The process of creating a new key, using it to sign the root DNSKEY RRset and securely destroying the old key will start in Q4 2016 and last until Q3 2016, though the portions resulting in visible changes in DNS occur between Q3 2016 and Q1 2017.  The important milestones in the project are:

- October 26, 2016: The new KSK is generated in ICANN's U.S. East Coast key management facility (KMF).
- February, 2017: The new KSK is copied to ICANN's U.S. West Coast KMF and is considered operationally ready, and ICANN publishes the new key at https://data.iana.org/root-anchors/root-anchors.xml.  (The exact date is dependent on the timing of the Q1 2017 key ceremony, which has not yet been scheduled.)
- July 11, 2017: The new KSK appears in the root DNSKEY RRset for the first time.
- October 11, 2017: The new KSK signs the root DNSKEY RRset (and the old KSK no longer signs).  This date is the actual KSK rollover.
- January 11, 2018: The old KSK is published as revoked (per RFC 5011, "Automated Updates of DNS Security").

What you need to do

If you operate any software performing DNSSEC validation (such as a security-aware recursive name server) that implements the RFC 5011 automated trust anchor update protocol and this functionality is enabled, you have no action: your software will notice the new KSK (authenticated by the old KSK) and update its trust anchor store accordingly.

If you operate any software performing DNSSEC validation that does not implement RFC 5011 or if you don't use the RFC 5011 protocol, you will need to update your software's trust anchor configuration manually to add the new KSK before October 11, 2017.  You can obtain the new KSK in February, 2017, using one of the methods described in the "Trust Anchor Publication" section of 2017 KSK Rollover Operational Implementation Plan<https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf> (one of the aforementioned recently published plans).

If you write, package or distribute software that performs DNSSEC validation and you hard code the root KSK (e.g., in code or configuration files), you should update your software with the new KSK when it becomes available in February, 2017.

Staying informed

ICANN will post occasional notices to various operational forums to keep the community informed of this project's progress, but we strongly suggest that anyone with an interest subscribe to the root KSK rollover mailing list<https://mm.icann.org/mailman/listinfo/ksk-rollover> operated by ICANN (ksk-rollover at icann.org<mailto:ksk-rollover at icann.org>).  The list is extremely low volume.

The ICANN staff supporting and implementing the root KSK rollover project welcome your questions and comments: please direct them to the ksk-rollover at icann.org<mailto:ksk-rollover at icann.org> list.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20160726/8c549f04/attachment.html>