[dns-operations] [Ext] Obsoleting 1024-bit RSA ZSKs (move to 1280 or algorithm 13)

[Paul Hoffman]

On Oct 20, 2021, at 9:29 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> I'd like to encourage implementations to change the default RSA key size
> for ZSKs from 1024 to 1280 (if sticking with RSA, or the user elects RSA).

This sounds fine.

> Implementation defaults aside, operators should actively migrate away
> from 1024-bit RSA ZSKs to either 1280-bit RSA (algorithm 8 or 10, not 5
> or 7) or better still to ECDSA P256 (algorithm 13).

This sounds fine.

> With RSA-250 (decimal, 829 bits binary) factored in Feb 2020 using
> 2700 core-years of CPU:
> 
> https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;dc42ccd1.2002 
> 
> the cost of factoring 1024-bit keys at ~200x more is now conservatively
> 0.54M core years or less given better optimised algorithms, parallel
> attacks on multiple keys, ...

The word "conservatively" is misused here. You have no way of estimating whether "better optimised algorithms" or "parallel attacks on multiple keys" will ever happen, and even if they do, how much or little they will improve the NFS algorithm.

> While 0.54M core years is not cheap, it is plausibly within reach and
> attacks only get better.

The word "plausible" carries a lot of weight here. It is indeed possible that a state actor has the resources to break short-lived 1024-bit RSA ZSKs. The question is why someone who controls that much computer power would want to mount that attack, which has very limited value to such a state actor, as compared to using it to break other 1024-bit RSA keys that were used for encrypting material of interest.

> The cost of attacking 1280-bit RSA with GNFS is ~90k times the cost of
> the 829-bit RSA-250 challenge, or ~24M core years.

This statement also makes guesses about scaling that cannot be supported by the current data. It also makes it sound like an attacker who could pull together a huge computing system for 1024-bit keys could not expand that system by 50x. In the cryptographic world, 50x (about 5 bits of effective strength) is considered a negligible difference.

> While the safety margin is still tight,

The word "tight" is unsupported.

> moving to 1280-bit RSA is a
> substantially worthwhile improvement,

The word "substantially" is unsupported, particularly given that cryptographers only look at jumps of maybe 32 bits of effective strength as interesting.

> and with reasonable key rotation
> (say every 90 days), attacks using publicly known techniques appear
> likely out of reach (spin ~100M cores for 90 days in the hope of
> cracking one key just before it is replaced).

This misstates the value of breaking ZSKs. Once a KSK is broken, the attacker can impersonate the zone only as long as the impersonation is not noticed. Once it is noticed, any sane zone owner will immediately change the ZSK again, thus greatly limiting the time that the attacker has.

In summary, it is fine to propose that software default to issuing larger RSA keys for ZSKs, but not with an analysis that makes a lot of unstated guesses. Instead, it is fine to say "make them as large as possible without causing automatically needing TCP, and ECDSA P256 is a great choice at a much smaller key size". 

--Paul Hoffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2584 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211020/56728978/attachment.bin>