Hi Fred, I agree with you. It should be from the group if we majorly agree that they are valid observation which I think they are. Thanks AK On Mon, Dec 16, 2019 at 4:55 AM Fred Baker <fred@isc.org> wrote:
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. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Website <http://www.unilorin.edu.ng>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/>