<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Stephen Morris had this to say, and as he is not on the list I (with his permission) am forwarding it, in case anyone has further comment.<br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">-- <br>/***************************************\<br>* ISC offers support on many<span class="Apple-tab-span" style="white-space: pre; "> </span>*<br>* of its products, including BIND 9.<span class="Apple-tab-span" style="white-space: pre; "> </span>*<br>* If you depend on it, depend on us! <span class="Apple-tab-span" style="white-space: pre; "> </span>*<br>\***************************************/<br><br>Curtis Blackburn<br><<a href="mailto:ckb@isc.org">ckb@isc.org</a>><br>Software Engineer, <br>BIND Development Team<br>Internet Systems Consortium</span>
</div>
<div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Stephen Morris <<a href="mailto:stephen@isc.org">stephen@isc.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Key Coverage Tool Proposal</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">March 13, 2012 12:41:16 PM CDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Blackburn Curtis <<a href="mailto:ckb@isc.org">ckb@isc.org</a>><br></span></div><br><div>Curtis<br><br>I'm afraid that I'm not subscribed to the bind-workers list, so I've<br>cut and pasted the email about the key coverage tool from the list<br>archives and am replying to you directly.<br><br><blockquote type="cite">this is a work in progress and we are looking for feedback to make <br></blockquote><blockquote type="cite">this a better tool.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As an administrator, I want a tool that allows me to be able to <br></blockquote><blockquote type="cite">make sure that all the activation dates for my keys are valid.<br></blockquote><br>Just as clarification, is this tool only advisory (i.e. it looks at<br>the state of the zone and reports what it sees) or active (it actually<br>handles the rolling of the key)?<br><br><blockquote type="cite">This tool will be written in python.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This key coverage tool: - ensure that there are no gaps in key <br></blockquote><blockquote type="cite">coverage - make sure that keys are published in your zone at least <br></blockquote><blockquote type="cite">1 ttl before that key is to be published<br></blockquote>I think the second "published: should be "used to sign records in the<br>zone".<br><br><blockquote type="cite">- use refresh rate from SOA - e.g., ttl+refresh to insure that<br></blockquote><blockquote type="cite">key is published soon enough<br></blockquote><br>I suggest checking the DNSOP key timing draft<br>(<a href="http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing">http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing</a>) for<br>timing considerations concerning the rolling of keys. The draft has<br>expired, but I am planning on resurrecting it immediately after this<br>IETF. In particular, there are additional intervals that need to be<br>considered, over and above the TTL.<br><br>(There is also a -bis version in preparation, see<br><a href="http://tools.ietf.org/html/draft-mekking-dnsop-dnssec-key-timing-bis">tools.ietf.org/html/draft-mekking-dnsop-dnssec-key-timing-bis</a>)<br><br><blockquote type="cite">The following is a list of things that the tool will have to be <br></blockquote><blockquote type="cite">able to gracefully handle whether by emitting a warning, an error, <br></blockquote><blockquote type="cite">or information:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">we expect to see one or more algorithm within one algorithm we <br></blockquote><blockquote type="cite">expect to see both a KSK and a ZSK - usually these will be <br></blockquote><blockquote type="cite">different keys (warn if not?)<br></blockquote><br>Informational message may be, but not a warning. RFC 4641bis<br>(<a href="http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis">http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis</a>) discusses the<br>ZSK/KSK split and the idea of a single type signing scheme.<br><br><blockquote type="cite">- usually the KSK will have the SEP flag (warn if not?)<br></blockquote>I think warn. RFC4641bis suggests that the SEP flag should be set on<br>the KSK and on the key used in a single-type signing scheme.<br><br><blockquote type="cite">- more than one KSK and ZSK is allowed<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">keys can be signed or unsigned keys can be published or unpublished<br></blockquote><blockquote type="cite">keys can be active or inactive first look for any period of time<br></blockquote><blockquote type="cite">where a key becomes inactive -error if a key following it would not<br></blockquote><blockquote type="cite">be signed -error if a key following it would not be published<br></blockquote><blockquote type="cite">-error if a key following it would not be active<br></blockquote><br>I'm not clear what is meant by signed/unsigned here. Do you you mean<br>that the DNSKEY is published in the DNSKEY RRset but the set is signed<br>or not signed?<br><br>(I presume that published and active have the same meaning as the key<br>timing draft.)<br><br><blockquote type="cite">warn if a ZSK remains published after it's been deactivated<br></blockquote><br>Assuming that "active" means "used to sign the zone", then there is a<br>retirement period for keys; they need to remain in the zone until all<br>RRs with signatures created by them have expired from caches.<br><br><blockquote type="cite">-do not error as long as at least one ZSK is published and active<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">in the case of complex key rolls involving both KSKs and ZKSs -we <br></blockquote><blockquote type="cite">will need to alert the user of the time of the KSK roll -the user <br></blockquote><blockquote type="cite">will need to ensure that the new DS is in place in the parent zone <br></blockquote><blockquote type="cite">(can we check this with the tool?)<br></blockquote><br>I advise checking the DS record with the tool. The DS record will<br>usually be in a zone under different administrative control from the<br>zone holding the KSKs, so processes and timescales for changes may be<br>different.<br><br>Note though that you can:<br>a) add a DS to the parent, change the KSK and remove the old DS record<br> b) add a new KSK to the zone, change the DS in the parent, remove the<br>old KSK from the zone<br>c) add the new DS and KSK at the same time, wait a bit, remove the old<br>DS and old KSK at the same time.<br><br>(see section 3.3 of the key timing draft.)<br><br><blockquote type="cite">in the case of zones with more than one algorithm in use -???<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In the case of a zone being rolled from one algorithm to another <br></blockquote><blockquote type="cite">-???<br></blockquote><br>Have a look at 4641bis for considerations about algorithms.<br><br><br><blockquote type="cite">private section is extensible - ensure that when the .private part <br></blockquote><blockquote type="cite">of KSKs and ZSKs is added to things continue to work<br></blockquote><br>Not sure what is meant by this.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">other possible scenarios that the tool may run into:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-corrupted fields/other bad input<br></blockquote><br><blockquote type="cite">-a zone with just KSKs -a zone with just ZSKs<br></blockquote>Strictly speaking, the SEP flag is just a flag of convenience and the<br>DNSSEC protocol makes no distinction between ZSK and KSK.<br><br><blockquote type="cite">-deliberately going insecure<br></blockquote>This will mean removing the DS record from the parent. The zone will<br>have to continue to be signed until the DS record has expired from<br>caches, else the zone risks being tagged as bogus.<br><br><blockquote type="cite">-nsec to nsec3 transitions -vice versa<br></blockquote>Also add the possibility of a zone with multiple NSEC3 chains.<br><br><blockquote type="cite">-non-readable keys -non-writeable keys-(I do not think that this <br></blockquote><blockquote type="cite">will be an issue) -revoked keys -bad key directory/other arguments<br></blockquote><blockquote type="cite"> -inaccessible zone file -it is possible to do some of the<br></blockquote><blockquote type="cite">checking without using the zone file at all,<br></blockquote>There is a distinction between the zone file - what should be in the<br>zone - and what is actually in the zone. The simplest solution might<br>be to just do the checking against the zone served by a particular<br>nameserver. To check a zone file, load it into a locally-running copy<br>of BIND and check against that.<br><br><blockquote type="cite">do we want to do that? -what if the key rolls havent taken place<br></blockquote><blockquote type="cite">on time<br></blockquote>It depends how the key rolling system is set up. For example, it is<br>entirely possible that the system is set to run at once a day, in<br>which case we would expect events to occur up to 24 hours after they<br>were scheduled (e.g. the system runs at 18:00 and the event is<br>scheduled for 18:00:01; in this case, it would not occur until 18:00<br>the next day).<br><br>Stephen<br></div></blockquote></div><br></body></html>