At Sun, 10 Apr 2016 10:18:11 -0400, Tim Wicinski <[email protected]> wrote:
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3 > draft-fujiwara-dnsop-nsec-aggressiveuse > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. *Speak > Up* if you have strong opposition to this work. > > *More Importantly* > Please also indicate if you are willing to contribute text, review, etc. > We will want several dedicated reviewers on this. I've read previous and current versions of the draft. I support the adoption of this draft with one condition: IMO its "problem statement" should be completely revised. If adopted, I'm willing to review future versions. Regarding the problem statement, I believe my comments on a previous version still stand: https://www.ietf.org/mail-archive/web/dnsop/current/msg14865.html (the point about wildcard may warrant more discussion, but that's relatively minor in the whole context). The latest version of the draft seems to try to defend it in that scenario, thereby rather making it fragile and unnecessarily complicated (see below for some specific points). So I think this draft should stop selling the idea as a counter measure for random subdomain attacks on *recursive servers*. It may still have other benefits, such as: - general possible performance improvement for recursive servers (but, as I commented for the cheese-shop draft, I'd like to see measured evidence about that). - possible counter measure for random subdomain attacks on *authoritative servers* (and encourage the authoritative operators to sign their zones) - reducing garbage (though not attack) traffic to authoritative servers, especially higher level ones such as root. And I see these are at least worth discussing, and I therefore support the adoption in that context. Some specific comments on the 03 version - Abstract: I suggest revising this on this point (see above): responses as well as some level of mitigation of random sub-domain attacks (referred to as "Water Torture" attacks). by either simply removing it or clarifying that it's mitigation for authoritative servers. - Section 3: IMO this section will have to be completely revised in terms of the selling point. Even if my point about the effect for recursive server is refused, this section looks still quite awkward since it reads as if this is *the* problem this proposal tries to address, while in (e.g.) abstract it rather sounds a weak subset of the goals. - Section 4.2: this may also depend on the goal of the proposal, but at this moment I don't think this "SHOULD" is fully justified: A full-service resolver implementation SHOULD support aggressive use of NSEC and enable it by default. It SHOULD provide a configuration knob to disable aggressive use of NSEC. If it's just a possible performance improvement for recursive servers, it should be totally up to the implementors choice. For other purposes such as (helping) attack mitigation for authoritative servers or reduce garbage traffic to the root, some stronger requirement level may make sense, but I'd like to see more empirical evidence before making the requirement. - Section 4.5 Even if a wildcard is cached, it is necessary to send a query to an authoritative server to ensure that the name in question doesn't exist as long as the name is not in the negative cache. When aggressive use is enabled, regardless of description of Section 4.5 of [RFC4035], it is possible to send a positive response immediately when the name in question matches a NSEC/NSEC3 RRs in the negative cache. I don't understand the second paragraph. I also don't understand how the first paragraph is related to the second. I'm not sure if it's only me, but I'd like to see more explanation here. - Section 5.1: IMO, this is an example that makes the document fragile by trying to defend it as an attack mitigation. If we say something like this: This draft proposes that the CD bit may be ignored to support aggressive negative caching when the full-service resolver is under attacks with CD bit set. It's useless unless we also specify how to detect the resolver is under an attack. And, if we can reasonably detect that (which I guess is possible) we might not necessarily need nsec-aggressiveuse for mitigation. When it's under an attack, other general counter measures such as rate limiting can be justified and probably sufficient. My personal suggestion is to stop the idea of defending it as an attack mitigation, and simply note the implication of the CD bit as a fact. It will not immediately make this proposal useless for other general cases, since such queries would be relatively much rare. - Section 5.2: ditto. I suggest simply removing this section. - Section 9: I don't understand this: Aggressive use of NSEC/NSEC3 resource records without DNSSEC validation may cause security problems. Specifically what does "without DNSSEC validation" mean? Something like a case where a validating resolver receives an NSEC/NSEC3 and uses that information without DNSSEC-validating it? If so, it's simply invalid per protocol whether the use is "aggressive" or not. So I don't see the need for stating that here. If this means something else, I didn't get it and would like to see more explanation. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
