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

[Viktor Dukhovni]

> On 22 Oct 2021, at 12:10 pm, Matt Nordhoff <mnordhoff at gmail.com <mailto:mnordhoff at gmail.com>> wrote:
> 
> There are challenges to upgrading to larger keys, or rolling
> algorithms, but how insurmountable are they?
> 
> There are at least 139 TLDs using 2048-bit or larger DNSSEC keys
> *right now* -- and that's excluding about two dozen that are in the
> middle of migrating to a different registry and downgrading to
> 1280-bit ZSKs.

The linked PNG is of a table from the RSA ZSK slide of my
upcoming presentation at ICANN72 CCNSO-TechDay on Monday (18:40 UTC).
It summarises many properties of the various key choices:

    https://dnssec-stats.ant.isi.edu/~viktor/ZSK-choices.png

[ The NSEC and NSEC3 sizes in the table are measured sizes of signed
  NXDOMAIN replies from all TLDs where I know of at least 50 signed
  delegations.  Smaller TLDs, especially with opt-out and no signed
  delegations return smaller NSEC responses because a single NSEC
  RR can cover all the relevant names. ]

I think this makes a reasonable case that given a suitable software/hardware
stack, newly acquired if need be, choosing a 1280-bit RSA ZSK is practical
and justified.  A better choice may be ECDSA P256 or 1536-bit RSA with NSEC.

The main motivation for bringing this up is that I think that it is not enough
for DNSSEC to be practically safe within a tolerable margin, rather, to take
full advantage of DNSSEC we need it to be *trusted*, and trust sometimesm takes
more than good enough security, the safety margins need to be high enough to
put to rest reasonable doubt.

At this point I rather think that RSA-1024 is no longer trusted, even if it can be
made practically secure enough for signing with regular key rotation.

The gap from 0.54 million core years for RSA-1024 and 240 million core years
for RSA-1280, extrapolated from the cost of the recent RSA-250 (829 bit)
factorisation:

	https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;dc42ccd1.2002

and cost ratios of ~200 and ~90,000 for 1024-bit GNFS and 1280-bit GNFS
respectively, relative to 829-bit GNFS, while "only" 9 bits, is I think quite significant.

The 54 billion (US) extrapolated core years for RSA-1536 is entirely out of reach
of GNFS with planetary-scale resources.

And as Matt points out, RSA-2048 ZSKs, or double-signed TLD zones seem to be
getting by alright.

So I think that it is time to leave the 2010's behind and reach for a more
trustworthy foundation for DNSSEC, by using stronger keys at least at the
eTLD layer, and ultimately for all zones.

-- 
	Viktor.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211022/6231c768/attachment.html>