On 24/07/2012 07:53, Matthijs Mekking wrote:
General comment: this is an improvement.
some comments and suggestions below
The "state" of the key frequently depends on the viewpoint, for example
zone may have key in active state but due to propagation delay some
validators may think the key is Published state.
During transition there different "participants" are in different
states. (I will ignore the case that a validator may have RRsets from
different versions of a zone and thus for RRset A and RRset B the
key states may be different).
The goal of the document is to document this and tell people how long it
takes until all "participants" consider the key to be in the same state.
-----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
Is this "RRSIG" in zone generated by the key ?
- - RRSIG DNSKEY
Why is this needed ?
Key has either RRSIG or not there, the role of the KEY dictates what it
signs.
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.
(this is
I think we should include paths for Revoked keys (RFC5011)
H --> I --> P --> W --> H
| | ^
V V |
+ --> + --------> R
Or the three different paths:
H --> I --> P --> W --> H
H --> I --> R --> H
H --> I --> P --> R --> H
(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]
An alternative way to present this to include the delay until next state
can be entered.
Below I have rewritten part of the representation above to include
the precondition for entering the next state
- Delay: how long to wait for the data to propagate
- Action needed be taken to move to the next state.
DNSKEY --- RRSIG ---- Delay/Action - APPROACH
Published --> Introduced - Hidden - DNSKEY TTL = [Pre-Publish]
--> Hidden - Introduced - MAX TTL = [Double-RRSIG]
Ready --> Propagated - Hidden - Action X = [Pre-Publish]
--> Hidden - Propagated - Action Y = [Double-RRSIG]
Action X = Sign zone with key
Action Y = replace the old key with the new one.
Rather than have a table like this I would prefer to have the
state machine for each approach.
(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?
I like this and think the document should adopt this notation as it is
much easier to express and understand.
Olafur
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
