October 2014 - ksk-rollover

[ksk-change] Action #3 - Root KSK Rollover Workshop at ICANN 52
by Dan York Jan. 20, 2015

Jan. 20, 2015

Action #3 - We decided to hold another workshop at ICANN 52 in Marrakesh. We asked for volunteers to be part of a "program committee" to organize the activities for ICANN 52. The following people indicated their interest at today's meeting in being involved: Participants: David Conrad, Geoff Huston, Jacques Latour, Joe Abley, Paul Ebersman, Dan York Q FOR LIST: Who else would be willing to participate in planning the ICANN 52 activities? (Please reply to list) Two notes: - We did not identify a lead for the program committee but I would assume DRC would be the point person (unless he says otherwise). - We did not discuss whether we want to have a public workshop AND a closed "interop" workshop as we did this time. This is something that we as a group may want to decide. (Discuss.... :-) ) 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/

5 7

[ksk-change] Action #2 - Creation of a document about multiple Root KSKs and a rollover
by Dan York Nov. 20, 2014

Nov. 20, 2014

Action #2 - We agreed that we need to create a document that outlines items such as (and this is NOT a complete list): - How could it work to have multiple Root KSKs? What would be involved? - What would be the logistics look like for a keyroll? - What are the concerns about rollback? Lead: David Conrad (DRC) said that he (or someone he finds) will take lead on this document. Participants: Mads, Kumar, Joe Several other people contacted me afterwards saying that they would be interested and need to figure out if they can with schedules, etc. (And now is the time they can say if they are in fact able to help with the document... ) Q FOR LIST: Who else would like to work on this document? Please reply back to the list. 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/

4 4

[ksk-change] HSM's - FIP 140-2 L4 comments
by Michael StJohns Oct. 27, 2014

Oct. 27, 2014

Hi - I recently exchanged emails with an HSM vendor on the subject of Fips 140-2 Level 4 products. What he told me was that all of their products had sufficient hardware protections to meet the L4 requirements, but that the cost of going through all the rest of the requirements (mainly the formal design analysis and modeling), as well as a lack of customers specifically asking for L4, generally meant that they ended up going for and getting the L3 certification. One of the things I commented on to NIST during the FIP140-3 second comment period was that the standard's focus on implementing specific FIPS defined policies for the HSM was overreaching - that instead the FIPS 140 standard should be ensuring that the HSM enforces policies set by the user and not imposing their own. For example, there's this requirement for L3 and L4 that you have identity based control of the key material, and that a specific user has to be logged in before the material can be used. That's problematic for three different use cases: a) The embedded HSM which provides identity information and possibly key management for the associated embedded firmware and processor - why would you want to have to login?? b) the case where you want to wrap key material in a more comprehensive policy - say where the HSM only emits a signature over a piece of data if its presented with N signatures over the same data it can verify against configured public keys. c) - and this one is why so few TPMs have made it through FIPS certification - the ability for an HSM to certify key material generated or contained on the HSM as originating from that HSM; there's no concept of separation of module keys (a key pair owned by the HSM itself, rather than a user) and user keys and treating them differently. Strangely enough, there's no requirement in the 140-2 L4 set that the login credential be anything stronger than a PIN. The FIPS 140-2 (and -4 if and when it comes out) is somewhat broken in that it thinks of the HSM in 1995 and PKCS11 terms. What I actually want out of an HSM is one that will enforce policies that I set on keys that I generate, not impose a set of policies that might not fit my needs - or in some cases actively prevent satisfaction of those needs. In some ways, FIP140 is actively bad in that things like Javacard Connected could never be certified under that standard which means that I can't get a certified product that is flexible enough for most needs. All that said, I do think we need a HSM with L4 hardware protection; we need something like the FIPS process to verify the operation of the various algorithms; we need something possibly more like the UL process to verify that key material that you want to stay in the HSM stays in the HSM. The FIPS 140 Level 4 incantation is a handy shorthand for requirements, but I think we should probably break it down to a finer grain on the next discussion go around. Mike

1 0

[ksk-change] On the topic of 1024-bit ZSKs
by David Conrad Oct. 20, 2014

Oct. 20, 2014

Unrelated to KSK change, but as we discussed it in the workshop... https://kivo.com/p/h985rFcI, slides 37-39 Dr. Bernstein notes (page 38): "Analyses in 2003 concluded that RSA-1024 was breakable; e.g., 2003 Shamir-Tromer estimated 1 year, ≈ USD $10^7" I'm a bit disappointed at the lack of caveats in Dr. Bernstein's slides. Regards, -drc P.S. Also perhaps of note (although not directly related to key change), the last bit of slide 47 and slides 50-53.

4 3

[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