July 2016 - ksk-rollover - lists.icann.org

The risk of miscommunication
by Stephane Bortzmeyer Aug. 2, 2016

Aug. 2, 2016

The Yeti test bed is currently trying a second KSK rollover <https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experi…> and there was a funny incident. A resolver admin, misinterpreting the instructions, updated manually his config with the new key, despite the fact it was still in AddPend state and not used for signing. Since people have a tendency to make mistakes, I suggest to pay extreme attention to the communication and documentation, when explaining sysadmins what to do.

5 5

Plan documents for root KSK roll project now available
by Matt Larson July 26, 2016

July 26, 2016

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-implem…> (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(a)icann.org<mailto:ksk-rollover@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(a)icann.org<mailto:ksk-rollover@icann.org> list. Matt -- Matt Larson VP of Research Office of the CTO, ICANN

1 1

Thoughts on 5011 compliance detection.
by Michael StJohns July 25, 2016

July 25, 2016

Hi - A discussion on 5011 with Wes Hardaker got me thinking about ways of detecting whether or not a client querying the root has 5011 support. 5011 has very definite timing recommendations for queries (section 2.3). I'm wondering if looking at the data sets for queries to the root and the intervals between those queries might reveal the majority of 5011 capable clients? So: 1. Determine the queryInterval and retryTime based on the formulas in 2.3 for the current DNSKEY RRSet. 2. Grab all the queries from all of the root servers that satisfy the characteristic that they were for the DNSKEY RRSet and associated RRSig only along with when they were received. 3. Consolidate them somewhere. 4. Sort and group by query address. 5. Determine the intervals between subsequent queries for each group. 6. Separate the intervals into retryTime periods, queryInterval time periods and non-compliant periods (e.g. everything not within 5% either way of the values calculated in step 1). 7. Score each client based on the proportions of query and retry vs non-compliant periods. 8. Set aside the data sets showing > 20% non-compliance for later analysis. 9. Change one or more of the signature or TTL times in a way that causes a change in the query and retry intervals. 10. Repeat 1-8 again and correlate the results against the first run looking for query patterns that indicate that a client has adapted to the query interval. This may or may not be possible to accomplish given the various demands on Verisign and ICANN, but it might actually glean real data. Its also possible that the Active refresh process is just using data gleaned from normal queries in which case this pattern won't be seen. AFAICT, the current values of original TTL are 2 days, and the value of RRSigExpirationInterval is 14 days. So queryInterval is MAX (1 hour, Min(15 day, 1day, 7 day)) or 1 day. Retry interval is MAX (1 hr, min (1 day, 4.8h, 33.6h)) or 4.8 hours. So finding clients that mostly query the DNSKEY RRSet directly either on a 4.8 hour or 1 day basis might reveal some 5011 clients. Mike

1 0

Fwd: Invitation to "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, in Berlin
by Matt Larson July 9, 2016

July 9, 2016

Hello KSK rollover folks, Please see the message below for information about an upcoming presentation on the root KSK roll during the IETF in Berlin. Matt -- Matt Larson VP of Research Office of the CTO, ICANN Begin forwarded message: From: Matt Larson <matt.larson(a)icann.org<mailto:matt.larson@icann.org>> Subject: Invitation to "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, in Berlin Date: July 8, 2016 at 3:45:03 PM EDT To: <96attendees(a)ietf.org<mailto:96attendees@ietf.org>> Dear IETF colleagues, I'd like to invite anyone interested in DNSSEC in the root zone to a session on "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, from 1230-1345 in the Bellevue Room in the InterContinental Hotel. ICANN and Verisign, as IANA Functions Operator and Root Zone Manager, respectively, are cooperating on two projects that are changing aspects of DNSSEC operation in the root zone: the root zone ZSK is increasing in size from 1024 bits to 2048 bits<http://blogs.verisign.com/blog/entry/increasing_the_strength_of_the> and the root zone KSK will be changing<https://www.icann.org/resources/pages/ksk-rollover>. Duane Wessels from Verisign and I will talk about the plans and answer any questions. Because of the critical nature of the root zone and the significance of these changes, Verisign and ICANN are making a number of presentations to increase awareness. We approached the IAB about a presentation in Berlin and they suggested this lunchtime slot. We'd like to thank the IAB and the Secretariat for graciously offering a room. Thanks and see you in Berlin, Matt -- Matt Larson VP of Research Office of the CTO, ICANN

1 0