DNSSEC key rollover failure

[Mark Andrews]

In message <7610864823C0D04D89342623A3ADC9DE1B022E8D at hopple.countryday.net>, "Sp
ain, Dr. Jeffry A." writes:
> > And now, as July 1 has passed and July 9 approaches, can you share a 
> > summary of what you found? Thanks.
> > -- 
> >     Offlist mail to this address is discarded unless
> >     "/dev/rob0" or "not-spam" is in Subject: header
> 
> On June 10, our zone countryday.net running on a bind 9.8.0 server began
> an automatic key rollover process, the zone having been configured with
> "auto-dnssec maintain."  The two original ZSKs 02750 and 33722 had been
> published on March 12. ZSK 02750 became active on March 16, and the zone
> was automatically signed with it. The third ZSK 26522 was published on
> June 10, but is not due to become active until September 12. The second
> ZSK 33722 became active on June 14, and the first ZSK 02750 became
> inactive on June 15. Checking the zone on June 17 showed that ZSK 33722
> had signed the SOA record but nothing else. Signatures from ZSK 02750 were
> on the other records and due to expire on July 9. However, ZSK 02750 was
> scheduled to be deleted on June 29. To avoid deleting ZSK 02750 before all
> of its signatures had been removed and replaced by those from ZSK 33722, I
> used dnssec-settime to change the deletion date of ZSK 02750 to July 14.
> On July 1, as Phil Mayers had predicted, bind re signed the entire zone
> with ZSK 33722, and those signatures are valid until July 31. The only
> signature remaining from ZSK 02750 is on the DNSKEY RRSet, and it is due
> to expire on July 14. From checking the zone periodically over the past
> couple of weeks, it appears that DNSSEC remained intact. The current
> status is shown at http://dnsviz.net/d/countryday.net/dnssec/.
> 
> When I originally set up DNSSEC, I referred to the web site "Practical
> DNSSEC Setup: How to Implement DNSSEC" at
> http://www.dnssec.net/practical-documents. One of the referenced documents
> is "Good Practices Guide for Deploying DNSSEC" at
> http://www.enisa.europa.eu/act/res/technologies/tech/gpgdnssec. On page 12
> of this PDF document, the authors make recommendations for key rollover
> timing, including a recommendation of a two-week interval between the
> inactivation and deletion dates (retirement time) for ZSKs.

The 2 weeks assumes that all records are re-signed when the new key
is activated and the old signatures removed.  Named re-signs as
they fall due as it incrementally re-signs the zone.  This is
important when you have very large zones being updated over small
links.

> I had adopted this two-week recommendation, but it now appears that this
> isn't long enough. As I now understand the behavior of bind 9.8.0, it would
> be possible for an RRSet to be signed using a certain key just prior to its
> inactivation date. That RRSIG would be valid for 30 days, and resigning with
> a different, currently active key would normally occur after 3/4 of that
> interval or 22.5 days. Thus the original key must not be deleted for 22.5
> days plus the TTL of the RRSIG records (one hour in my case).

The old key can be deleted once all rrsets signed with it have timed
out of the system.  If the maximumun ttl in the zone is 1 hour then
approximately 1 hour after the last rrset has been re-signed with
the new key you can delete the old key.  The two weeks is a
conservative value for those that don't want to do the maths.

> I don't know if the signature validity interval of 30-days or the resigning
> fraction of 3/4 is configurable when auto-dnssec maintain is in effect. The
> only statement about this issue that I could find in the bind reference
> manual is the "-e"  and "-i" parameters of dnssec-signzone. What do others
> know about this issue?

It is configurable.  See sig-validity-interval.  There is a optional
re-signing parameter.

> Phil Mayers referred me to the document "DNSSEC Key Timing Considerations"
> at http://tools.ietf.org/pdf/draft-ietf-dnsop-dnssec-key-timing-02.pdf.
> Section 3.2.1 on the Pre-Publication Method for ZSK rollover is relevant
> here, in particular the description of Event 8 on page 11.  It refers to the
> "delay needed to ensure that all existing RRSets have been re-signed with
> the new key," but does not quantify this.  From what I understand, it is 30
> days * 3/4 = 22.5 days for bind 9.8.0.

Yes.
 
> It seems to me that there is no harm in having a retirement time a little
> too long and major problems in having it too short. My plan at this point is
> to use 35 days. I would certainly welcome further advice from the DNSSEC
> experts on the list. Thanks. Jeff.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org