Comments from the Internet Infrastructure Foundation (.SE)
Comments from the Internet Infrastructure Foundation (.SE) Submitted by ICANN staff on behalf of Anne-Marie Eklund-Löwinder ---------------------------------------------------------------------------- ----------- Consultation on Root Zone KSK Rollover The Internet Infrastructure Foundation (.SE), as the administrator of the Swedish country code top level domain, appreciate ICANN's consultation on Root Zone KSK Rollover and has compiled the following response (attached as .pdf as well). Background .SE recognizes the efforts made by ICANN to make sure that the root is signed in a safe and secure manner, involving independent and neutral parts from the Internet Community by appointing Trusted Community Representatives, whereas .SE's Chief Information Security Officer Anne-Marie Eklund Löwinder is appointed as a Crypto Officer for the East Coast site in Virginia, US. We believe that it is essential to have an open publication of policies and processes, and we strongly support the development of a secure, efficient operation of DNSSEC for the root zone. The Swedish TLD .se was a very early adopter of DNSSEC on the TLD level and the first ccTLD to sign its zone in 2005. From that time we have performed a number of KSK key rollovers, and have some experience to share. The most important question is how you can ensure that when the key has to be changed, it is propagated securely, safely, and quickly? Sharing the Swedish experiences Unfortunately, there is no silver bullet solution to this issue. When .SE started with DNSSEC and key rollovers, we had no one to follow by example. As the root wasn't signed by that time, we became the trust anchor for our part of the Internet universe. To make sure to minimize risks and avoid serious problems, we spent a lot of time thinking about what would be the best way of making sure that every resolving operator should be aware of the change of keys. *We cannot stress enough the fact that there will be validating resolvers that will stop working when the old key is removed. It is important to minimize that problem as much as possible.* We introduced the use of two KSK's with two year validity and a very extensive overlap in validity time (one year), making sure that those who had to update keys (mainly operators of resolving name servers) had sufficient time to do this in a good manner (12 months). From that point we rolled KSK on an annual basis. *We strongly recommend ICANN to suggest a time for overlap of keys long enough to make sure that as many as possible are aware of the change of keys, but not as long as to make it feel like an eternity. From our perspective 2-4 months should be sufficient.* .SE:s ambition was from the very beginning to design a procedure in close dialogue with the community. We started off with an extensive period of notifications and early warnings by advertisements in computer magazines, mailing lists, information on our web site et cetera. But even then, on some occasion, one of the largest ISP's made a mistake which cut off all their customers from the .se part of the Internet. On the other hand, that incident was the main reason that we found out about the "roll-over-and-die" problem (http://www.potaroo.net/ispcol/2010-02/rollover.html). As we all know, stirring things up exposes flaws. A RZ KSK rollover will be no exception. *We would like to emphasize that it is of great importance that ICANN organize an extensive information campaign regarding the key rollover.* Following .SE by example, several other top-level domain registries started to sign their domains, and there is still a significant number who has announced their ambition to do so, especially after the root signing. The deployment by individual TLD's meant a proliferation of individual trust anchors that ends up as isolated islands of trust, which in the end made the transition to a signed root zone more dangerous and more complex by each TLD trust anchor added. Therefore, we are especially grateful that the root signing took place several years ago. By starting early we were able to find a number of bugs in the implementation without having to much negative effects on the Internet users in .se, since there weren't too many validating resolvers around. On the global level this is not the case anymore. It is a significant risk that the negative effects of poor implementation on the resolving side of DNS will be considerable. *We suggest that ICANN, if possible, put up a web service where those concerned may check whether they are using the valid new key or the old one.* The new gTLD program has as a mandatory requirement that the zones must be signed with DNSSEC. The introduction of new gTLD's will increase the number of resolvers validating DNSSEC, resulting in software problems or other major changes to DNSSEC, such as key rollover, to have a much larger impact. Key Signing, Key Management and distribution From .SE point of view the root zone's KSK management and distribution process should be designed to minimize the impact on resolving name service providers throughout the Internet. The ICANN Root Zone KSK Operator DPS states that "each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation". The consequence of that statement is that no one really knows when a key rollover will take place. The DPS also states: "RZ KSK roll-over is scheduled to facilitate automatic updates of resolvers' Trust Anchors as described in RFC 5011 [RFC5011]". That is a truly good ambition, but the truth is that RFC 5011 aren't tested operationally on the public Internet. Neither is it sure that the name servers are configured to manage key rollover automatically, and it would surprise us if there are more than a few operators who has been thinking of this. No one knows what the outcome of this experiment will be. For that reason it is advisable to provide the community with an extensive time period during which anyone may update keys in a planned, after the new key has been taken into production in the root zone. Even though there is a call for decisions on when and how to change keys it is necessary that this decision is built upon a proper risk analysis. Even though it in general is standard with a regular change of keys, in practice it is dependent on a number of different parameters such as: - Changes due to the development of algorithms. - Changes due to the development of key lengths. - If the confidentiality of a key is suspected to be compromised. - Advances of modern crypto analysis and the development of computational performance. The message is: If it's not broke, don't fix it. In .SE we quite recently changed our policy for KSK key rollover from the regular annual key rollover with two valid keys in use into one single key system that will be changed when called upon. If the confidentiality of a key signing key (KSK) is suspected of having been compromised, a new key will be generated and put into immediate use, in parallel with the old key. The old KSK will remain in place and be used to sign the key set until it can be considered sufficiently safe to remove the key, taking into account the risk for disruptions in relation to the risk presented by the compromised key. A KSK rollover is always announced through the predefined channels in the .SE DPS, and made widely available in almost all possible ways. .SE answers to ICANN's Consultant Questions 1. What prerequisites need to be considered prior to a first scheduled KSK rollover. Answer: Changing keys should only occur if there is a strong reason to do so, like: - Changes due to the development of algorithms. - Changes due to the development of key lengths. - If the confidentiality of a key is suspected to be compromised. - Advances of modern crypto analysis and the development of computational performance. - Exchange of encryption hardware (HSM). Mostly, by changing keys you are signaling to the trusting parties that something is essentially "wrong", or at least not as it should be. All hardware has a finite lifetime. Since the internal batteries in the current HSM according to the vendor have a restricted lifetime of five years, the first prerequisite is that the key rollover has to be performed well before mid 2015. There should be a reasonable time for preparations, and we believe it is about time to start the planning right now. It would be desirable if it was finished before all the new gTLD's are about with too many domains, to minimize the negative effects, should anything go wrong. 2. When should the first scheduled KSK rollover take place? Answer: Well before mid 2015 for obvious reasons. 3. What should the IANA Functions Operator (ICANN) and the other Root Zone Management Partners do to gauge the technical and end-user impact of a KSK rollover following the first scheduled KSK rollover. Answer: Starting as soon as possible by: - Estimating the number of resolvers that are supposed to make use of the new key. - Estimating the type of operators that will be affected, - Mapping the presence of hardware and software implementers and vendors that are using or will make use of the RZ KSK in a foreseeable time period. - Reach out to the hardware and software implementers and vendors to explain how to keep the RZ KSK updated automatically. - Make sure that there are standardized mechanisms for the RZ KSK updating, to make sure that everyone follows the same route. RFC 5011 might not be sufficient for equipment that is offline for an longer time period. - Publishing information and a timeline of what will happen, how it will happen and about what time it will happen. It would be useful if ICANN would compile examples for configuration of name servers to manage automatic key update. For the future it should be clarified that the established policy allows for a KSK rollover carried out when required, which means that a key rollover may take place for any reason, but it is not regular and frequent in the sense that you decide to change keys "every other month", or "once a year". It should only be changed if necessary. .SE finds it very important for ICANN to set a firm target date for the key rollover and to make that date known to the public. In our opinion that process involves publishing of a road map for reaching that goal, and communicate with the community. 4. How often should a scheduled KSK rollover take place, following the first one. Answer: Se Q3 above. A KSK rollover should only be made when required. If one decide to do it with a specific frequency, and then someone find a weakness in an algorithm the day after, then you will have to do a new rollover despite the fact that it is not timely, which will cause a lot of questions and trouble. 5. How far should the published calendar for scheduled KSK rollovers extend into the future? Answer: Following the arguments above, there shouldn't be such a calendar. But you should have a published action plan with a timeline telling how long the entire key rollover procedure will take. 6. What public notification should take place in advance of a scheduled KSK rollover? Answer: Except for the obvious mailing lists and publishing on the ICANN web site, ICANN should collect and keep track of information about contact points in every regional organisation like for instance CENTR, and in every RIR to get support to spread the information to the right recipient, trying to propagate the information to the operators concerned. 7. What other considerations are necessary for the Root Zone Management Partners to take into consideration prior, during and after a planned key roll over? Answer: *Prior* to a planned key roll over information is crucial. *During* a planned key rollover there is not much left but following the procedures, like we are doing in the key ceremonies. A key rollover does not differ much from a key generation and therefore it should be managed like one. The result of this approach would be that every 4-5 years, the key ceremony will take longer time than a regular key ceremony. *After* a planned key rollover it is important to follow up on any kind of incidents or problems that have occurred, both by monitoring (if possible) the resolvers (in all different sizes) and the infrastructure, together with a public comment period where anyone can post their questions, concerns and problems. We are happy to answer any questions that this message will raise, and willing to discuss this further if you would find it valuable. Kind regards, Anne-Marie Eklund Löwinder Chief Information Security Officer, The Internet Infrastructure Foundation (.SE) Patrik Wallström Senior Researcher, The Internet Infrastructure Foundation (.SE) CEO, OpenDNSSEC AB (svb) .SE (The Internet Infrastructure Foundation) Direct: +46(8)-452 35 17 | Mobile: +46(73)-43 15 310 Twitter: @amelsec Mail: PO Box 7399, SE-103 91 Stockholm, Sweden Visitors: Ringvägen 100 https://www.iis.se/en/ Attachment:
smime.p7s |