Comments on Root Zone KSK Rollover
Dear ICANN staff members:I follow the DNSSEC KSK management processes as a unique occurrence, in transparency, of system-wide master cryptographic key management (there are no other instances with similar detailed public disclosure). Although my perspective is expertise in cryptographic key management, I refer to the Internet community need for a basis for trust in the DNSSEC root zone KSK as the foremost goal.
In a nutshell, the following comment concludes that the Internet community needs no special effort from ICANN for DNSSEC KSK rollover operations.
As a factual introduction, let me recall the we are *only* concerned about where in the universe one can find and/or use the two prime factors of this single large number:
21208098148227117960343321833612838096034870221647180437563475296388626117494892254973074223001088922717633438967100118744506133332159724439458690021182903411950795350909541266418188079006856065408673727358953004891761659414231359984826901879133425177752833476889832941722260694661146034962454805267582346109421607802892137569319015893046312943136542420282972251828018894000780546865129436833472430679599666672431529382878002135872237273078199540583353802237029602303157877313296857711265104481160993715957666189735909436584681552582060343296317391386783993929108545402564992151452260402874012061307801750574916077373This being an obvious single point of failure (details left as a security audit exercise), the replacement number would equally be a single point of failure. ICANN et al. must guard the first point of failure. I see little benefit in attempting to guard the mechanism by which the replacement number would come into force: if the first guarding mission fails little can be trusted about the second guarding mission.
From a security operations perspective, the work done by ICANN et al. in preparation of the DNSSEC root zone deployment need not be put into question in any significant aspects. The lesson inherited from this effort about KSK rollover is that some future course of action is envisioned (RFC5011) but the specifics remain to be determined. I would explain this indefiniteness by the very challenges (and workload) of managing any system-wide cryptographic key, plus the relative triviality of the rollover issue in view of the urge to provide an integrity service to the global DNS.
An updated analysis from a security operations perspective must start with the Internet community dependency of the DNS and the root operations by ICANN. From this highest level perspective, one would care about *institutional* rollover (i.e. the DNS root policies, management, and operations by a different institutional arrangement). Indeed, as of today the DNSSEC KSK security rests on technologies, procedures, facilities, equipment, and personnel framed by institutional rules. Should the Internet community expect ICANN to add a KSK rollover subset of technologies, procedures, facilities, equipment and personnel as if the original set was inadequate? A yes answer would be either an oversight that the institutional rollover would be the proper question, or, as I argue, an ill-advised opinion that the DNSSEC KSK security has some intrinsic limitation or weakness.
The DNSSEC KSK is a system-wide cryptographic key used for data integrity purposes. From the mainstream historical use of cryptographic techniques for military and then industrial secret protections, we (the IT security community) are left with a motto that cryptographic keys should be changed periodically. Does this apply to system-wide data integrity keys? Incidentally, from an applied cryptography perspective, even a more prevailing question lacks a consensus response: does this apply to a long-term entity authentication key? The needed answers should rest on threat models and risk analyzes. In plain language, these are explanations about the circumstances where an enemy would attempt to break the DNSSEC KSK and the benefits of doing so. To my knowledge, there are no such published analyzes for the DNSSEC KSK (maybe ICANN should tell the community what it knows in this area) and hence no rationale for applying the periodic key change motto to the DNSSEC KSK. As a personal note, I once proposed a KSK rollover technology (with compliant procedural elements) and then determined that even the RFC5011 route was unnecessary, partly based on a risk analysis concurring with the present comment.
About algorithm rollover (the deployment of new cryptographic algorithms as the strength of current ones diminishes), the balance of benefits and inconveniences should be considered. In general, a deployed algorithm start its life cycle with a large security margin and might later gradually weaken over a long period. As this occurs, not all uses of the algorithm becomes equally problematic. The weakening impact is typically circumstantial; and application characteristics may include or facilitate mitigation strategies. This applies to the DNSSEC KSK as it is deployed today with RSA, SHA-2, and a 2048 bits RSA modulus. The security margin remains good. For the cryptography inclined reader, the SHA-2 replacement with Keccak has no pressing justification, the non-use of RSA-PSS already rests on application characteristics (DNS root operations offer no inadvertent signing oracle to an enemy), and the 2048 bits key size appears not challenged by forthcoming factorization breakthroughs. For sake of analysis, here is a possible mitigation strategy for a broken root KSK caused by a factorization breakthrough: increase the size of the root ZSK beyond the new factorization frontiers and publish the ZSK with an alternate mechanism (this strategy works for critical relying parties because the root KSK and ZSK can be monitored easily and openly).
The preceding paragraph argues that the DNSSEC KSK is not a good algorithm rollover client application because it has a good algorithm to start with and it would resist well to a weakening of its algorithm. The installed base effect could be a more effective barrier to any DNSSEC root algorithm rollover. The installed base effect may even be a barrier to the rehearsal of the RFC5011 rollover mechanism since it was seldom if ever tried as a full scale experiment.
Still, there remains a theoretical possibility that the DNSSEC KSK need to be changed in an emergency. The total collapse of the SHA-2 or digital signature algorithm would have such an impact on every aspects of Internet operations that the DNSSEC KSK would be a low priority concern. The other causes for a DNSSEC KSK rollover would be related to an institutional failure, in which case an institutional emergency response becomes suspicious almost by definition.
For global reliance on DNS data integrity, the Internet community has to live with ICANN at al. as a single point of failure, DNS root KSK as a single point of failure, and HSM technology obsolescence as a single point of failure. The consultation document refers to the HSM battery life as a HSM unit obsolescence. My first reaction is that this battery life limitation should have been flagged when the original root signing procedures were designed (at least one comment e-mail from me to ICANN allude to the the related concept of HSM backup media obsolescence and the HSM manufacturer documentation must have been explicit). The preventive circumvention of HSM battery exhaustion need not be a KSK rollover; a private key material backup (from the operating HSM unit) followed by a restore operation (to a new HSM unit) would be the normal way to proceed. The Internet community is in no way better protected from the threat of an uncontrolled private key material backup operation merely because ICANN abstain from using the HSM backup function when appropriate.
Other comments may refer to a missed opportunity for RFC5011 security due to the lack of a "standby" KSK in the DNSSEC root zone. The present opinion is essentially agnostic about this question as it rests on confidence in the DNSSEC KSK security over an indefinite time horizon. More precisely, while I see the increased resilience of DNS root zone with an active and standby KSK pair, I doubt there would be an assessment of the benefits offsetting the impacts on procedures, facilities, equipment and personnel. The word \"technology\" is absent from the preceding sentence because the technological implications of RFC5011 would be minimal; what matters is the impact on procedures, facilities, equipment, and personnel induced by any rollover strategy.
It has been suggested that algorithm rollover towards elliptic curve cryptography (ECC) should be a consideration for a proactive DNSSEC KSK rollover planning. I have serious reservations about the wisdom of this suggestion for the Internet community.
- The switch from RSA to ECC corresponds to a switch in algorithm breakthrough vulnerability from the integer factorization problem to hard problems in elliptic curves. It is much easier to come up with an independent opinion on the integer factorization problem, which means the switch to ECC would increase the Internet community reliance on a smaller group of highly skilled mathematicians.
- Correspondingly, the KSK key size recommendations for ECC algorithms would be little more than a leap of faith on an even smaller group of mathematicians (not every highly skilled mathematicians would make or endorse such a germane consideration as an actual cryptographic key size).
- Furthermore at the theoretical level, the security proofs appear more conclusive for the RSA cryptosystem than for the ECC schemes (this is a highly debated field, thus this statement is to be taken as an opinion).
- The performance characteristic of ECC is such that signature validation is much more CPU-intensive than signature generation. The DNS validating resolver operations may be negatively impacted depending on the specific circumstances.
The economic incentives to avoid unjustified algorithm agility (savings in system life cycle costs for all participants) should go without saying when looking at the switch to ECC. This is my opinion; those disagreeing may consider it biased. However, the above four points might also explain the lack of industrial momentum towards the ECC technology.
It seems that the executive branch of the US federal government is the foremost promoter of ECC adoption. I doubt the Internet community at large is well served by this push strategy.
In conclusion, I see little benefit in a proactive DNSSEC KSK rollover planning. From an IT security management perspective, I would put emphasis on the continued operational security for the current KSK, which ultimately rests on ICANN transparency and accountability. I did a quick review the latest ZSK ceremony reports for signs of wear and tear in repeated security procedures. From what I remember from this review, I would be more concerned about a root cause and impact analysis of an intervention by a locksmith during the ceremony (if it did occur) than about the whole KSK rollover issue. Anticipative planning of emergency re-keying the DNSSEC root KSK may be useful as a prospective exercise to the extent it stresses the importance of *preventing* KSK compromises.
-- - Thierry Moreau