-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Stephen asked me to send this suggestion we had (surfaced from
discussions) to the list. We would like to have input before the
upcoming IETF meeting.
Modification to the key states
==============================
As you might know, I had this idea of unraveling key states. Instead
of having states that describe the overall state of the key, we would
have states for components of the key. How to divide the key into
components is based on the parts that can be published:
- - DNSKEY
- - DS
- - RRSIG
- - RRSIG DNSKEY
We can call this the representation of the key (which components are
visible in the zone and/or caches). The RRSIG for zone contents and
for the DNSKEY RRset need specifically be split to support a Single
Type Singing Key in a later stadium.
Each component follows a certain publication path. Initially it is
Hidden, it will be Introduced into the zone, it is long enough in the
zone to be Propagated to all caches, it will be Withdrawn from the
zone and it will become Hidden again (as it has expired from caches):
Hidden --> Introduced --> Propagated --> Withdrawn --> Hidden.
(Note: a component could be removed from the zone before it was
propagated, so a transition between Introduced and Withdrawn. The
other way around is also true: A record can be reintroduced before it
had expired from all the caches. The idea is to consider full
rollovers only, so these transitions will be out of scope.)
The overall key states from draft-ietf-dnsop-dnssec-key-timing-03.txt
map (but not one-to-one) to the unraveled key states:
For example, for ZSK Rollovers:
Generated -> (DNSKEY Hidden, RRSIG Hidden)
Published -> (DNSKEY Published, RRSIG Hidden) [Pre-publish]
-> (DNSKEY Hidden, RRSIG Published) [Double-RRSIG]
Ready -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish]
-> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG]
Active -> (DNSKEY Propagated, RRSIG Introduced) [Pre-publish]
-> (DNSKEY Introduced, RRSIG Propagated) [Double-RRSIG]
-> (DNSKEY Introduced, RRSIG Introduced) [Double-Signature]
Retired -> (DNSKEY Propagated, RRSIG Withdrawn) [Pre-publish]
-> (DNSKEY Withdrawn, RRSIG Propagated) [Double-RRSIG]
-> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature]
Dead -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish]
-> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG]
-> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature]
Removed -> (DNSKEY Withdrawn, RRSIG Hidden) [Pre-Publish]
-> (DNSKEY Hidden, RRSIG Withdrawn) [Double-RRSIG]
-> (DNSKEY Withdrawn, RRSIG Withdrawn) [Double-Signature]
(I leave the KSK rollovers as an exercise to the reader ;-) )
So you see, the key states as they are now do not map uniquely to how
the key is presented in the zone. I want to propose that either the
document uses the unraveled key states, or otherwise defines a unique
mapping between the overall key states and the representation of the key.
Also, we should not limit to one key state at a time. For example, a
key can be Published and Active at the same time in my opinion.
- From -03:
Published The DNSKEY record - or information associated with it -
is published in the zone, but predecessors of the key (or
associated information) may be held in caches.
Active The key has started to be used to sign RRsets. Note that
when this state is entered, it may not be possible for
validating resolvers to use the key for validation in all
cases: the zone signing may not have finished, or the
data might not have reached the resolver because of
propagation delays and/or caching issues. If this is the
case, the resolver will have to rely on the key's
predecessor instead.
But both descriptions may be valid at the same point in time. So I
would like to say the key can be Published and Active at the same time.
Finally, I would like to drop "associated information". To keep a
clear definition, a key state should only say something about one key
component. So, the definition for Published would become:
Published The DNSKEY record is published in the zone, but
predecessors of the key (or associated information) may
be held in caches.
or even more simpler:
Published The DNSKEY record is published in the zone.
So, you would get more states, but with simpler descriptions.
To summarize:
1. Use unraveled key states or define a unique mapping between the
overall key states and the representation of the key.
2. A key can have more than one state at a time.
3. Drop "associated information", a key state only says something
about one key component.
Thoughts?
Best regards,
Matthijs
On 07/09/2012 07:13 PM, Stephen Morris wrote:
> After much delay, the -03 version of the key timing draft has been
> submitted. It incorporates a number of comments made on-list and
> privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred
> Hoenes.
>
> Perhaps the most significant change concerns the timing
> considerations related to the introduction of a new KSK (section
> 3.3.4.1).
>
> Stephen
>
>
> On 9 Jul 2012, at 17:29, internet-dra...@ietf.org wrote:
>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> Domain Name System Operations Working Group of the IETF.
>>
>> Title : DNSSEC Key Timing Considerations Author(s)
>> : Stephen Morris Johan Ihren John Dickinson Filename :
>> draft-ietf-dnsop-dnssec-key-timing-03.txt Pages : 33
>> Date : 2012-07-09
>>
>> Abstract: This document describes the issues surrounding the
>> timing of events in the rolling of a key in a DNSSEC-secured
>> zone. It presents timelines for the key rollover and explicitly
>> identifies the relationships between the various parameters
>> affecting the process.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing
>>
>>
>>
There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03
>>
>> A diff from previous version is available at:
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-03
>>
>>
>>
>>
Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ DNSOP mailing
>> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________ DNSOP mailing list
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQDoysAAoJEA8yVCPsQCW5AaYH/iFlHzxxMaUUsds5kW5M2y6J
UANul10z65dWe0Sng335KmalieBFEuaFBugSo0IONazf6Qj8OWQ8OGHCbGKTDqI2
KOIC5z38AAD/BI82ahYUwVMr5u2aQXKFpjQc1yhH6ujvxspa0MWC+Uzzce5vSoQG
I+ubviuWI2Oen4qN8X/FPf3JmagAzlBy87hf+qX6a2E649eXuQPWocfyyQqGXGWZ
jjtkJ8cOp0BPLwf6OQ3HLYIlx6a/ucEsYaGJrzpDQvMjUj8c+nDngg9yoLqp+bxZ
Stp2PpE83gSqRNeDUJRRrP8CtZvtCl4AH48iHa2z5V5OwZ8bxjWGavHWUPSt0fw=
=XiNc
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
