<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class="">On 22 Oct 2021, at 12:10 pm, Matt Nordhoff <<a href="mailto:mnordhoff@gmail.com" class="">mnordhoff@gmail.com</a>> wrote:<br class=""><br class="">There are challenges to upgrading to larger keys, or rolling<br class="">algorithms, but how insurmountable are they?<br class=""><br class="">There are at least 139 TLDs using 2048-bit or larger DNSSEC keys<br class="">*right now* -- and that's excluding about two dozen that are in the<br class="">middle of migrating to a different registry and downgrading to<br class="">1280-bit ZSKs.<br class=""></blockquote><div class=""><br class=""></div>The linked PNG is of a table from the RSA ZSK slide of my<div class="">upcoming presentation at ICANN72 CCNSO-TechDay on Monday (18:40 UTC).<div class="">It summarises many properties of the various key choices:</div><div class=""><br class=""></div><div class=""> <a href="https://dnssec-stats.ant.isi.edu/~viktor/ZSK-choices.png" class="">https://dnssec-stats.ant.isi.edu/~viktor/ZSK-choices.png</a><br class=""><div class=""><div class=""><br class=""></div><div class="">[ The NSEC and NSEC3 sizes in the table are measured sizes of signed</div><div class=""> NXDOMAIN replies from all TLDs where I know of at least 50 signed</div><div class=""> delegations. Smaller TLDs, especially with opt-out and no signed</div><div class=""> delegations return smaller NSEC responses because a single NSEC</div><div class=""> RR can cover all the relevant names. ]</div><div class=""><br class=""></div><div class="">I think this makes a reasonable case that given a suitable software/hardware</div><div class="">stack, newly acquired if need be, choosing a 1280-bit RSA ZSK is practical</div><div class="">and justified. A better choice may be ECDSA P256 or 1536-bit RSA with NSEC.</div><div class=""><br class=""></div><div class="">The main motivation for bringing this up is that I think that it is not enough</div><div class="">for DNSSEC to be practically safe within a tolerable margin, rather, to take</div><div class="">full advantage of DNSSEC we need it to be *trusted*, and trust sometimesm takes</div><div class="">more than good enough security, the safety margins need to be high enough to</div><div class="">put to rest reasonable doubt.</div><div class=""><br class=""></div><div class="">At this point I rather think that RSA-1024 is no longer trusted, even if it can be</div><div class="">made practically secure enough for signing with regular key rotation.</div><div class=""><br class=""></div><div class="">The gap from 0.54 million core years for RSA-1024 and 240 million core years</div><div class="">for RSA-1280, extrapolated from the cost of the recent RSA-250 (829 bit)</div><div class="">factorisation:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;dc42ccd1.2002" class="">https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;dc42ccd1.2002</a></div><div class=""><br class=""></div><div class="">and cost ratios of ~200 and ~90,000 for 1024-bit GNFS and 1280-bit GNFS</div><div class="">respectively, relative to 829-bit GNFS, while "only" 9 bits, is I think quite significant.</div><div class=""><br class=""></div><div class="">The 54 billion (US) extrapolated core years for RSA-1536 is entirely out of reach</div><div class="">of GNFS with planetary-scale resources.</div><div class=""><br class=""></div><div class="">And as Matt points out, RSA-2048 ZSKs, or double-signed TLD zones seem to be</div><div class="">getting by alright.</div><div class=""><br class=""></div><div class="">So I think that it is time to leave the 2010's behind and reach for a more</div><div class="">trustworthy foundation for DNSSEC, by using stronger keys at least at the</div><div class="">eTLD layer, and ultimately for all zones.</div><div class=""><br class=""></div><div class=""><div class="">-- <br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Viktor.<br class=""></div><br class=""></div></div></div></div></div></body></html>