I have been tying to find out if there are any recommendations about the various intervals in a keys life, e.g. how long between publication and activation? Ditto for activation to inactivation? Ditto for inactivation to deletion?
I Googled it, but the info out there is not very helpful; Microsoft; 7 - 7300 days (recommends 755 days) for KSK and 7 to 1875 days (recommends 90 days) for ZSK. ENISA 365-1460 days (recommends 1 yr) KSK, 1 yr for ZSK NIST 1 - 2 yrs for KSK, 1 - 3 m for ZSK. Plus a lot of other recommendations ranging from 1 to 5yrs for KSK and from 14 days to 2 yrs for ZSK.
I am currently think along the lines of 90 days from Creation to Deletion with active life of 30 days for ZSKs. 420 days from Creation to Deletion with an active life of 360 days for KSKs. Are these reasonable?
Plus, what are the "names" for the various intervals, there does not seem to be a consistent naming convention, the various points in the timeline seem to have fairly standard names but not intervals. What is the period from creation to publication called? ditto publication to activation, activation to inactivation, inactivation to deletion?
Am 18.01.2015 um 20:32 schrieb John john@klam.ca:
I have been tying to find out if there are any recommendations about the various intervals in a keys life, e.g. how long between publication and activation? Ditto for activation to inactivation? Ditto for inactivation to deletion?
I Googled it, but the info out there is not very helpful; Microsoft; 7 - 7300 days (recommends 755 days) for KSK and 7 to 1875 days (recommends 90 days) for ZSK. ENISA 365-1460 days (recommends 1 yr) KSK, 1 yr for ZSK NIST 1 - 2 yrs for KSK, 1 - 3 m for ZSK. Plus a lot of other recommendations ranging from 1 to 5yrs for KSK and from 14 days to 2 yrs for ZSK.
I am currently think along the lines of 90 days from Creation to Deletion with active life of 30 days for ZSKs. 420 days from Creation to Deletion with an active life of 360 days for KSKs. Are these reasonable?
Plus, what are the "names" for the various intervals, there does not seem to be a consistent naming convention, the various points in the timeline seem to have fairly standard names but not intervals. What is the period from creation to publication called? ditto publication to activation, activation to inactivation, inactivation to deletion?
I asked the same questions DNS specialist. His answer was that it depends :-)
I have written scripts for PowerDNS that rotate the ZSK every month (1st to 3rd of each month; three days, three steps). I think I will keep the KSKs for about 4-5 years (currently no scripts)
Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com
Hello John,
John wrote:
I have been tying to find out if there are any recommendations about the various intervals in a keys life, e.g. how long between publication and activation? Ditto for activation to inactivation? Ditto for inactivation to deletion?
have a look at "DNSSEC Key Rollover Timing Considerations" (an IETF draft document that might be promoted to an RFC later) --> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-06
Also, read RFC 6781 https://tools.ietf.org/html/rfc6781
I Googled it, but the info out there is not very helpful; Microsoft; 7 - 7300 days (recommends 755 days) for KSK and 7 to 1875 days (recommends 90 days) for ZSK. ENISA 365-1460 days (recommends 1 yr) KSK, 1 yr for ZSK NIST 1 - 2 yrs for KSK, 1 - 3 m for ZSK. Plus a lot of other recommendations ranging from 1 to 5yrs for KSK and from 14 days to 2 yrs for ZSK.
there are no technical reasons to roll the DNSSEC keys, but (security-) policy reasons. The policy will be different between sites and organizations.
I am currently think along the lines of 90 days from Creation to Deletion with active life of 30 days for ZSKs. 420 days from Creation to Deletion with an active life of 360 days for KSKs. Are these reasonable?
Some of the times depend on the propagation times between the master DNS server and the slaves (zone-transfer), the rollover-type (pre-publication or double-signing) and the time-to-live (TTL) of the records in the DNS zone.
Without knowing these values, I cannot say if the times are reasonable. They *look* reasonable.
Usually one starts with the life-times of the KSK and ZSK, and calculates all the other time-values from there (prepublication, activation, deactivation, deletion). It is good practice to also calculate some buffer times.
Plus, what are the "names" for the various intervals, there does not seem to be a consistent naming convention, the various points in the timeline seem to have fairly standard names but not intervals. What is the period from creation to publication called? ditto publication to activation, activation to inactivation, inactivation to deletion?
the standard "names" are in RFC 6781 https://tools.ietf.org/html/rfc6781
Best regards
Carsten
On 1/19/2015 7:21 AM, Carsten Strotmann wrote:
Hello John,
https://tools.ietf.org/html/rfc6781
the standard "names" are in RFC 6781 https://tools.ietf.org/html/rfc6781
I read them both the draft, and the RFC. A little like eating saw dust, but if you want to make sure thinks are unambiguous I suppose that's inevitable.
Why a formal period between "ready" and "active", surely if the publishing period is correctly chosen then a key is activated when ready. Similarly when a key has reach the end of its retirement and is dead, surely it should be removed from the system asap. The more junk there is lying around the greater the likely hood of error.
Regards
On 23/01/15 04:50, John wrote:
Why a formal period between "ready" and "active", surely if the publishing period is correctly chosen then a key is activated when ready. Similarly when a key has reach the end of its retirement and is dead, surely it should be removed from the system asap. The more junk there is lying around the greater the likely hood of error.
The time period between "ready" and "active" is the allow for the key to be returned in DNSKEY RR without that key actively being used in signing. This prevents a caching resolver being caught between a key rotation where it ends up with the old set of DNSKEY cached, and RRs signed with a new key not in that set.
The same mechanism can also be used to have an key ready for emergency rotation. They key is already published and can be used for signing immediately, rather than waiting for TTLs.
At the other end, the time between active and unpublished is to allow for resolvers to be able to validate their old signed RR with the old DNSKEY until TTL for everything has passed.
On 1/22/2015 8:32 PM, Ted Cooper wrote:
On 23/01/15 04:50, John wrote:
Why a formal period between "ready" and "active", surely if the publishing period is correctly chosen then a key is activated when ready. Similarly when a key has reach the end of its retirement and is dead, surely it should be removed from the system asap. The more junk there is lying around the greater the likely hood of error.
The time period between "ready" and "active" is the allow for the key to be returned in DNSKEY RR without that key actively being used in signing. This prevents a caching resolver being caught between a key rotation where it ends up with the old set of DNSKEY cached, and RRs signed with a new key not in that set.
The same mechanism can also be used to have an key ready for emergency rotation. They key is already published and can be used for signing immediately, rather than waiting for TTLs.
I thought that was what the Publish interval was all about? Why three periods, /inception - publish/publish - ready/ready - active/? I could see ready state for a standby key, maybe? However, as these periods are not bound to a length of time, but to occurrence of the their start and end events. So a standby key can be defined as any key that has been published but not activated.
At the other end, the time between active and unpublished is to allow for resolvers to be able to validate their old signed RR with the old DNSKEY until TTL for everything has passed.
That I understand, but why the period from unpublished to dead. Surely once a key has reached unpublished it is dead and should be deleted asap! So why the define a period between unpublished and dead?
John Allen
participants (4)
-
Carsten Strotmann -
Christian Rößner -
John -
Ted Cooper