Relationship of root zone KSK rollover to RFC5011.
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.