KSK key rollover and DS update

Managed DNS Hosting
1

Hi!

I’m new to deSEC and maybe I’m missing some documentation? But I was wondering about the Key Signing Key (KSK) rollovers, which I presume are happening occasionally, and the associated need to update the DS record in the parent domain.

So first question: Will the DNSKEYs used as KSKs be periodically rotated by the deSEC system?

If so it becomes necessary to also change the DS record in the parent domain when a new key becomes active. Since anything related to the parent domain (e.g. glue NS records and DS records) seems to be outside the scope for deSEC how is this supposed to work?

Note: I would normally expect a process similar to the following for a KSK rotation:

  1. A new DNSKEY with flags set for a KSK is generated and added to the zone. (The previous KSK is still present and used to to sign the DNSKEY RRSet.)
  2. The new KSK is used to generate an additional RRSIG record signing the DNSKEY RRSet. So there would be 2 RRSIG records for the DNSKEY RRSet at this point. But, if the initial setup was done correctly then the DS record in the parent domain would still point to the old KSK and thus the RRSIG associated with the old KSK would be used to verify the DNSKEY RRSet.
  3. ??? Some mechanism would need to trigger getting a DS record for the new KSK and adding it to the parent domain.
  4. Wait for the relevant (DNSKEY) TTLs to expire.
  5. Remove the DS record for the old KSK from the parent domain.
  6. Wait for the relevant (DS) TTLs to expire.
  7. Remove the old KSK and the RRSIG using the old KSK from the zone.

Thanks!

BTW: Given what I have seen so far with other DNS providers regarding DNSSEC support, deSEC seems like a great idea! Thanks for building and maintaining this :grinning: :+1:

fiwswe

2

I just noticed that domains hosted by deSEC only have a single DNSKEY, i.e. no separation between KSK and Zone Signing Key (ZSK).

While this makes no difference wrt. the need for periodically rotating the key, it could affect the frequency of this happening? Usually the reason for separating the KSK from the ZSK is to allow for different rotation periods and/or different cryptographic algorithms for the two types. But I see no technical reason for not using the KSK as the ZSK.

So basically my question remains: Is the key rotated regularly and if so how should the resulting DS update be handled?

3

Dear fiwswe,

thanks for your post and welcome to deSEC!

No, you did not overlook something in the docs - currently, we have no standard way of key rotation. The reason behind this is the cumbersome rotation of DS records, which (currently, mostly) is business that must be done by our users with their registrars. Many registrars have only limited or none support for this. Even just setting the DS records for the first time is not widely supported. For a somewhat up-to-date overview on support, please refer to Roth et al., Table 2. We can observe that only a minority of our users manages to set up DS records for their zone correctly, which somewhat confirms the findings of Roth et al.

That being said, this problem has been recognized by the DNSSEC community and proposals for alleviation are underway, notably the CDS/CDNSKEY proposals of RFC8078. We plan to support this (status of implementation on GitHub), but our development
ressources are limited and as CDS/CDNSKEY support on the registrar side is still very limited, this is not top-priority to us.

We’re also thinking about checking our user’s domain status every once in a while, and potentially sending reminders for setting up DS records. A key rotation process (without RFC8078’s CDS/CDNSKEYS) may be implemented along those lines, with email reminders of what needs to be done on the user side.

While you absolutely right that eventually deSEC must implement some mechanism for efficient key rotation, since you’re asking about it I am wondering if there is an important reason to increase the priority on this issue for deSEC?

Thanks,
Nils

4

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

5

Dear fiwswe,

I agree with what you’ve written, and your proposal seems like a good strategy on how to go forward. One limitation may be that the process should be compatible to RFC8078, which you didn’t explicitly mention.

Anyways, deSEC only has limited resources available for development, and we currently want to focus our attention onto more pressing issues such as two-factor authentication, streamlining of the singing process on our servers, and the fast replication of DNS information onto our DNS frontend servers. But eventually, we will come back to this.

Also, deSEC is a community-project, so any contribution, including an implementation of your proposal, receives a warm welcome on GitHub.

Best,
Nils

6

Hi Nils!

As for RFC8078 compatibility, I agree that this should be a consideration. Though I would argue that any solution that does not block a future RFC8078 implementation in any way would be acceptable as a first step.

From a rough first scan of RFC8078 (and RFC7344 which it is based on) I see that the concepts are slightly different than my proposal. Although I suppose that the proposed deSEC API command to trigger generating a new key (step 1) could also trigger the addition of CDS and CDNSKEY records into the zone. In fact that should be fairly easy to implement and probably would not have any negative impact on any existing systems. Steps 3 and 4 of my proposal may need to take into consideration that an RFC8048 mechanism might also be at work and back off if that is detected.

I saw that PowerDNS seems to be able support CDS and CDNSKEY RRSets already (https://doc.powerdns.com/authoritative/domainmetadata.html#publish-cdnskey-publish-cds). Is this in use for deSEC? If so are there any domains where these RRSets can be seen (for testing)? I tried the following without getting any records:

$ dig +dnssec +multi @ns1.desec.io desec.org CDS
$ dig +dnssec +multi @ns1.desec.io desec.org CDNSKEY

The one thing that strikes me as questionable about RFC8078 is the need for some entity to regularly poll for CDS/CDNSKEY records. There seems to be no way to actively notify the parent domain of changes to these RRSets (unless my quick scan of the RFCs missed something). This would cause some additional base load on authoritative name servers as a reasonable poll frequency would be a compromise of responsiveness to changes and DNS traffic. Polling is generally not a good strategy, only used as a last resort. OTOH this might make RFC8078 more likely to be adopted and it allows for intermediates to act instead of the parent domain itself. E.g. for cases where the registrar is separate from the DNS hoster, as with deSEC hosted domains, a savvy registrar might automate getting the DS RR into the parent domain. But what happens when a registry like DENIC also starts to implement RFC8078?

As for helping out, I also agree. For myself I don’t have any experience with Docker or PowerDNS and only minimal Python experience, not that I am opposed to learning. But It would probably take a while to get up to speed and set up a suitable development and testing environment. As a first step I’d be willing to help with a more detailed specification. Though thoroughly understanding the current setup would probably be a good thing start start off with. To that end where should setup/development related discussions, questions, etc. be located? This forum or GitHub? Or somewhere else?

Thanks!

fiwswe

7

Hi,

As far as your last question is concerned, dev questions best go to GitHub.

deSEC has been supporting CDS/CDNSKEY records for a few weeks now. We still don’t have a way to trigger key rotation, but it is on the roadmap for later. (So why do we have it? It enables multi-signer models, RFC 8901.)

Stay secure,
Peter

8

Good news, thanks!

fiwswe