At Mon, 27 Apr 2015 18:58:10 -0400, Tim Wicinski <tjw.i...@gmail.com> wrote:
> This starts a Working Group Last Call for Adoption for > draft-ietf-dnsop-negative-trust-anchors (I guess this is "for Publication", not "for Adoption"). Also, have we decided to publish it as an Informational document? I'm not opposed to it, but this document contains some normative text and affects inseparability in some sense, so a standard truck seems to be a more appropriate choice for me. > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ > > https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04 > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons I do not think it's ready for publication yet. I'd like to see a discussion on whether it really makes sense that an NTA for a domain name even disables a positive trust anchor below the name. I made more specific comment on this in a separate message: http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html (with some other comments on the 04 version of the draft). I also think Appendix B needs more editorial cleanups. Those editorial matters may not be a showstopper by themselves, but I guess it's better to fix them before sending it to the IESG. A couple of other comments on version 4: - Section 4: It is therefore recommended that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the I guess this 'recommended' may be better RFC2119 capitalized, i.e., "RECOMMENDED". Not a strong opinion, but it seems to me to be more aligned with general tone and other usage of RFC2119 keywords of this section. - Section 4: likewise, maybe s/should/SHOULD/ When removing the NTA, the implementation should remove all cached entries below the NTA node. Editorial and minor comments: - Section 3: there's an awkward blank line (and spaces) before the reference: names for a Negative Trust Anchor. For example, Unbound calls their configuration "domain-insecure." [Unbound-Configuration] - Section 7.1: s/has have/has/ Thus, there may be a gap between when a domain has have been re- - Appendix B: s/servers/server's/ (?) domain is consistency and history. It therefore is good if you have the ability to look at the servers DNS traffic over a long period of - Appendix B: s/them install/install them/ most of these tools are open source so you can them install locally if you want. - Appendix B: this sentence doesn't parse well to me... Using the tools over the Internet has the advantage though that as these are not located in the same part of the network you already will have more than local view by using different tools. - Appendix B: s/server.s/servers./ consistently around the world and from all authoritative server.s Use - Appendix B: s/an guarantee/a guarantee/ attack, although that is not an guarantee. Also if the output from - Appendix B: it's now a dnsop wg document EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to the domain. - Appendix B: this sentence doesn't parse well to me... Again if the data is the same this is an indication that the error is operator caused not an guarantee. - Appendix B: s/parents/parent's/ (or "parent zone's ?) o DNSKEYs in child zone don't match parents zone DS record. There - Appendix B: these two sentences seem too informal grammatically, if not broken: Has the existed before and was used? Was there a change in the DNSKEY RRSet recently (indicating a key rollover) and of course has the actual data in the zone changes. - Appendix B: o Data in DS or DNSKEY doesn't match the other. This is more common in initial setup when there was a copy and paste error. Again checking history on data is the best you can do there. It's not possible to give a checklist just to run through to decide if a domain is broken because of an attack or an operator error. Is the "It's not possible..." sentence supposed to belong to the bullet? This sentence seems to talk about something general, and seem to make more sense if it's part of the sentence that follows: All of the above is just a starting point for consideration when having to decide to deploy or not deploy a trust anchor. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
