Fwd: Key Coverage Tool Proposal

Tue Mar 13 20:16:03 UTC 2012

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.
-- 
/***************************************\
* ISC offers support on many		*
* of its products, including BIND 9.	*
* If you depend on it, depend on us!  	*
\***************************************/

Curtis Blackburn
<ckb at isc.org>
Software Engineer, 
BIND Development Team
Internet Systems Consortium

Begin forwarded message:

> From: Stephen Morris <stephen at isc.org>
> Subject: Key Coverage Tool Proposal
> Date: March 13, 2012 12:41:16 PM CDT
> To: Blackburn Curtis <ckb at isc.org>
> 
> Curtis
> 
> I'm afraid that I'm not subscribed to the bind-workers list, so I've
> cut and pasted the email about the key coverage tool from the list
> archives and am replying to you directly.
> 
>> this is a work in progress and we are looking for feedback to make 
>> this a better tool.
>> 
>> As an administrator, I want a tool that allows me to be able to 
>> make sure that all the activation dates for my keys are valid.
> 
> Just as clarification, is this tool only advisory (i.e. it looks at
> the state of the zone and reports what it sees) or active (it actually
> handles the rolling of the key)?
> 
>> This tool will be written in python.
>> 
>> This key coverage tool: - ensure that there are no gaps in key 
>> coverage - make sure that keys are published in your zone at least 
>> 1 ttl before that key is to be published
> I think the second "published: should be "used to sign records in the
> zone".
> 
>> - use refresh rate from SOA - e.g., ttl+refresh  to insure that
>> key is published soon enough
> 
> I suggest checking the DNSOP key timing draft
> (http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing) for
> timing considerations concerning the rolling of keys.  The draft has
> expired, but I am planning on resurrecting it immediately after this
> IETF.  In particular, there are additional intervals that need to be
> considered, over and above the TTL.
> 
> (There is also a -bis version in preparation, see
> tools.ietf.org/html/draft-mekking-dnsop-dnssec-key-timing-bis)
> 
>> The following is a list of things that the tool will have to be 
>> able to gracefully handle whether by emitting a warning, an error, 
>> or information:
>> 
>> we expect to see one or more algorithm within one algorithm we 
>> expect to see both a KSK and a ZSK - usually these will be 
>> different keys (warn if not?)
> 
> Informational message may be, but not a warning.  RFC 4641bis
> (http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis) discusses the
> ZSK/KSK split and the idea of a single type signing scheme.
> 
>> - usually the KSK will have the SEP flag (warn if not?)
> I think warn.  RFC4641bis suggests that the SEP flag should be set on
> the KSK and on the key used in a single-type signing scheme.
> 
>> - more than one KSK and ZSK is allowed
>> 
>> keys can be signed or unsigned keys can be published or unpublished
>> keys can be active or inactive first look for any period of time
>> where a key becomes inactive -error if a key following it would not
>> be signed -error if a key following it would not be published
>> -error if a key following it would not be active
> 
> I'm not clear what is meant by signed/unsigned here.  Do you you mean
> that the DNSKEY is published in the DNSKEY RRset but the set is signed
> or not signed?
> 
> (I presume that published and active have the same meaning as the key
> timing draft.)
> 
>> warn if a ZSK remains published after it's been deactivated
> 
> Assuming that "active" means "used to sign the zone", then there is a
> retirement period for keys; they need to remain in the zone until all
> RRs with signatures created by them have expired from caches.
> 
>> -do not error as long as at least one ZSK is published and active
>> 
>> in the case of complex key rolls involving both KSKs and ZKSs -we 
>> will need to alert the user of the time of the KSK roll -the user 
>> will need to ensure that the new DS is in place in the parent zone 
>> (can we check this with the tool?)
> 
> I advise checking the DS record with the tool.  The DS record will
> usually be in a zone under different administrative control from the
> zone holding the KSKs, so processes and timescales for changes may be
> different.
> 
> Note though that you can:
> a) add a DS to the parent, change the KSK and remove the old DS record
> b) add a new KSK to the zone, change the DS in the parent, remove the
> old KSK from the zone
> c) add the new DS and KSK at the same time, wait a bit, remove the old
> DS and old KSK at the same time.
> 
> (see section 3.3 of the key timing draft.)
> 
>> in the case of zones with more than one algorithm in use -???
>> 
>> In the case of a zone being rolled from one algorithm to another 
>> -???
> 
> Have a look at 4641bis for considerations about algorithms.
> 
> 
>> private section is extensible - ensure that when the .private part 
>> of KSKs and ZSKs is added to things continue to work
> 
> Not sure what is meant by this.
> 
>> 
>> other possible scenarios that the tool may run into:
>> 
>> -corrupted fields/other bad input
> 
>> -a zone with just KSKs -a zone with just ZSKs
> Strictly speaking, the SEP flag is just a flag of convenience and the
> DNSSEC protocol makes no distinction between ZSK and KSK.
> 
>> -deliberately going insecure
> This will mean removing the DS record from the parent.  The zone will
> have to continue to be signed until the DS record has expired from
> caches, else the zone risks being tagged as bogus.
> 
>> -nsec to nsec3 transitions -vice versa
> Also add the possibility of a zone with multiple NSEC3 chains.
> 
>> -non-readable keys -non-writeable keys-(I do not think that this 
>> will be an issue) -revoked keys -bad key directory/other arguments
>> -inaccessible zone file -it is possible to do some of the
>> checking without using the zone file at all,
> There is a distinction between the zone file - what should be in the
> zone - and what is actually in the zone.  The simplest solution might
> be to just do the checking against the zone served by a particular
> nameserver.  To check a zone file, load it into a locally-running copy
> of BIND and check against that.
> 
>> do we want to do that? -what if the key rolls havent taken place
>> on time
> It depends how the key rolling system is set up.  For example, it is
> entirely possible that the system is set to run at once a day, in
> which case we would expect events to occur up to 24 hours after they
> were scheduled (e.g. the system runs at 18:00 and the event is
> scheduled for 18:00:01; in this case, it would not occur until 18:00
> the next day).
> 
> Stephen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20120313/23bdaac3/attachment.html>