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 protected]
http://www.eurid.eu
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
