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

[Moritz Müller]

We have plans to roll to ECDSA for .nl but my colleagues from the Ops team can probably comment on that.

—
Moritz

> On 8 Oct 2021, at 19:51, 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
> 
> 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. ]
> 
> --
> 	Viktor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211011/929b90dd/attachment.sig>