[DNSOP] Timing of key changes (some things that hit me right away)

[Edward Lewis <[e-mail]>]

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 [phone]

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.