- ksk-rollover - lists.icann.org

[ksk-change] Action #4 - Review Joe Abley's Internet Drafts
by Dan York Oct. 18, 2014

Oct. 18, 2014

Action #4 - There was discussion of two Internet-Drafts that Joe Abley has submitted: DNSSEC Trust Anchor Publication for the Root Zone https://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-10 Establishing an Appropriate Root Zone DNSSEC Trust Anchor at Startup http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 (expired back in 2011) There are actually two actions here: 1. Joe is going to re-circulate these drafts on relevant IETF lists (and presumably update the 2nd one). 2. Everyone is urged to review these drafts and send comments/feedback to the DNSOP mailing list (if you are subscribed) or directly to Joe (if you are not). PLEASE DO REVIEW THESE DOCUMENTS AND SEND COMMENTS! Separately, during the meeting Kumar Ashutosh from Microsoft indicated that they have implemented Joe's draft. Benno Overeinder from NLNet Labs indicated that Unbound implements this draft. Jakob asked on the list if there are any other implementations. (Please send comments to this ksk-rollover list.) Thanks, Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

4 4

[ksk-change] Roll back
by Michael StJohns Oct. 17, 2014

Oct. 17, 2014

Hi - For the purposes of this message, I'm assuming we're talking not about placing a removed non-revoked key back into service, but placing a revoked key back into service. The way 5011 works is that there's a remove hold down time for the trust anchor database at a resolver. It's there to allow the resolver to purge old data after its no longer valid. Revoking a trust anchor both removes the key from the trust anchor set and makes it useless for signing things. At the completion of the remove hold down time, say the resolver purges all knowledge of the trust anchor key, and then say the resolver sees something signed by that key. Since the key isn't affirmatively a trust anchor key, a chain of trust can't be traced from it. A zone owner *could* place it back into service as a trust anchor, but would have to go through the same process it uses to add any other trust anchor key. Not a good idea, but also not really a threat surface. Mike

1 0

[ksk-change] Monolithism considered harmful...
by Michael StJohns Oct. 17, 2014

Oct. 17, 2014

Hi - I'm noticing some issues with terminology that are tending to make discussion about the topic difficult. For example " rollover" is actually the monolithic combination of a number of discrete actions. Let me suggest we try hard to talk about the discrete actions rather than "rollover" as it will make our life a bit easier in figuring out timing, resources and plans. Here's my break down. This assumes that we eventually get to a steady state of at least two trust anchors; that 5011 is used; and that the other mechanisms have sufficient assurances to them that providing them does not adversely affect the security model for DNSSEC. Note that nowhere below discusses the time lines necessary for the discrete actions due to the current root signing processes (eg scheduling and travel time). Trust anchor actions (from zone owner point of view): add trust anchor generate a key pair publish via 5011 format the trust point DNSKEY RRSet sign the trust point DNSKEY RRSet with an existing trust anchor private key publish the signed DNSKEY RRSet via DNS for twice the add hold down period publish via ICANN web page format the XML trust anchor record update the web page publicize the update (for those doing manual updates) publish via software vendors sign the new trust anchor set with an as yet to be determined ICANN credential send trust anchor set to vendors publicize the update and participating vendors publicize the update and participating vendors publicize the update and participating vendors publicize the update and participating vendors return to normal signing policies (e.g. 1 key signs DNSKEY RRSet, stand by key(s) present or not present) after a minimum of twice the add hold down time; additional time may be needed to allow keys to propogate through vendor and manual processes. revoke trust anchor set revoke bit on key to be revoked format the trust point DNSKEY RRSet sign the trust point DNSKEY RRSet with both a still valid trust anchor key and the private key being revoked publish the signed DNSKEY RRSet via DNS for twice the remove hold down period or longer. update the ICANN web page list of trust anchors update the signed trust anchor set for vendors send the updated signed trust anchor set to the vendors publicize the revocation [[ level of effort for this action depends on whether revocation was due to compromise or routine supercession actions]] supercede a key [ two stage] add a trust anchor wait for completion of add revoke an old trust anchor return to normal signing procedures after twice the removal time emergency revocation without immediate supercession (assumes 2 or more keys, of which at least N-1 keys are not compromised) [[ Same actions as "revoke trust anchor"]] [[ In the model below, for non emergency supercessions, the publish to the icann web page and publish to the vendor channel can be moved ahead of 5011 in the time line and a delay imposed between. However, the semantics which describe the TA (icann xml, signed TAs for vendors) will need to be rich enough to describe future events as the revocation won't necessarily have occurred when the update data reaches the end user; there's also the question of what happens if a compromise occurs between the ICANN/Vendor publish and the effective date]] supercede a key [ one stage ] aka emergency or non-emergency revocation with immediate supercession (assumes 1 compromised or superceded key and at least 1 non compromised key, can scale to more than 1 compromised key) generate a key pair set revoke bit on key to be revoked publish via 5011 format the trust point DNSKEY RRSet to include both revoked key and new public key sign the trust point DNSKEY RRSet with both the revoked key and a different valid trust anchor private key publish the signed DNSKEY RRSet via DNS for the greater of twice the hold down period or twice the removal period publish via the ICANN web page format the XML trust anchor object to add the new trust anchor and remove the old publish the new object on the ICANN web page publicize the change publish via the Vendor channel sign the revised trust anchor set send the signed set to the participating vendors have them publicize to their own customers (customers will have also seen the above announcement). return to normal signing procedures after the greater of twice the hold down period or twice the removal period; can be extended to allow for more time for completion of web page and vendor channel updates. trust reboot [compromise] [[ publicize the compromise - may be deferred if impact assessment dictates]] generate new key pairs publish via the ICANN web page format the XML trust anchor object (containing only the new trust anchors) publish the new object on the ICANN web page publish via the vendor channel sign the revised trust anchor set (containing only the new trust anchors) send the signed set to the participating vendors wait 30 days publicize the compromise and updates wait 60 more days revoke all the compromised trust anchors via 5011 root DNSKEY RRSet will include old trust anchors as well as new trust anchor and will be signed by new trust anchor as well as old. wait twice the remove hold down time resume normal signing procedures trust reboot [ routine ] generate new key pairs do 5011 add of the new trust anchors publish via the ICANN web page format the XML trust anchor object (containing old AND new trust anchors) publish the new object on the ICANN web page publish via the vendor channel sign the revised trust anchor set (containing old AND new trust anchors) send the signed set to the participating vendors publicize the compromise and updates wait 60 days at least revoke all the old trust anchors via 5011 wait twice the remove hold down time resume normal signing procedures

1 0

[ksk-change] Web page / site (Github repo?) to list tools available for testing Root KSK Rollover...
by Dan York Oct. 16, 2014

Oct. 16, 2014

As I was writing that email about the action of creating tools for testing Root KSK Rollover, it occurred to me that it would also be helpful if we had a page that pointed to some of the tools that are being developed such as: ------ Warren Kumari: http://keyroll.systems/ Jakob Schlyter's keyroller demo scripts: https://github.com/jschlyter/keyroll/ Benno Overeinder / NLNet Labs: http://unbound.net/documentation/unbound-anchor.html http://www.unbound.net/documentation/howto_anchor.html ------ It would also be useful if this could be an *easily* editable page by members of this group of people working on tools so that people could update the page with info about their tool when they make updates. So... it occurs to me: 1. Should "someone" set up a Github repo where we could either have a markdown page in the main repo or use a Github Page? (Perhaps have ICANN do this with their Github account?) That way anyone interested in editing the page could be added to the team associated with the Github repo. (or fork the repo and send a pull request) 2. If people don't want to use a Github repo, should "someone" set up a page or a wiki somewhere that could contain these links and be editable by others? 3. Or is there some other solution that's so obvious I'm missing it? I could certainly throw up a page on the Deploy360 website... and would be glad to do so if we have no other options, but the only detail is I can't easily give people editing capability and that would leave *me* being the bottleneck. I'd also be glad to set up a repo using my own Github account (as would probably any number of us)... but it seems to me that it might make more sense to have this hosted off of ICANN's "organization" on Github (unless there are policies or issues with doing that). Comments? Thoughts? Brilliant ideas? Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

1 0

[ksk-change] Action #1 - Creation of testing/interop tools
by Dan York Oct. 16, 2014

Oct. 16, 2014

Action #1 - There was discussion that we need to have tools that will allow people to test their applications and services to ensure that they would work in a Root KSK Rollover situation. There was (naturally, given the crowd) a great interest in developing tools. I recorded the following people having interest: Warren, Duane, Ralf, Rick, Evan Sebastian, Olafur. Q FOR LIST: Anyone else interested in working on tools? We unfortunately did not identify a person during the session to take the lead on helping us figure out what we need for "tools" and to "coordinate" (for some definition of that word) the tools effort. ANYONE INTERESTED IN VOLUNTEERING TO BE THE LEAD? I think it would be helpful to have "someone" as the main point of contact particularly if we are successful in getting more people interested in the process. Regards, Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

1 0

[ksk-change] Actions coming out of ICANN 51 Root KSK Rollover Public Workshop - Oct 16, 2014
by Dan York Oct. 16, 2014

Oct. 16, 2014

List members, Coming out of today's Public Workshop at ICANN 51 in L.A., I recorded these actions: 1. Creation of testing/interop tools 2. Creation of a document 3. Workshop at ICANN 52 4. Review of Joe Abley's Internet Drafts In an effort to be clear and to help identify who else might be interested in helping, I'm going to send out four separate email messages about each of these actions. If I missed any actions, please let me know. Regards, Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

1 0

[ksk-change] tools for ksk rollover
by Benno Overeinder Oct. 16, 2014

Oct. 16, 2014

Related to the discussion in the room wrt. tools for implementation of Joe's draft. unbound-anchor implements that draft from Joe and includes an ICANN certificate with which it validates. See http://unbound.net/documentation/unbound-anchor.html and http://www.unbound.net/documentation/howto_anchor.html. Cheers, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

2 1

[ksk-change] Write up of key rollover experience
by Geoff Huston Oct. 16, 2014

Oct. 16, 2014

http://www.potaroo.net/ispcol/2010-02/rollover.html This is a writeup of the consequences of key rollover at the time when the in-addr zone operate with an unsigned root and without 5011 support. (Obviously a signed root has largely addressed this situation.) At the time there was a degree of reliance of various forms of out of band key distribution, which may have some relevance to the root key roll. Anyway, in response to a request for write ups of previous key roll experience, this is one. Geoff

1 0

[ksk-change] Promoting remote participation in today's ICANN 51 workshop
by Dan York Oct. 16, 2014

Oct. 16, 2014

FYI, to help potentially promote more remote participation in today's public workshop, I put out the following post this morning: http://www.internetsociety.org/deploy360/blog/2014/10/root-dnssec-ksk-rollo… (with a shortened URL of http://wp.me/p4eijv-5lj <http://wp.me/p4eijv-5lj> ) Feel free to pass that link along to anyone you know who might be interested. Please note that while the page on the ICANN 51 site *has* been updated - http://la51.icann.org/en/schedule/thu-dnssec-key-rollover - it now lists the times as 9:30-13:30. The plan as far as I know it is still to start at 9:00am after the SSAC Public Meeting ends and aim to finish up by noon. We do, though, have the room until 13:30 if we wish to continue discussions. Talk to many of you soon, Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

2 1

[ksk-change] Agenda and timeline for Root KSK Public Workshop on Thursday at ICANN 51
by Dan York Oct. 15, 2014

Oct. 15, 2014

List members, On behalf of the ad hoc program committee[1], I want to relay some information about the Root KSK Public Workshop on Thursday, October 16, 2014 here at ICANN 51 in L.A. LOCATION and TIME --------------------------------- The meeting will be on Thursday, October 16, 2014, from 9:00am - 12:00noon PDT (UTC-7). It will NOT be 0800-1800 as currently shown on the ICANN calendar. Location is the Brentwood Room on the lower California level. REMOTE PARTICIPATION --------------------------------- Remote participation information at: http://la51.icann.org/en/schedule/thu-dnssec-key-rollover AGENDA --------------------------------- The public workshop is aimed to be a discussion forum to collect guidance from a wide range of people. I have been asked to act as a moderator to ensure that the flow moves appropriately and that all get to contribute. The proposed agenda is: 1. INTRODUCTION A brief level setting of why the workshop has been called, where we are at in the process (ICANN public consultation in early 2013, SSAC report, ICANN Board resolution in Nov 2013), and what we hope to do in the workshop. (See my recent "Background Information" post [2] for links for more info.) 2. HOW a Root KSK Rollover might occur We would like to discuss how an automated (RFC5011 [3] ) would occur as well as non-5011 roll options and options for a staggered roll. Joe Abley will discuss a couple of relevant Internet Drafts. 3. WHAT a Root KSK Rollover might involve We would like to discuss what changes might be made during a Root KSK Rollover. Specifically two points: a. ALGORITHM CHANGE - Geoff Huston will give a presentation about potential impacts of a change of the algorithm. (Geoff also presented this information about the DNS-OARC meeting this past weekend.) b. Length of KSK - There has been some discussion about changing the length of ZSKs and KSKs and moving to longer key sizes. We would like a discussion around this idea and the potential impacts. 4. IMPLICATIONS Discussion of additional implications beyond those discussed earlier. For instance, issues around response sizes. 5. POTENTIAL TIMELINE (unanchored) We would like to discuss what a potential timeline might look like for the entire process. The intent is NOT to establish a fixed date but rather to establish what a timeline might look like for the full process to take place. 6. NEXT STEPS We want to spend the end of the session identifying specific steps and actions that will occur coming out of this workshop. Given that we only have three hours and a great amount to cover we will be asking people to assist us in helping keep the discussions focused and flowing and moving along through the agenda. Please feel free to send comments to the list - and we will see you on Thursday. Thank you, Dan [1] Ad hoc program committee: Joe Abley, Duane Wessels, Roy Arends, Jakob Schlyter, Dan York, David Conrad [2] http://www.internetsociety.org/deploy360/blog/2014/10/background-informatio… [3] http://tools.ietf.org/html/rfc5011 -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

1 0