Hello,
As promised during IETF80, Prague, my comments on this draft :
2.2. KSK Rollovers
... In the KSK case this can never be a problem as the KSK is only used
for one signature ...
Administrators should use the KSK only to sign the DNSKEY RRset,
but implementations may allow to use the KSK for *all* RRset's.
--> shouldn't the "is only used" be "should only be used" ?
(next paragraph)
Trust in the KSK is either due to the existence of a DS record in the
parent zone (which is itself trusted) or ...
I object to the phrasing : "which is itself trusted".
It should not be interpreted that the mere existence of a DS record
makes it trustworthy. In reality, the DS record is trusted
because the accompanying RRSIG can be validated.
2.3. Summary
(only) two methods : ZSK Method and KSK Method.
In draft-ietf-dnsop-rfc4641bis-06.txt, section 3.1, there is motivation
to not always distinguish between KSK and ZSK.
(While I am not in favour of global recommendation for this (no
distinction),
if an administrator chooses not to differentiate, this does introduce a
third method, combining both. I think this draft should describe
associated issues
as well)
In addition, in my comment on that draft, earlier this week, I contributed
my observation that some DNSSEC'd domains use 3 keys for rollover :
initial situation : key1 & key2
start of rollover : add key3 --> key1 & key2 & key3
end of rollover : remove key1 --> key2 & key3
I don't think this is covered by any of the Methods in this draft (of
key-timing).
Leave it to the authors if they want to consider and include this method
for timing considerations.
For clarity : I did *not* invent this method, I merely noticed it being
used "out there" !
Nor do I know if the authors of rfc4641bis will include this method of
rollover at all !
3.1 Key States
Ready : The new key data has been published for long enough to
guarantee that any previous versions of it have expired
from cache.
I object to the phrasing : "previous versions of it".
(as long as a key exists, all "versions" are identical (keyid, algorithm,
value);
What is really meant : "any previous versions of the DNSKEY RRset".
Where the next "preceding" version of the DNSKEY RRset,
is a RRset where the new key is not yet present, with its DNSKEY record)
Retired : The key is in the zone but a successor key has become
active. As there may still be information in caches that
that (word is present twice !) require use of the key,
it is being retained until this information expires.
I would additionally state :
The key, in Retired state, is no longer used for generating RRSIG's.
Also, instead of "information in caches", I propose :
As there may be RRSIG's present in caches,
RRSIG's that were generated with this key,
the key is being retained until those RRSIG's expire themselves.
(because : "information" is really "RRSIG's generated with this key",
isn't it ?)
3.2.1 - 3.2.2 - 3.2.3 - 3.3.1 - 3.3.2 - 3.3.3
(each time : the time flow)
There is always an event "Tgen",
but there is never an event "generation of the new key".
To be consistent, the generation of the new key should be added.
However, this complicates the time flow.
My recommendation is not to show "Tgen" at all.
It is obvious that a key must be generated before it can be published.
But I don't think showing this event in the time flow has any
additional contribution.
I do realise that the text that goes with this event
states that Tgen might be the generation of "a pool of keys".
OK - perhaps we can live with this single "Tgen" + text;
otherwise there is no reason for the state "Generated",
and keys would come "out of nowhere" to the state "Published",
which might be even more confusing.
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
