http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01
I really wish that the ZSK/KSK division in terminology was replaced
by SEP and non-SEP. That is the "real difference" (based on there
being an SEP bit in the key flags, not a KSK/ZSK bit).
It's possible that a ZSK is also an SEP, the rules for SEP change
then apply to the ZSK.
2.3. Comparison of Rollover Methods
...
Pre-publication is more complex - introduce the new key, one TTL
later sign the records, and one TTL after that remove the old key.
However, the amount of DNSSEC data is kept to a minimum, hence
reducing the impact on performance.
This above paragraph is missing something. "and one TTL after that"
should be replaced with "and one TTL after replacing all of the old
signatures with new signatures".
(To make this a bit more clearer:)
From
and one TTL after that
To
and one TTL after replacing all of the old signatures with new signatures
-------------------------------------------------------
The time to replace all of the old signatures with new signatures
grows with the size and churn of a zone. It some cases it will be
done in a flash, in some on the order of a week.
2.3's second paragraph should read
Pre-publication is more complex - introduce the new key, one TTL
later sign the records, and one TTL after replacing all of the old
signatures with new signatures remove the old key. However, the
amount of DNSSEC data is kept to a minimum, hence reducing the impact
on performance.
Later on,
3. Zone-Signing Keys
3.1. Key Timeline
...
Event 6: while the current ZSK is still active, its successor becomes
ready. From this time onwards, it could be used to sign the zone.
From this time onwards, signatures generated by the predecessor are
replaced with newly generated signatures with the successor until all
of the predecessor signatures are removed. In addition, any new
signatures required as a change to the zone contents are generated
with the successor.
(The span of time from Event 6 to Event 7 might not be "trivially small.")
One general thought, IMHO, reducing the number of flash-cut events in
favor of gradual changes is desirable for stability and scalability
reasons. In a way, a zone could be seen in a state of continual key
change.
3.2. Key States
An alternative way of considering the key timeline is to regard the
key as moving through a set of states, the state transitions being
determined by time. The state transition diagram is linear and is
shown in Figure 2:
+-----------+ +-----------+ +-----------+
Start ---->| Generated |----->| Published |----->| Ready |
Tgen +-----------+ Tpub +-----------+ Trdy +-----------+
|
+-----------+ |
+------------| Active |<-----------+
| Tret +-----------+ Tact
V
+-----------+ +-----------+ +-----------+
| Retired |----->| Dead |----->| Removed |
+-----------+ Tdea +-----------+ Trem +-----------+
Figure 2: ZSK State Diagram.
The state diagram omits "Exposed" and "Lost". By "exposed" I include
a few failure states:
1) The key is witnessed by an unauthorized entity (i.e., exposed)
2) The key is reverse engineered via crypto-analysis (by James Bond maybe)
3) The key is found in a dictionary attack (I generate key pairs and
match the public one)
4) etc.
By "lost" I mean:
1) The (lone) disk is it on crashed (or all disks it was on crashed).
2) Someone left the laptop in the airport lounge and it was destroyed
by the authorities.
3) Olafur's daughter did a "sudo rm -fr /" to revenge Dad's trip to
the IETF some years back. (No, she just tripped the power cord at
home - but it could have been worse!)
I would draw lines from Published, Ready, Active, and even Retired to
Exposed and Lost. Then from Exposed to Retired and from Lost to
Dead. Just because a key is compromised (exposed) doesn't mean all
uses of it is bad. Don't screw over 95% of the population that the
attack isn't directed at to save the 5% that is hit.
4.5. Key States
The key states for a KSK during the rollover are identical to those
in Figure 2.
I disagree with that. You need a state that represents "I asked the
parent to change but they haven't responded" and a state "I told a
gaggle of TARs I am changing and am waiting for them to catch up."
The states for SEP differ because you are waiting on external
entities to react to events you generate. For SEP and RFC 5011, the
difference between "Exposed" and "Lost" is profound - you can't "sign
the revoked key" if you have lost the private key.
5. Algorithm Considerations
The preceding sections have implicitly assumed that all keys and
signatures are created using a single algorithm. However, [RFC4035]
(section 2.4) states that "There MUST be an RRSIG for each RRset
using at least one DNSKEY of each algorithm in the zone apex DNSKEY
RRset".
The "however" is an incorrect linkage... The first sentence has no
bearing on the second. ;) Perhaps the second sentence ought to be
"Nevertheless, a zone may use multiple algorithms for DNSSEC, or even
be in transition from one algorithm to another over time." (The
latter is where I thought you were going - algorithm change.)
Except in the case of an algorithm rollover - where the algorithms
used to create the signatures are being changes - there is no
relationship between the keys of different algorithms. This means
that they can be rolled independently of one another. (Indeed, the
keys for each algorithm could, if desired, have different TTLs.) In...
Keys are all in the DNSKEY RRset, regardless of algorithm - they have
to have the same TTL. RRSIGs are supposed (as in SHOULD) to be the
same as the data they cover.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
