Relationship of root zone KSK rollover to RFC5011.

[Chris Thompson <cet1@xxxxxxxxx>]

This is a response primarily in connection with Q1, "what prerequisites
need to be considered prior to a first scheduled KSK rollover".

ICANN's DNSSEC Practice Statement for the Root Zone KSK Operator,
<https://www.iana.org/dnssec/icann-dps.txt>, makes several references
to RFC5011, giving the impression that a root zone KSK rollover would
be done in a way compatible with that RFC. This apparent commitment was
used as one of the arguments for advancing RFC5011 to Internet Standard
status (January 2013).

However, the key schedule actually described in section 6.6 of the DPS
does not in fact conform to the requirements of RFC5011. Specifically,
the revoked KSK is never self-signed, so that correct RFC5011 client
implementations (such as BIND's "managed-keys") will never invalidate
it as a trust anchor (although they may for example warn about its
unexpected absence from the DNSKEY RRset at the end of the sequence).

This is not a satisfactory situation. ICANN should make a decision as
to whether a root zone KSK rollover will or will not conform to RFC5011
in all respects. Despite the limited experience with deployed RFC5011
client implementations actually being used to update trust anchors,
I would recommend conforming. However, this would necessarily involve
periods when the root zone DNSKEY RRset is signed by at least two keys.
That was avoided, apparently deliberately, in the schedules described
in the existing DPS.

When the root zone was first signed in 2010, there was substantial
concern about the size of signed DNSKEY RRset responses. Since then,
many TLDs have been signed using key schedules which involve much
larger signed DNSKEY RRset responses than are used for the root
zone, without apparently making them inaccessible to validating
DNS resolvers. If it is thought necessary, ICANN could go through
a process resembling that using during the "DURZ" experiments, in
which the signed DNSKEY RRset responses from selected root nameservers
were artificially padded, to provide some reassurance on this point.

-- 
Chris Thompson           University of Cambridge Computing Service,
Email: cet1@xxxxxxxxx    New Museums Site, Cambridge CB2 3QH,
                         United Kingdom.