Olafur, On 06/07/2016 05:46 PM, Ólafur Guðmundsson wrote: > > > On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking > <matth...@pletterpet.nl <mailto:matth...@pletterpet.nl>> wrote: > > All, > > Matthijs thanks for the review > sorry for the delay in response. > > > I have read it and I like it. Still there are I think some things that > need to be addressed: > > - On enabling DNSSEC via CDS/CDNSKEY: most of the policies assume some > sort of communication channel between the child zone operator and parent > zone operator, while in fact RFC 7344 registers new resource records > because we assume there is no such channel. CDS/CDNSKEY records are put > in the child zone to signal the desired DS RRset in the parent. The > child can only hope that the parent will pick it up and the only way to > get confirmation is to query the parent zone. So how would the parent > "send a notification requesting a confirmation" (section 3.2) or > "instruct the requestor to insert some record into the child domain" > (section 3.4)? > > > Ok the current text is sub-optimal added: > "for example by sending email to the registrant requesting a confirmation."
... > It could use the same CDS approach and put it in some new resource > records in the parent zone (just stick it in the DNS ;)). > > That is even bigger change :-) sorry no go I thought so already :) Still it is unfortunate that we are not able to close the final gap of fully automating DNSSEC, but at least we are making the gap smaller and smaller. > Anyway, if we assume there is no other communication channel, the > document should provide more details on where to put this notification > or challenge such that the child can pick it up. If we say there is a > different communication channel, there needs to be more details about > how that channel looks. Or we should just keep saying it is a hard > problem and leave it out of scope (and solve it in yet another > document). > > In general we envision three confirmation approaches > - A proof of change control of zone by requesting record insertion > (covered) > - A delay in acceptance, i.e. a stability check (covered) > - A email to registrant asking for confirmation. (just added) > While there might be more this is all we envision. I still think Section 3 is on the weak side and has almost the same value as the oneliner: The authentication mechanism for verifying the child really wants to enable DNSSEC is out of scope for this document. > - On using 0 as the DNSSEC Delete Algorithm in CDS and CDNSKEY records, > I think that is fine and is a cleaner approach then using a non-zero > algorithm number. The document could perhaps make it explicit it is > meant only to be used in CDS and CDNSKEY records, not DS/DNSKEY. > > > done > > > - The document suggests that when disabling DNSSEC, only the fixed > fields should appear in the records. Do you mean fixed length fields? > > > changed "fixed fields" to "exactly the fields" > > > - Leaving out the Digest/Public Key field changes the definition of the > CDS and CDNSKEY records: No longer are their formats identical to the > DS/DNSKEY records. So at minimal this updates RFC 7344. Existing > versions of DNS server that support RFC 7344 will likely not be able to > load a CDS record as described in section 4 and consider it malformed. > > > Good point, making this clearer in text An alternative solution can be: In case the DNSSEC algorithm is 0, the Digest/Public Key MUST be ignored. > Finally, two nits: > > - Nit: The abstract gives the reader the feeling that initial trust is a > very hard problem, but then section 1.2 says it can be easily solved > with some simplifying assumptions :) Perhaps you meant to say that it is > hard to solve technically unless some reasonable policies can be > assumed. > > - Nit: The first use mentioned in section 2 is just KSK Rollover. What > does explaining the different operations add to the document? > > Basically setting the stage and expectations I think it is confusing, since the document does later not mention the ADD and REPLACE operation. Personally I would just say: "KSK Rollover" Best regards, Matthijs > Best regards, > Matthijs > > > thanks again > Olafur > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
