[dns-operations] .NL and 1024-bit RSA ZSKs.

[Matt Nordhoff]

On Fri, Oct 8, 2021 at 5:55 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> > On 8 Oct 2021, at 1:12 pm, Puneet Sood via dns-operations <dns-operations at dns-oarc.net> wrote:
> >
> > This is another case where NSEC3 opt-out interferes with effective
> > NSEC{3} response caching which would reduce queries to the TLD.
>
> Speaking of the .NL zone DNSSEC parameters, the ZSK is 1024-bit RSA,
> and .NL is the largest zone (by signed delegation count) with RSA
> keys less than 1280 bits.
>
> The .COM TLD uses 1280-bit RSA ZSKs, while .BR, .CZ, .CH, .FR and .DK
> all use ECDSA P256.
>
> The next batch of TLDs with 1024-bit RSA ZSKs are .EU, .NO, .BE and .ORG.
>
> While we don't have compelling evidence that 1024-bit RSA DNSKEYs,
> rotated sufficiently often are at a realistic risk of brute-force
> cryptanalytic attacks, the broader cryptographic community has
> left 1024-bit RSA behind, and we now have better options:
>
>   * 1280-bit RSA is practical and improves the safety margin
>   * P256 has been successfully adopted by 45 TLDs and has
>     near universal resolver support, on par with RSA.
>
> So I'd like to suggest that .NL consider either a stronger ZSK,
> or an algorithm rollover.
>
> Not all is stuck in the past, over the last ~1 year, the use of
> algorithm 7 has dropped from a peak of ~2.2 million zones to
> just ~350k zones and lately continuing to fall ~10k/day.
>
> So progress is possible, it just does not happen on all fronts
> at the same time.
>
> For those not yet caught up on last-night's OARC "Town Square"
> Mattermost channel, it would be good to have auth operators
> look more closely at their use of RSA and as needed move to a
> set of best-practice key algorithms/sizes.
>
>         RSA: 2048-bit KSK, 1280 or 1536-bit ZSK
>         P256: Fortunately no further tunables

A couple hundred TLDs even use 2048-bit RSA ZSKs with success. It's
not as efficient, but it must be practical enough, since people in
fact do it.

(Resolvers with poor TCP handling might not appreciate it if .com ever
deployed it, though...)

> The only potential tweak in ECDSA is whether signatures use
> a random nonce, or a deterministic variant that derives the
> nonce from the message:
>
>         https://datatracker.ietf.org/doc/html/rfc6979
>
> Deterministic ECDSA signing should be well suited for
> zone signing when the software stack supports it, and
> can be more performant if the RNG is a bottleneck.
>
> [ I don't know which HSMs, if any, support deterministic
>   ECDSA signing. ]
-- 
Matt Nordhoff