.SE KSK Algorithm Rollover
At The Swedish Internet Foundation we are very security concious. We were the first TLD in the world to sign their zone with DNSSEC. Being on the forefront of things is a nice feeling, but sometimes you get to feel the pain of it. Having signed so early means that at the time there was only one algorithm to use, RSA-SHA1. The security of SHA1 has been discussed in the community for some time now and even though there is no need for panic, there are more secure alternatives available today.
When you look at the IANA algorithm list the situation is somewhat diffrent from october 2005. There are a lot of algorithms to choose from. Some are clearly inappropriate, like RSAMD5, but how does one choose between all the others? The IETF has tried to agree on some guidance in the question, but no definite answer has been reached. (https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-algorithm-update-wouters-00.pdf)
Sweden has one of the highest percentage of validating resolvers in the world, and we would like to keep it that way. Unfortunately we do not have information on all the validating resolvers in Sweden and their crypto capabilities. That requires us to make a conservative choice and eliminates all ECC algorithms.
There is no need to choose any of the NSEC3 algorithms, since we publish our zone file anyway. This leaves us with a short list of RSA-SHA256 and RSA-SHA512.
The added key and signature size of SHA512 didn't really attract us and as the root is running on RSA-SHA256 we don't believe RSA-SHA512 would be worth the effort.
We have decided to run with RSA-SHA256 for the time being.
That's how we roll
Ripe NCC has some experience with algorithm rollovers and published a very informative blog post about it.
The short verion is that you must follow these steps
- Sign with new ZSK, insert RRSIG in zone
- Insert new KSK and ZSK in zone
- New and old KSK sign DNSKEY set
- Publish new DS in parent and remove old DS from parent
- Drop old KSK, ZSK and RRSIG from zone
Between all the steps wait at least two times the TTL of your zone.
We will use OpenDNSSECs automatic algorithm rollover. It uses a slightly different approach.
- Update KASP database
- Generate new keys
- OpenDNSSEC will start using the new keys, publishing KSK, ZSK and double signing all records
- Publish new DS in parent and remove old DS from parent
- Drop old KSK, ZSK and RRSIG from zone
Sidelines
To make the whole process easier on use we have upgraded our infrastructure to run OpenDNSSEC 2.1.3. Not only is this the shiny new version of OpenDNSSEC. This version comes with the capability to roll over algorithms.
We will use OpenDNSSECs automatic roll over capabilities.
What if?
If things go south? We actually do have two instances of OpenDNSSEC. We will perform the rollover on one of them, while the other instance will standby and sign the .SE zone with no changes. So we will be able to fall back in case of any failure.
Timeline
The time line is preliminary. We will start the rollover on the 28th of November. But the time line after that is dependend on many factors, not all of which are under our control.
Update OpenDNSSEC to version 2.1 (support for automatic algorithm rollover)
Update KASP database with new policy
Create new KSK and ZSK in HSM
Start Algorithm Rollover in OpenDNSSEC
Start IANA process to update .SE DS records in the root
Algorithm roll over is done
Update second OpenDNSSEC instance to use new keys
