Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Hi, On Wed, 05 Sep 2012 13:20:10 -0400 Michael StJohns m...@nthpermutation.com wrote: Hi - As the subject document seems to describe an operations problem rather than a protocol problem, I'm going to use the dnsop mailing list to post some comments. Thank you for bringing this to dnsop mailing list. While I haven't completely internalized this document, I'm pretty sure it's addressing the wrong problem. The issue is not that there are too many DS in the parent zone as compared to DNSKEY in the child. It's actually perfectly correct to publish a DS record in advance of publishing the related DNSKEY. I *think* the issue they may be concerned with is a complete disjunction between the parent DS and child DNSKEY RRSets. But that's not what the document says. Disjunction between DS and DNSKEY will happen. That is premise of the document. And the document (at least, one of the authors) is intent to indicate rational procedure to recover from the validation failure caused by the disjunction as soon as possible. Case 1 - there is no such thing as a failing DS. There is a DS that does not currently match a child DNSKEY, but that is not necessarily a fail. Case 1 - the appropriate problem is no matching DS for zone DNSKEYs - the resolution is add a matching DS to the parent zone, or deploy a DNSKEY that matches an existing DS. Case 2-5 seem to be the same problem as case 1, rather than separate problems - but the title of the cases does not reflect this. In any event, removal of data is mostly not going to help the problem - you need to add the appropriate links in the trust chain. Data that does not provide a link in a trust chain is just extraneous and may be safely ignored until it can be removed with normal practices. Case 1-5 are alternate countermasures in case of disjunction has happened. Of course, add appropriate DS in parent zone is correct way to recover the disjunction. However, if DS is corrected, zone banishing may remain until DS cache is expired in validators. This duration will take huge impact to the internet users. As described above, the document is intent to indicate rational procedure to shorten the duration. At best this is an incomplete ID (and I'd recommend not posting something this incomplete), at worst it's headed in the wrong direction. Indeed, the document is imcomplete, and need feedbacks from experiences. Regards, -- Yoshiro YONEYA yoshiro.yon...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Yoshiro YONEYA (yoshiro.yoneya) writes: Indeed, the document is imcomplete, and need feedbacks from experiences. There are indeed many ways to facilitate recovery, not all of them practical or realistic. Here's one that's more in the realm of prevention, but would faciliate recovery, assuming the implementation doesn't suffer from the same operational errors that led the zone owner to consider recovery in the first place, and assuming the DS-set has been completely borked by the parent: Case 6: always have a backup (fallback) DS, published alongside the existing (production) DS record or records (during rollover) currently associated with the currently active (production) KSK. Keep this backup KSK in a safe place, and in case of serious SNAFU with the existing DS-KSK couple, pull the backup KSK out of the Safe Place, and start signing the ZSK with that. The DS-set containing the active + backup KSK being by definition always published, this should allow for faster convergence (assuming a fairly low TTL for the DNSKEY RRset in the signed zone). The problem with the ID may be that there are so many different ways of doing this (hinted at by the phrase Registration system (or zone generation system) of parent zone will be complicated.)... Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
Hi, Here is my review. There are some small comments and some larger comments, but I decided to report them in order of appearance. * Section 1.1. Key Rolling Considerations. - Bullet point 2 takes into account DNSSEC boot-strapping. The document is mainly about key timings in a rollover event. Section 3.3.5 talks a bit about introducing a first key. I am questioning that the topic on enabling DNSSEC is so small in this document that it may be better to remove this bullet point and section 3.3.5. - A style remark. In bullet point 4: I would remove the brackets around the last sentence. - Another style remark. The last sentence talks about key-signing keys and zone signing keys. Inconsistency with the -. * Section 1.2. Types of Keys - In the last sentence of paragraph 2, make clear that also the RRSIG of the DNSKEY RRset is important: In the case of the KSK, the information is the self-signed DNSKEY and the DS RRset...^^^ * Section 2.1. ZSK Rollovers - Bullet point 2, second paragraph. Once the signing process is complete and enough time has elapsed to allow all old information to expire from caches, It is actually more about the new information to propagate to caches, so I would suggest to replace it with: Once the signing process is complete and enough time has elapsed to allow all new information to propagate to caches, ... ^^^ - The final paragraph, which summarizes the three ZSK rollover methods, can it be removed? The section itself is already a summary of the possible ZSK rollovers, I don't see any value in this final paragraph. * Section 2.2. KSK Rollovers - Nit: Paragraph 4 starts with Like the ZSK case, ... which to me seems to insinuate that the number of KSK rollover methods is related to the number of ZSK rollover methods. I would like to see it removed. - Bullet point 1 says that the ZSK Double Signature rollover is also known as Double-DNSKEY. I have not heard of this term before reading this document. Is it really known as? If not, please remove it to avoid unnecessary confusion. Also, again: don't say waiting for old information to expire, but waiting for new information to propagate. * Section 2.3. Summary - KSK Double-Signature has the description Publish the DNSKEY and RRSIGs at the same time. But actually that is true for all KSK rollovers. In fact, I think this table doesn't have much value and I argue that it can be removed. * Section 3.1. Key States - Repeating myself: These key states are not sufficient to describe the rollover time lines. See the comments below on the rollover time lines. * Section 3.2.1. (ZSK) Pre-Publication Method - Style inconsistency: The first line uses capitals for Pre-Publication rollover, while in other sections the rollover names are completely lowercased. - A general note on the Events 1: It explains every time why there are different times for key generation and publication. This can be done only once with a note that this is also true for the other Events 1. - Event 8 talks about an expired DNSKEY RRset in the cache. Seems a contradiction to me. * Section 3.2.2. (ZSK) Double-Signature Method - Event 3: The current key is said to be retired. However, the key state definition of retired is: A successor key has become active and this key is no longer being used to generated RRSIGS. But in this rollover, it is required to have the current key generate signatures, otherwise there are no double signatures and the Double-Signature rollover can make the zone go bogus. In short, the key state in this event does not match the key state description. * Section 3.2.3. (ZSK) Double-RRSIG Method - The first line mentions double-signature rollover, should be double-RRSIG. - Event 5: The key is now said to be active. Actually, according to the key state description, the key was already active earlier: The key has started to be used to sign RRsets. With ZSK Double-RRSIG, the key has started to be used to sign RRsets in Event 2. * Section 3.3.1. (KSK) Double-Signature Method - Event 5: The time that the key becomes active, but the key state description of active only takes about creating signatures, not about the so-called security chain. - Event 9: Also the key state description of retired doesn't mention the security chain, but is only aligned for ZSK rollovers. These two comments are also for the other KSK time lines. * Section 5. Algorithm Considerations - Paragraph 1: ... using a single algorithm. - using the same cryptographic algorithm. * Section 7. Summary - The second paragraph says that the Double-RRset rollover is the most efficient method for KSKs. While this is true if you look at the duration of the rollover, this is not true for the number of parent interactions. In fact, in the following line, the document says that the time take to roll KSKs depends on factors related to the (signed) parent. So if the
Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
Matthijs Mekking matth...@nlnetlabs.nl wrote: Most of your points look OK to me though I have not yet reviewed the document in detail. I have a disagreement and a suggestion: * Section 2.1. ZSK Rollovers - Bullet point 2, second paragraph. Once the signing process is complete and enough time has elapsed to allow all old information to expire from caches, It is actually more about the new information to propagate to caches, so I would suggest to replace it with: Once the signing process is complete and enough time has elapsed to allow all new information to propagate to caches, ... ^^^ No, I think the original text is correct. You can't remove the old DNSKEY until all the old RRsets (and RRSIGs) have expired, and you can't remove the old RRSIGs until the old DNSKEY RRsets have expired. Whether the caches have the new data is irrelevant since it's also OK for them to have no data. And when caches are filled is not under the authority's control. - Bullet point 1 says that the ZSK Double Signature rollover is also known as Double-DNSKEY. I have not heard of this term before reading this document. Is it really known as? Double-KSK would be a better term, since Double-DNSKEY sounds like the normal steady state with a KSK and ZSK. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
On 09/06/2012 01:44 PM, Tony Finch wrote: - Bullet point 1 says that the ZSK Double Signature rollover is also known as Double-DNSKEY. I have not heard of this term before reading this document. Is it really known as? Double-KSK would be a better term, since Double-DNSKEY sounds like the normal steady state with a KSK and ZSK. I disagree. To me Double-KSK sounds like having two keys, both with DS and DNSKEY records published. //Yuri ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
