Subject: [DNSOP] comments on <draft-mekking-dnsop-dnssec-key-timing-bis-00>

From: "Marc Lampo" <[email-masked]>
Date: Wed, 4 May 2011 10:25:50 +0200 (CEST)

Hello,

Thanks to the "Draft Minutes", sent earlier this week, I found the second
draft I had volunteered to comment on ;-)

Please consider the comments as "constructive" and not negative criticism
!

I appreciate the addition of "conditions", next to various "states",
but I am afraid it makes the text harder to read and understand.
Globally, making the text more accessible would allow more administrators
benefit from its message.
(though I don't have a particular recommendation on how to make it more
accessible, sorry)

Globally :
The title mentions "dnssec key timing", which many might interpret as
"timing considerations when rolling dnssec keys".
But the text goes further then that and addresses "Policy rollover"
(section 4).

My suggestion would be to remove "key" from the title and go for
"dnssec timing considerations" which would then more cover the content.

You could also consider "rollover of NS records".
By which I mean :
A registrar (DNS operator) changes authoritative name servers.
Some "timing considerations" apply also in this case -
a document addressing "dnssec timing considerations" would be the place to
document them.
(and other document(s), describing change of registrar
 could then refer to this document for the timing issues)

1.1 Key Rollover Considerations
"Speed" refers to "fast" and "simple".
--> I would remove "simple" from this description
    and add "simplicity" as separate consideration.

--> In the consideration of "simplicity" I would somehow include that
    "simpler procedures have more chances to be executed without errors".
    (which implies : a complex procedure is also more error prone)

You could also mention that some considerations are actually in conflict
with each other !
The "simplest" way to rollover is not the "fastest" or the "smallest" (in
terms of size of zone files).
--> administrators will have to make a choice.

1.1.1. Key goals
Though this is mentioned to be a major addition with respect to the "key
timing" draft
(in 7. Acknowledgements), I must be missing something here :
--> some clarification/rephrasing seems appropriate !

Some remarks :
1) a "key" has a "goal" ?
A key is used for some purpose (eg ZSK, KSK), but a "goal" ?

2) Three "goals" are listed, two of them of "verbs" ?
Is "activate" or "remove" a goal (a reason to exist) of a key ?
+
"stand-by" key : is it a goal of a key to be "stand-by" ?

I'm afraid this phrasing does not relay the original idea of goals, sorry.

3) Both "activate" and "remove" state : "make validating resolvers
use/forget ..."
This description puts the resolver in an sort of "decision" mode.
In reality, resolvers get whatever authoritative name servers send them,
and work with that.  There is no "initiative" possible, on the resolver
side,
to start using or explicitly forgetting about data.

Overall, my feeling is that the real goal of describing timing is not
described.
What it really comes down to, in my opinion :
(following meant to explain the idea only)
 Validating resolvers may receive one or multiple signatures
 In order to validate signatures, the corresponding keys must be available
(1 DNSKEY "set").
 That DNSKEY "set" also has one or more signatures.
 To complete the chain-of-trust,
 a jump to the parent domain is needed, where there are one or more DS
records available.
 Those DS records have one or more signatures ...

When a resolver starts with a signature,
 it walks up the chain-of-trust but may be on a loose end.
In that case the resolver will start with another signature ...

In my opinion the "goal of describing timing conditions" (and rollover
procedures)
 is to describe approaches where validating resolvers have the least
chance
 of starting with what will turn out to be loose ends
 and oblige to start over : it costs time and CPU cycles ...
)

2.2 Key states Unraveled
--> Though the title is about "Key states", the text also introduces
"states" for RRSIG and DS !

State "Introduced" :
 "The information is introduced and, as a result, may be available in the
zone.
  In this state, there may be resolvers that fetch this information."
I don't think "may" is the correct verb.
If information is, forgive the word, published by authoritative name
servers,
 resolvers *will* pick it up.
--> otherwise : please explain under which conditions a resolver might not
                pick up what it is sent by the authoritative name server.
    (please do not reply with : old information might be in its cache
     Because the whole idea of describing timing considerations
     is precisely about how to limit the period of time
     during which unusable information is in that cache - leading to those
"loose ends")

State "Propagated" :
 (typo only) "... from cache of from the authoritative name server."
              Replace "of" by "or".

State "Withdrawn" :
 "The information is being withdrawn from the zone,
  but may still be available in the zone."
--> "withdrawn" probably applies to the authoritative name servers
--> "still available" probably means in caches.
  I suggest some rephrasing to avoid confusion.

 "In this state, the information can still live in the resolver caches."
--> Precisely !  Rephrasing the first sentence would make this obvious
point unnecessary.

 "The key condition is said to be RetiredDS if it has its DS state in
Withdrawn
  (for KSKs)."
--> I would leave out the parentheses referring to KSK
    because to condition when there is only one key, no distinction
between ZSK and KSK,
    is also in the document (section 4.4).
    So what matters is the presence of a DS related to a key,
    regardless of the fact if that key is used to sign DNSKEY only, or all
RRset's in the zone.

3.1.3. Double-RRSIG
--> perhaps it escaped me elsewhere in the text,
    but comes down to "signatures, generated with a key, whose public part
is not published".
    May I suggest to write this more directly,
    instead of describing this in multiple lines.

--> perhaps/probably this document is not the right place,
    but "Double-RRSIG" explicitly and deliberately introduces
    a loose end for the validating resolver !
    If the resolver happens to start with this signatures,
    for which there is no DNSKEY, it will have to start over.
    Okay, it is only one step to start over, but anyway.
    From the perspective of "trying to minimise the number of loose ends"
    Double-RRSIG is not the best idea.
    (but this observation is probably better placed in another draft/RFC)

3.4. Stand-by Keys
 "In the case of a KSK, ..."
--> what I miss (and suggest to mention explicitly) is that both the
stand-by key
    is published (DNSKEY record present) and the corresponding DS
record(s) is/are present.
   (DS without corresponding DNSKEY makes no sense,
    as the other key-timing-draft (Morris,Ihren,Dickinson) states)

(last paragraph of that section)
 "Because a stand-by KSK only makes sense with the double-DS method,
  stand-by keys in a STSS is not applicable.  This is because the
  Double-DS method is not easily integratable with one of the ZSK
  rollover methods."
 STSS = Single Type Signing Scheme : one key only/no distinction between
ZSK and KSK
  or
 - in readable (I hope ;-) text :
   the key used to sign all RRSET's has its DS in the parent.
--> I don't quite agree with these statements.
    I admit that 3.3.4 describes a quite complex procedure for Double-DS
    in the case of STSS,
    but it (3.3.4) also states "... at the cost of double signatures in
your zone ..."
    The whole idea of "stand-by" is to publish everything *but* the
signatures !
    And that, in my opinion, simplifies the procedure.

 I don't see why an administrator
  - could not publish two keys (STSS),
  - have DS's for both in the parent zone,
  - effectively sign with only one of them.

Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150    
    1831 Diegem - Belgium
    [email-masked]
    http://www.eurid.eu

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 May 2011 14:50:09 +0200

Hi Marc,

> Please consider the comments as "constructive" and not negative criticism

I will:)
Thanks for your review.

> (though I don't have a particular recommendation on how to make it more

I must confess I am still struggling on how to make the text most
accessible. You can describe the key timings with different views. the
"conditions" are one of them. The unraveled key states are the most
technical part, in my opinion. They describe the actual state a piece of
information is in. With the "conditions", I tried to introduce terms so
that you can speak about keys on a more human level.

[I am currently thinking "property" is a better term, but it is just a
game of term juggling]

> "dnssec timing considerations" which would then more cover the content.

True, but in the case of policy rollovers, I actually only highlight the
consequences in terms of key rollovers. In addition, the document is
considered to be a follow up document for the DNSSEC key timing document.

>  could then refer to this document for the timing issues)

I am inclined to limit the document to key rollover timing
considerations, since that already is enough for approximately 40 pages.

But if the working group has a different view on this, I am of course
willing to listen.

> --> administrators will have to make a choice.

I agree that Speed and Simplicity can be two different considerations.
However, it turns out that the fastest rollovers are also the most
simple ones, the recipe for the fastest rollovers are the least complex.

So there is no conflict between the Simplicity and Speed. However, there
is of course a conflict between Speed, Size and Interactions with the
parent.

> --> some clarification/rephrasing seems appropriate !

This is actually a new approach on how to look on key rollovers. Instead
of following the lifetime of one key from Generated to Dead, it is
possible to identify a rollover as a set of key goals: One key needs to
be activated, another needs to be removed.

This section just introduces the definition of Key Goals. But I guess
some additional clarification would be good indeed.

> A key is used for some purpose (eg ZSK, KSK), but a "goal" ?

I hope the above clarification can help in resolving your confusion
about key goals.

> Is "activate" or "remove" a goal (a reason to exist) of a key ?

A key rollover is a combination of key goals. Usually "Activate" key A
and "Remove" key B.

> "stand-by" key : is it a goal of a key to be "stand-by" ?

Yes, it can be possible to say that a key is a stand-by key. Than that
key's goal is to be stand-by.

(And then in case of an emergency key rollover, you change its key goal
from stand-by to activate).

> I'm afraid this phrasing does not relay the original idea of goals, sorry.

What do you mean with original idea of goals?

> to start using or explicitly forgetting about data.

No, but by adding RRs or removing RRs from RRsets in the zone at the
authoritative side and keep that version of the zone for long enough,
you can be sure that previous versions of these RRsets expire from
resolver caches. That's what I mean with "make use/forget ...".

>  Those DS records have one or more signatures ...

To me, this sounds more like requirements.

>  and oblige to start over : it costs time and CPU cycles ...

This sounds to me an operational consideration (keep the size of the
response to a minimum, by having the minimal amount of necessary
signatures).

> "states" for RRSIG and DS !

The key states from draft-ietf-dnsop-dnssec-key-timing have been
unraveled to the components DNSKEY, RRIG and DS, yes.

>      during which unusable information is in that cache - leading to those

My apologies for the bad phrasing here. What I meant was that it is
possible for resolvers to pick up the information from the authoritative
name server. But there may be resolvers that do not go to the
authoritative name server to pick up this information, because they
still have previous version of the information in the cache.

So as you can see: I did reply with "old information might be in the
cache". More importantly, I do not think that describing timing
considerations is about limit the period of time during which unusable
information is in the cache. First it is not unusable, because if it is
the cache, it may be used. Second, if you want to limit the period of
time of information in the cache, just lower the TTL.

>  (typo only) "... from cache of from the authoritative name server."

Thanks.

> --> Precisely !  Rephrasing the first sentence would make this obvious

Rephrasing is probably necessary. I want to point out that information
that is in the state "Withdrawn" may still exist in the zone file. For
example, if signatures are being removed incrementally.

>     regardless of the fact if that key is used to sign DNSKEY only, or all

In the case of a Single Type Signing Scheme, a key is used as a KSK and
a ZSK at the same time.

>     instead of describing this in multiple lines.

Ok.

>     (but this observation is probably better placed in another draft/RFC)

Yes. So if that is your consideration, you would not optimize the size
of the DNSKEY RRset (as that conflicts with minimizing the number of
signatures). It might indeed be necessary to explicitly add which
considerations conflict with each other.

>     as the other key-timing-draft (Morris,Ihren,Dickinson) states)

For a KSK, adding a standby-key is done by adding the DS at the parent
(not adding the DNSKEY RR in your zone, otherwise it would be an active
key). So, it does make sense to have a DS without corresponding DNSKEY.

>     The whole idea of "stand-by" is to publish everything *but* the

Yes, but because with a KSK, the DNSKEY RR and its signature travel
together, one would not publish the DNSKEY RR for the KSK.

>   - effectively sign with only one of them.

The key timing documents assume that the RRSIG and the DNSKEY RR for
KSKs travel together (as there is no point in publishing the DNSKEY RR
for the KSK an not use it for signing). So you would still need to sign
with your proposal of the STSS Stand-by key.

However, it might be that this rollover scenario does provide a reason
for signature and DNSKEY not travel together.

Thanks!

Best regards,
  Matthijs