Hi Nils!
Thanks for your response!
The reasons for occasionally rotating keys should be obvious: Even with keeping all key material on a secure system here in Germany, with every additional day of usage the chances rise that either your system is compromised or some cryptographic threat renders existing keys insecure. So IMHO deSEC is heading towards a situation where all keys will need to be rotated at once. That would be a nightmare for everyone involved. Now this situation may not come up for a few years if everything goes well. But eventually it will happen.
Once you accept the basic need for key rotation, doing this somewhat regularly, and hopefully fully automated, ensures that the mechanism is in place and working. Whereas currently your clients will set up their domains once, possibly fighting their registrar to get the DS records into the parent domain and probably having forgotten what steps to take when this situation pops up unexpectedly in the future.
Now all that said, I do realize the difficulty of interfacing with all the registrars and/or owners of the parent domains (often TLDs). So getting a universal and automated system up and running would probably require some standards (RFC8078 sounds promising) as well as wide adoption of those standards. So this will take time…
Suggestion:
As an intermediate solution would a process be acceptable where the client triggers the process for a domain? That would allow those clients who are already able to script the registrar/parent domain side to get the benefit of regular key rotation. Alas, for users not able to do this this would not help. They would have to wait for a future universal solution.
This solution would only be needed for keys used to sign DNSKEY RRSets (KSK, CSK).
Also, if separate ZSK are used, then their rotation could be handled internally by deSEC. So changing deSEC from CSK to KSK+ZSK would at least partially mitigate the security risks associated with long key lifetimes.
Roughly, this suggested mechanism could look like this:
Prerequisite: A client domain set up correctly for DNSSEC, including the correct DS record in the parent zone.
- Step 1: Client user calls deSEC API with a request to initiate the key rotation process. This will cause deSEC to generate a new key and add the associated public key as an additional DNSKEY record. (Of course the RRSIG DNSKEY would have to be regenerated after adding the RR.) Depending on key usage (KSK, ZSK, CSK) all of the associated RRSets are also signed using the new key with the RRSIG RRs added in addition to the existing ones. So for a CSK all RRSets would get a second RRSIG.
- Step 2: Client user extracts the DS (or DNSKEY, depending on what is needed) for the new key using the deSEC API.
- Step 3: Client user adds the new DS to the parent domain, using whatever mechanism the registrar/parent domain owner offers. (Worst case this would be a manual process, but hopefully some API exists to automate this.)
- Step 4: Once the new DS is added to the parent domain and all relevant TTLs have expired, the client user calls the deSEC API again to finalize the key rotation. This will cause deSEC to remove the old DNSKEY and the associated RRSIG records.
Steps 1-4 would be automated on the client side as much as possible and scheduled to run at appropriate intervalls, e.g. every 6 weeks.
A number of issues would need to be taken into account:
- Probably only one key rotation request should be allowed for a client domain at a time.
- The API should include a mechanism to cancel a pending key rotation request.
- For completeness the API might include a call to check the key rotation status. I.e. if step 1 was done then the call would return information about the new key, a transaction ID, timestamp, etc. Before step 1 happened or after step 4 the call would simply return a result of “No key rotation pending.”
- Possibly a timeout would be needed to cancel very old pending key rotation requests (step 1 without step 4).
- It might be a good idea to limit the frequency of key rotations to some reasonable value.
Thanks!
fiwswe