March 2015 - ksk-rollover - lists.icann.org

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

March 26, 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

4 4

[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