[dns-operations] .FI going insecure for two weeks (!)

[Peter Thomassen]

Hi Shumon,

On 12/17/24 22:13, Shumon Huque wrote:
> Yup, but moving to the new platform using the same algorithm non-disruptively still requires some specific features to be supported (multi-signer ZSK import

Only by the new system; you do not need to touch the old system at all.

In detail, to move to a new platform (without changing the algorithm yet), it is sufficient to

- take the signed zone of the old system, replace the DNSKEY RRset so that it contains both the old ZSK and the new KSK+ZSK, and is signed with the new KSK (call this the "new" zone)*;
- keep all old RRSIGs (except for DNSKEY);
- add the new KSK DS;
- deploy the "new" zone on one of the NS.

You can then observe whether all is fine, and if not, take down that NS and resume normal operation of the old zone. (You can even test that on this NS before announcing its route publicly.) If, as expected, responses of both the new and old zone validate, you can

- add RRSIGs from the new ZSK to the new zone;
- deploy the new zone on more NS;
- eventually take down the old zone, and remove live old DS and RRSIGs, before they expire.

This process does not touch the old system at all, and rollback is possible by simply taking down a route. So it should be very low-risk.

As usual, there's a trade-off; in particular, as the old zone is imported once, regular updates to the zone (in particular, delegation changes) would need to be suspended during the transition. However, most TTLs in .fi are a few hours, so this would be needed for no more than ~a day (or even less with reduced TTLs).

*: For CSK, mutatis mutandis applies, of course.

> - I assume that's what you mean by "additional RSA key")

Only insofar as the new system uses an additional key; not that the old system would have to support (or even know about) that.

> and it's possible these features may be lacking in some platforms.

My point here is that the old system does not need to support any multi-signer stuff, as long as the algorithm isn't changed in the same transition.

Multi-signer capabilities on both systems are only needed if one can't import the old system's signatures into the new one (e.g., when online-signing), or if one wants to make zone changes during the transition.

This is why the above procedure would not work well in a permanent multi-signer setup, which is why I guess RFC 8901 doesn't describe it. (FWIW, I think I first heard of it from Tamás.)

I'm not saying that this should be done; I'm just responding to thoughts about what level of multi-signer support would or would not be required.

> You could deploy a totally new keypair at the new party without cross sharing, but that introduces intermittent validation failures and possible complete failures for resolvers that don't robustly retry queries.

You only need half the cross-share to make it work :-)

Best,
Peter

-- 
https://desec.io/