Hi, On 06/21/2013 11:58 PM, Wes Hardaker wrote: > Paul Wouters <[email protected]> writes: > >> I am in favour of adopting this draft as a WG item. > > Ditto.
Another ditto. I am pleased to see that there is still activity on the topic of automating the synchronization between DNSKEY at the child and the DS at the parent. >> I don't think the CDS record should be able to cause a child domain to >> go from secure to insecure, or from insecure to secure. That >> (infrequent) change should have an additional authentication, eg via EPP >> or otherwise) > > Ditto. I think the goal of any of the automatic update techniques > should be to make the routine easy but it shouldn't be a goal to handle > the infrequent, and challenging cases. (infrequent and easy is fine). > > Unless we can show a clear, secured, path for some transition I don't > think it's worth solving. Another ditto. Agreeing with it's not worth solving to deal with the irregular cases. Going unsigned is an irregular case. Also backing a previous made comment by other people: * I prefer to have the CDS wire format to be similar to the DS wire format. With the current draft, it is already possible to automate all possible key rollovers, no need for managerial hooks to say this record is proposed, must be added, deleted, is valid for only this period etc. Comments on the draft (apologies for its length): * Nit: In section 1, it says there may be two interactions with the parent. This could also be only one, this could be more in some freaky rollovers, so I would prefer that it reads: "there may be one ore more interactions with the parent". * Section 3. I appreciate that most ZSK /KSK terminology is carefully replaced with, but in section 3 is still something that itches: "The SEP bit is an optional bit to indicate that the key is allowed to sign the DNSKEY RRset". That is not true. Without the SEP bit, the key may also sign the DNSKEY RRset. * Section 3.1.1. As said above, I don't like the idea of using the CDS record to go unsigned. * Nit: Section 4.1. I think the last paragraph fits better in section 4.2. CDS Consumption. * Section 4.2. About the polling strategy. I am wondering how well this scales with respect to the number of delegations. * Section 4.2. It is suggested that RFC 5011-like hold down timers are being used, e.g. new keying information must be published for a month before acceptance as a new trust anchor. This makes the duration of key rollovers unnecessary long. The hold down timers in RFC 5011 are there to mitigate against a compromise. The compromise allows the attacker to sign data in the zone. Similar we could look at a compromise that allows the attacker to upload a DS/DNSKEY to the parent. However, there are no mechanisms to mitigate against this attack. Why should we have mitigation for the CDS proposal, if there is none for the current mechanism? The difference between CDS and RFC 5011 is the location of the trust anchor your are updating. With CDS, you are updating the DS in the parent. With RFC 5011, you are updating lots of trust anchors in the wild. The latter may indeed require a bit more conservative approach. * Section 4.3. I wonder if the SHOULD in the first sentence should be a MUST. * Section 4.4. I dislike the idea of the side effect of parent calculates DS, so I would like to see that only the "augment" mode is supported (where I think it should read: "it will make sure there are CDS records for the digest algorithm(s) it require(s)" (CDS instead of DS)). The publishing "Future DNSKEYs" does not go well with several rollover scenarios (those based on Double-DS). I am wondering if the policy is "We calculate the DS" or "We decide the digest algorithm". In case of the latter, then augment mode can be used to support this. In case of the first, the future DNSKEY is really required to be published, and Double-DS based rollovers are not possible in combination with CDS. * Section 6. Security Considerations. The last paragraph. Isn't this solved by saying that the Parental Agent MUST ensure that old versions of the CDS RRset do not override newer versions in section 4.3. Usage? There is already a proposed method on how to achieve this there. * When implementing a prototype for this in OpenDNSSEC, I questioned myself what value I should use for the TTL. We could consider 0, as this record is not really intended for the resolver. We could also use the TTL to suggest a polling frequency for the parental agent. Just some thoughts. Best regards, Matthijs * _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
