ICANN ICANN Email List Archives

[comments-root-zone-consultation-08mar13]


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

Comments on root zone KSK rollovers

  • To: comments-root-zone-consultation-08mar13@xxxxxxxxx
  • Subject: Comments on root zone KSK rollovers
  • From: Tony Finch <dot@xxxxxxxx>
  • Date: Fri, 12 Apr 2013 18:30:44 +0100

I think it is very important that it is possible to reliably update
the DNS root trust anchor, so that key size changes and algorithm
updates work, and so that we can recover from a compromise (though
I really hope that never happens!).


1. Prerequisites.

There are still some gaps in the tools that support root key rollovers.
I hope ICANN will encourage vendors to make improvements.

Validators should provide tools to report their trust anchor RFC 5011
status. For example, I wrote a script check5011 which will be included
with BIND 9.10. This is necessary so that the rollover process can be
monitored, so that hostmasters can be sure the new key is trusted
before the old key is removed. If something goes wrong it might be
desirable to provide a tool that can force the RFC 5011 state of a
trust anchor, rather than doing a full out-of-band reinitialization.

Validators should be able to automatically update their trust anchor
out-of-band, if they have missed the in-band RFC 5011 process. This
includes software that ships with embedded copies of the current root
trust anchor: it should be possible to install the software after a
rollover without going through a complicated and intimidating manual
process to fetch the new trust anchor. The update tools should handle
restarts as well as initial installs, so that (for example) a virtual
machine image created before a rollover will still work after the
rollover.

The unbound-anchor tool is a good example of what is needed.
http://www.unbound.net/documentation/unbound-anchor.html

Windows has a command `dnscmd /RetrieveRootTrustAnchors` but it is not
clear if this handles restarts as well as initial configuration.

BIND ships with an embedded copy of the root trust anchor. This needs
to be replaced by a tool like unbound-anchor.


2. First rollover.

Ideally this should have happened soon after the initial deployment of
the root KSK and regularly thereafter. A pity.

It would be good to have the better tooling widely deployed before the
rollover.

The rollover schedule in the DNSSEC practice statement for the root
zone KSK operator is quite aggressive, taking two months. It might be
worth doing a slower rollover to allow time for hostmasters to verify
that RFC 5011 is working correctly, and to perform any fixes that may
be necessary, such as software updates. The more thorough testing
process proposed by Michael StJohns is a very good idea.


4. Rollover frequency.

I think rollovers should occur annually. I don't think there is much
advantage to an initial high frequency of rollovers followed by a
slower regular schedule: that would conflict with a slower-than-usual
first rollover. Annual rollovers are probably frequent enough to
provide a useful learning experience.

The rollover frequency should be high enough to ensure that vendors
need to have proper implementations of in-band RFC 5011 and
out-of-band trust anchor update tools.


5. Rollover calendar.

Root KSK rollovers should have a regular schedule that is expected to
continue indefinitely, like the root ZSK rollover schedule. If the
schedule is changed then notice should normally be given in advance -
a year before, perhaps? But this has to be on the understanding that
emergency changes may be required.


6. Public notifications.

Would it be worth using a CERT advisory to notify hostmasters that the
KSK is to be rolled? This sould include helpful instructions for how
to verify that automatic RFC 5011 updates are working, what to do in
case RFC 5011 does not work, and which situations are likely to cause
problems for RFC 5011 (such as offline machines, old software, etc.)


7. Other considerations.

At the moment the out-of-band update mechanism is vulnerable to
compromise of the ICANN signing keys which are used to make the
OpenPGP and S/MIME signatures. The S/MIME signature is also vulnerable
to compromise of any PKIX certification authority.

It would be useful to have a small list of certification authorities
that can be used to validate the S/MIME signature and the TLS
connection to the root trust anchor publication web site. This would
reduce the exposure to the PKIX certification authority system.

It would be nice to know more about how the signing keys are managed:
their storage and update schedule. Shouldn't there be a document like
a DPS for these keys?

I understand that ICANN would like to include third party signatures on
the root trust anchor publication web site. This would be a very good
thing, since it would allow out-of-band update software to require a
quorum of valid signatures instead of just one. This improves
security, since compromise of a single key does not compromise the
whole process. It improves robustness, since signing keys will be able
to change without breaking existing software that uses those keys for
validation, so long as a quorum of old-enough keys remain in use.


Tony.
-- 
f.anthony.n.finch  <dot@xxxxxxxx>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.


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