[RSSAC Caucus] Collected KSK comments

Fred Baker fred at isc.org
Mon Dec 16 04:55:17 UTC 2019


I'm pulling together comments that we might make. I am including who said them, because we said that Caucus contributions would be attributable to their source. Speaking for myself, I would rather have the comments be considered to have been made by the committee, which is to say without attribution. If that's a general viewpoint, let me know.

George Michaelson:
The proposal should address algorithm rollover. As that is considered out of scope for this version, propose for the next change.

The proposal should include measurement. (George: specifically what would you like to measure?)

The alternate/replacement key pre-gen stuff is forward-thinking, and good.

Paul Muchene:
Phase D, the KSK standby state, it potentially invites an attacker to exploit possible vulnerabilities with either the properties of the key or key generation algorithm.

If phase D could be reduced a reasonably shorter duration (1-1.5 years) this problem could be mitigated. However, if this duration is pretty short and will inconvenience the dissemination of the KSK to OS and DNS software vendors, then considerations should be proposed for using a longer KSK key length of 3072-bit RSA. 

Dessalegn Yehuala
Section 2.4 seems to give a soft rationale for the rollover frequency. Arguments exist for a longer or a shorter interval, and these arguments don't seem to be strong enough to make a firm choice.

Section 2.6 assumes current state of the strength of the current cryptographic algorithm employed for the KSK (2048-bit RSA), there is no risk mitigation identified in the event the current cryptographic algorithm discovered to have some exploitable vulnerabilities. 

Fred Baker: in that context, researchers from KeyFactor presented a paper at First IEEE Conference on Trust, Privacy, and Security that reported that one in 172 RSA certificates certified keys for which the private key could be derived from the public key. 

Davey Song: Suggests changing to an ECC algorithm rather than changing to a 3072 bit key.

There should be a predictable timeline for algorithm rollover and as a result a advance timeline for study, review, and testing work on this. 


More information about the rssac-caucus mailing list