[RSSAC Caucus] Collected KSK comments

[ABDULKARIM AYOPO OLOYEDE]

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 at 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 at 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/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20191216/4aff1def/attachment.html>