Most probably by now you are tired of all the talk about rolling the root KSK. Yes, we are too! So, today we are not going to talk about that one.
Hopefully you remember that IIS rolled the keys for .se. Not only that, we also rolled the algorithm used from RSA-SHA1 to RSA-SHA256. Being responsible for the operations of .nu as well, and the fact that .nu currently uses RSA-SHA1-NSEC3-SHA1,the same arguments about the security of SHA-1 that applied for .se apply for .nu as well. Beyond that .nu use a 2048 bit KSK and a 1024 bit ZSK. A key length of 1024 bits for RSA is no longer considered secure and won’t be supported in the latest firmware update for our HSM hardware.
When upgrading .se to RSA-SHA256 we got only two questions, but from almost everybody ”Why RSA? and/or Why not ECDSA?”
This time we intend to go with ECDSA, specifically we want to roll to algorithm 13, ECDSA Curve P-256 with SHA-256. Our reasoning is that we do not need the additional security of P-384 and that the Ed curves are to young.
We do have reliable data from Geoff Huston (APNIC) that resolvers in Sweden support ECDSA.
From August to December 2017 the measurements show some fluctuation in validation. With max in August at 90% and low in September at 50%. But the graphs show that almost all validators validate RSA and ECDSA. And the numbers fluctuate in the same way all the time. This indicates that resolvers will validate ECDSA if they validate at all.
Unfortunately couldn’t we find any data on support for Ed25519 or Ed448.
To be or not to be?
We also had a discussion about the further usage of NSEC3. NSEC3 is more complex and makes it harder to debug possible errors. On the other hand, we are already running NSEC3 and haven’t had any problems. To keep the necessary changes to a minimum we decided to stay with NSEC3, even though we publish our zone file.
Do you think this is reasonable? Should we roll to Ed448? Let us know what you think would be the best move forward.