ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Comments from the Internet Infrastructure Foundation (.SE)

  • To: "comments-root-zone-consultation-08mar13@xxxxxxxxx" <comments-root-zone-consultation-08mar13@xxxxxxxxx>
  • Subject: Comments from the Internet Infrastructure Foundation (.SE)
  • From: Chhun Chy <chhun.chy@xxxxxxxxx>
  • Date: Wed, 17 Apr 2013 13:38:34 -0700

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).




.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


*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


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


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


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


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


- 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


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


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


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


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?




*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


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy