Hi all, So, there is a project underway to roll the DNSSEC root key. There has been much written about this, including SAC063 (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a DNSSEC Root KSK Rollover Plan Design Team, various consultations with the community, many presentations at DNS-OARCs, etc.
One of the biggest impediments to actually performing the rollover is that some set of folk will not have performed RFC5011 style rollover, whether because their software doesn't support 5011, because they have statically configured a TA, because the bigger response makes them sad, whatever. The fact that we cannot tell who has only has the old key, and who has both makes the keyroll very scary - we cannot predict who, and how wide scale the outage will be when the old key is removed. I've written a draft that proposes a different way of performing root key rollover that exposes who all has which key - this allows one to know that 99.8% of resolvers have the new key, who has the old one, and who will break. It does this by encoding the current set of TAs that the resolver has into a query, and using that to fetch the new keys. By watching queries at the root one can see the population of people with each TA, and watch that change over time. This was written for root key roll, but is applicable to any TA in the tree. I'd appreciate any feedback, the draft announcment is here: Name: draft-wkumari-dnsop-trust-management Revision: 00 Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors Document date: 2015-06-29 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt Status: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ Htmlized: https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 Abstract: This document describes a simple means for automated updating of DNSSEC trust anchors. This mechanism allows the trust anchor maintainer to monitor the progress of the migration to the new trust anchor, and so predict the effect before decommissioning the existing trust anchor. It is primarily aimed at the root DNSSEC trust anchor, but should be applicable to trust anchors elsewhere in the DNS as well. [ Ed note - informal summary: One of the big issues with rolling the root key is that it is unclear who all is using RFC5011, who all has successfully fetched and installed the new key, and, most importantly, who all will die when the old key is revoked. A secondary problem is that the response sizes suddenly increase, potentially blowing the MTU limit. This document describes a method that is basically CDS, but for the root key (or any other trust anchor). Unlike the CDS record though, this record lives at a special name - by querying for this name, the recursive exposes its list of TAs to the auth server (signalling upstream) . This allows the TA maintainer to predict how many, and who all will break. It also allows the pre-publication of a key before using it, and so avoids the need to double response sizes...] [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.] [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ] W [0]: Full disclosure: Author. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
