- ksk-rollover - lists.icann.org

[ksk-change] How to tell which trust anchors are present at a DNS resolver.
by Michael StJohns March 25, 2015

March 25, 2015

One of the discussions we've been having about 5011 roll overs is that there's no way to tell whether or not they are "taking" because there's no way to check the resolvers externally. I was looking at various possibilities including locally significant RRs that could be queried to , but nothing clicked. After a beer with Scott Rose - we came up with the following convention: Querying a server with QNAME="." and QTYPE="DS" and with no recursion, gets you a set of DS records that represent the trust anchors for that server for the root. This would have to be implemented, but given that I think it may take 2 years to get the rollover done, that may not be a problem. Comments on this approach? (Note comments of "this won't work because its too late" are understood and ignored). What we;re looking for are comments on whether the convention has bad side effects or would be difficult to implement correctly. Mike

3 4

[ksk-change] Fwd: Replacement of Root KSK Hardware Security Modules
by Kim Davies March 23, 2015

March 23, 2015

Apologies for duplicates. I am forwarding on this announcement we posted to our Root DNSSEC announcement list. kim Subject: Replacement of Root KSK Hardware Security Modules ICANN today posted a summary of its planned HSM Replacement Project for the Root KSK online at https://www.icann.org/news/announcement-3-2015-03-23-en Here is the text: Overview As part of securely maintaining the Root Zone Key Signing Key (KSK), ICANN utilizes specialized devices known as Hardware Security Modules (HSMs). These HSMs store the private key material for the Root Zone KSK, and are powered by batteries that have a limited lifespan. While the batteries are currently in good condition and have an expected shelf life of 10 years, the manufacturer warrants the first five years of operation. Out of an abundance of caution, ICANN is planning to replace the existing units during 2015 after five years of service. Background The Domain Name System Security Extensions (DNSSEC) provides a way for software to validate that Domain Name System (DNS) data has not been modified during Internet transit. This is done by incorporating public key cryptography into the DNS hierarchy to form a chain of trust originating at the root zone. In accordance with its role as IANA Functions Operator, ICANN is the Root Zone Key Signing Key Operator performing the function of securely generating and storing the Root Zone KSK. ICANN uses HSMs to store the KSK. HSMs are secure crypto-processors that manage cryptographic keys and perform cryptographic operations while providing physical protection of the private keying material through tamper evident mechanisms. ICANN has two duplicate HSMs for each secure ICANN Key Management Facility (KMF) — one facility on the U.S. East Coast and another facility on the U.S. West Coast. In the event that one HSM or KMF should fail, the other redundant devices and locations would be available for use. Beyond these options there are further recovery procedure details that are documented in the KSK Disaster Recovery and Business Continuity Plan. Unlike many other electronic devices, the battery for an HSM is typically built into the unit and cannot be replaced individually. The batteries in these HSMs have a life expectancy of 10 years from the manufacture date, with the manufacturer warranty covering five years of support from the date of first use. Replacement Process The HSMs currently in production were first used in 2010. With the warranty period ending, and as a conservative approach to the battery’s expected lifetime, ICANN intends to bring into service new HSMs during calendar year 2015. The contents of the existing HSMs will be imported into the new HSMs, which can perform the same functions as the existing set. This process will be performed during quarterly events at the KMFs known as key signing ceremonies. Scripts will be written to include the commissioning of new HSMs during regularly scheduled key signing ceremonies in 2015. ICANN plans to augment the existing four HSMs with an additional four HSMs such that the new HSMs are placed into parallel production with the 2010 HSMs for a transitional period to guarantee the security and availability of KSK operations. Once the relevant parties are confident that the new HSMs are functioning correctly and the continuity of KSK operations will not be compromised, a secure method of decommissioning and destroying the existing modules will be designed to adhere to the most current industry specifications. Key Risks The following list represents the key identified risks and their mitigations: Risk: All four production HSMs fail to perform cryptographic operations due to a battery failure thus impacting the continuity of operations. Mitigation: There are currently four duplicate HSMs, plus additional backups that can be activated by the disaster recovery process. The failure rate of a battery in a single HSM is easily mitigated by the redundancy resulting from the three other HSMs. The expected shelf life of the battery is around 10 years, and each unit reported their battery condition as good. That said given the similar production dates, it is possible that the batteries in all HSMs could fail around the same time. To maintain the continuity of operation and mitigate the risk of all HSMs ceasing to function, we consider it prudent to perform the HSM replacement in 2015 and use HSMs with differing battery lot and production dates. Risk: The new production HSMs do not function correctly when powered up for the first time. Mitigation: As part of installing the new HSMs, acceptance testing will be performed to verify the function of the units prior to the ceremonies in which they are put into production. For a period after the new HSMs are placed into service, the existing HSMs will continue to be stored in the secure facilities allowing for more options for remediation in the case of new HSM failure. Risk: All new production HSMs share a common defect. Mitigation: It is possible that if all four HSMs are from the same production batch, they may have common flaws (such as bad battery composition) that would compromise the redundancy in place. To mitigate this risk, ICANN worked with the vendor to ensure the HSM units are comprised of models with different manufacture dates and contain batteries that were built in different production runs. Questions and Answers Q1: Why do the HSMs need to be replaced, and not just the batteries? A1: While the HSMs can be reconditioned with new batteries, they must be returned to the vendor to perform that procedure. ICANN will replace the HSMs, rather than recondition the units, to ensure the cryptographic key material does not leave the secure Key Management Facilities. Q2: How does this project involve a future rollover of the Root KSK? A2: This project is distinct from the project to replace the existing Root KSK with a new Root KSK (known as a “rollover”). HSM issues relating to the rollover will be considered by the Root KSK Rollover Design Team. Separation of the HSM replacement project from a Root KSK rollover is considered beneficial to allow time for the Rollover Design Team to fully develop their approach without being influenced by operational pressures relating to HSM replacement. Q3: What consideration was made in selecting the replacement HSMs? A3: ICANN procured the most recent HSM model, the AEP Keyper Plus, from the vendor used to provide the HSMs that are currently in production. This model meets FIPS 140-2 Level 4 security certification, which is a requirement for the Root KSK in the IANA Functions contract. This model also allows for the importing of the Root KSK from the older models without needing to regenerate the Root KSK. The newer HSM model was selected rather than the current HSM model in ICANN’s production model as the expected lifetime of support from the vendor is greater. Q4: How many trusted community representatives are needed to replace the HSMs? Q4: ICANN has determined that three trusted community representatives is the minimum number needed to export the root KSK from the existing production devices, and import them into the new devices. This process does not require generation of a new set of “SO” and “OP” cards, and therefore does not require the entire set of Cryptographic Officers to be present. The existing Recovery Key Share Holders’ credentials will continue to work with the new HSMs. With kindest regards, Kim Davies Director, Technical Services ICANN

1 0

[ksk-change] Helping the panel name the reasons for the KSK rollover
by Paul Hoffman Feb. 23, 2015

Feb. 23, 2015

When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design. The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well. --Paul Hoffman DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed. Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key. HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed. Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers. Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals. Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.

9 16

[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] Solicitation for Statements of Interest regarding Root KSK Rollover
by Edward Lewis Jan. 8, 2015

Jan. 8, 2015

(I believe this has been posted before, but to have a post-holiday period ³refesher²:) ICANN, as the IANA functions operator, in cooperation with Verisign as the Root Zone Maintainer and the National Telecommunications Information Administration (NTIA) as the Root Zone Administrator, together known as the Root Zone Management (RZM) partners, seek to develop a plan for rolling the DNS root zone key-signing key (KSK). The KSK is used to sign the root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the Internet¹s root zone. The Root Zone Partners are soliciting five to seven volunteers from the community to participate in a Design Team to develop the Root Zone KSK Rollover Plan (³The Plan²). These volunteers along with the RZM partners will form the Design Team to develop The Plan. Individuals interested in volunteering approximately 5 hours per week for the Design Team should consult the announcement: https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf and submit their Statement of Interest to ksk-rollover-soi(a)icann.org no later than January 16, 2015.

1 0

[ksk-change] Solicitation for Statements of Interest regarding Root KSK Rollover
by KSK Rollover SOI Dec. 22, 2014

Dec. 22, 2014

ICANN, as the IANA functions operator, in cooperation with Verisign as the Root Zone Maintainer and the National Telecommunications Information Administration (NTIA) as the Root Zone Administrator, together known as the Root Zone Management (RZM) partners, seek to develop a plan for rolling the DNS root zone key-signing key (KSK). The KSK is used to sign the root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the Internet’s root zone. The Root Zone Partners are soliciting five to seven volunteers from the community to participate in a Design Team to develop the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with the RZM partners will form the Design Team to develop The Plan. Individuals interested in volunteering approximately 5 hours per week for the Design Team should consult the announcement: https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf and submit their Statement of Interest to ksk-rollover-soi(a)icann.org no later than January 16, 2015.

2 1

[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] FYI: media coverage of '1024 DNSSEC RSA keys are weak'
by Richard Lamb Nov. 14, 2014

Nov. 14, 2014

Thanks to Peter Koch for pointing these articles out. -- Heise, a German language online news medium, published an article titled "DNSSEC with too short RSA keys". <http://www.heise.de/newsticker/meldung/DNSSEC-mit-zu-kurzen-RSA-Schluesseln -2449480.html> The article refers to a paper by Dan Bernstein and Tanja Lange about advances in factorization by massively parallel hardware operation <http://cr.yp.to/factorization/batchnfs-20141109.pdf>. It appears that the article might go far beyond the substance or even the claims in the paper. There was a previous note at <http://www.golem.de/news/verschluesselung-parallele-angriffe-auf-rsa-schlue ssel-mit-1-024-bit-1411-110435.html>, much less alarmist. Some serious review of the paper to evaluate the claims and conclusions would be helpful. -Peter PS: an obviously, if RSA1024 was unusable for DNSSEC, there are other uses ..

1 0

[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