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

[Viktor Dukhovni]

On Fri, Oct 22, 2021 at 12:54:14PM +1000, George Michaelson wrote:

> I would be concerned that the language which makes the recommendation
> HAS to also note the operational problems. You alluded to the UDP
> packetsize problem. And implicitly the V6 fragmentation problem. What
> about the functional limitations of the HSM and associated signing
> hardware?

Indeed limitations in hardware and software stacks can be a short-term
barrier to updating algorithms or key sizes.  But ultimately, I would
hope these would not be barriers to following best-practice (which of
course is open to debate, and I don't claim to speak authoritatively,
rather I'm making what I think is a cogent case).

> Even without moving algorithm, Signing gets slower as a function of
> keysize as well as time to brute force. So, there is a loss of
> "volume" of signing events through the system overall. Time to resign
> zones can change. Maybe this alters some operational boundary limits?
> (from what I can see, 1024 -> 1280 would incur 5x slowdown.  1024-2048
> would be 10-20x slowdown. RSA to elliptic curve could be 50x or worse
> slowdown)

Actually the story for signing is quite a lot better for ECDSA than
that.  On my Xeon Skylake CPU, with OpenSSL, *signing* with ECDSA is
more than 4x *faster* than with RSA 1024:

                     sign/s verify/s
    rsa 1024 bits    9440.5 147066.7
    rsa 2048 bits    1400.7  48202.9
    rsa 1280 bits    2565.0  83284.0
    rsa 1536 bits    2069.2  78504.6
     256 bits ecdsa 38470.3  12519.7

    [ I patched the OpenSSL 1.1.1 build tree to add support for
      1280-bit and 1536-bit RSA tests to "openssl speed". ]

It is *verification* that was ~12x slower with ECDSA than 1024-bit RSA,
and is a cost born on the validating resolver side, not the signing
server side.   Almost 44% of non-TLD zones are using ECDSA, and the
resolvers are coping fine.

> If the case for "bigger" is weak, then if the consequences of bigger
> are operational risks, maybe bigger isn't better, if the TTL bound
> life, is less than the brute force risk?

I see many zones using RSA keys that haven't been rotated in 4 years.
For TLDs things are better, the oldest ZSKs date back to mid January
this year, but I think more frequent rotation is prudent.

> A totally fictitious example. but .. lets pretend somebody has locked
> in to a hardware TPM,

Well, a TPM is unlikely except for the KSK, which only needs the DNSKEY
RRset now and then.  TPMs are crypto-decelators, and their performance
is simply not adequate for holding the ZSKs for all but the smallest
zones.

> and it simply won't do the recommended algorithm but would power on
> with 1024 until the cows come home? If the TTL was kept within bounds,
> if resign could be done in a 10 day cycle rather than a 20 day cycle
> (for instance) I don't see why the algorithm change is the best
> choice.

The algorithm change is aid of improving trust in the broader DNSSEC
ecosystem.  If we're stuck with parameters that NIST recommendations
suggest not using beyond 2010, that hardly inspires confidence.

My primary recommendation is ECDSA P256 (13), with 1280-bit RSA only as
a fallback for operational reasons, when indeed software or hardware
limit your choices to RSA, and 1280 or 1536-bit RSA is viable.

A well implemented ECDSA signer will outperform an RSA signer on similar
general-purpose CPUs.  Of course it is always possible to have a poor or
no ECDSA implementation.

-- 
    Viktor.