Comments on Root Zone KSK Rollover

[Thierry Moreau <thierry.moreau@xxxxxxxxxxxxx>]

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:
21208098148227117960343321833612838096034870221647180437563475296388626117494892254973074223001088922717633438967100118744506133332159724439458690021182903411950795350909541266418188079006856065408673727358953004891761659414231359984826901879133425177752833476889832941722260694661146034962454805267582346109421607802892137569319015893046312943136542420282972251828018894000780546865129436833472430679599666672431529382878002135872237273078199540583353802237029602303157877313296857711265104481160993715957666189735909436584681552582060343296317391386783993929108545402564992151452260402874012061307801750574916077373
This 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