-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc,
On 05/04/2011 10:25 AM, Marc Lampo wrote: > 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 will:) Thanks for your review. > 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) 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] > 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. 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. > 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) 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. > 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. 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. > 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 ! 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. > Some remarks : > 1) a "key" has a "goal" ? > 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. > 2) Three "goals" are listed, two of them of "verbs" ? > 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? > 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. 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 ...". > 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 ... To me, this sounds more like requirements. > 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 ... > ) This sounds to me an operational consideration (keep the size of the response to a minimum, by having the minimal amount of necessary signatures). > 2.2 Key states Unraveled > --> Though the title is about "Key states", the text also introduces > "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. > 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") 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. > State "Propagated" : > (typo only) "... from cache of from the authoritative name server." > Replace "of" by "or". Thanks. > 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. 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. > "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. In the case of a Single Type Signing Scheme, a key is used as a KSK and a ZSK at the same time. > 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. Ok. > > --> 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) 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. > 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) 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. > (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 ! Yes, but because with a KSK, the DNSKEY RR and its signature travel together, one would not publish the DNSKEY RR for the KSK. > 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. 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 > Kind regards, > > > Marc Lampo > Security Officer > > EURid > Woluwelaan 150 > 1831 Diegem - Belgium > [email protected] > http://www.eurid.eu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3PsBAAoJEA8yVCPsQCW5slcIAJOMU9kf4KcoTI/PhybkZGol YlucmnhjWJysvLYNeo58tOXIMBCMNsNRSGBa1WUT8PBvMLBjoag+RQB/r2Eee/nH CzR/uNzt+8Ifhzep8OJeWcJgDQDortmDjt7k4VfIzQfuTPwQ6gDi7vNAmlzoqNRY JdVyvcCKNxsyFzAFUKDKHfZGJVCdyCqCyViWZLFGZ9q6/nzKg9j/BFqH4Tcbf73p dEhz2rA0cZDHmHKzUI4hatTea1/XnNOnFxSyy0pJLUoYAIrxv0HqqRZdaVM+Bvst wji6R5hFz/HMZevf/0027rpnA/R9d4aYCTZGaOk7U5//ZeVYSt9NmyIP6HGbtLo= =CmsH -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
