On Thu, Sep 29, 2016 at 2:32 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > At Thu, 22 Sep 2016 08:19:17 -0400, > Tim Wicinski <tjw.i...@gmail.com> wrote: > >> This draft has been worked on and it seems that the Working Group is >> happy with the updates that have been made and I feel it's ready for the >> next step. >> >> This starts a Working Group Last Call for: >> "Aggressive use of NSEC/NSEC3" >> draft-ietf-dnsop-nsec-aggressiveuse >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ >> >> 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. > > This draft is now in a pretty good shape, but IMO it needs some more > non-trivial discussions, and in that sense I don't think it's ready > for publication as it is. Specific comments follow. I'll also try to > answer some of the points I haven't responded to in previous threads. > > - (general) this draft still unnecessarily limits the use of this > technique to *recursive* resolvers. In my previous comment I > pointed out that the term "full-service resolver" is too > restrictive. The 02 version changes the term to "recursive > resolver", but that doesn't address the main point of my comment.
Thank you -- I guess that I didn't really understand the main point of your comment then. > I'll note some specific part of the draft that has this issue, but > it may not be comprehensive. Thank you - hopefully the specifics will help me better understand what you are looking for, > If the sense of this comment is > accepted, the entire draft will have to be carefully examined and > revised. > > - Section 1: s/recursive/validating/ > > This document updates RFC 4035 to allow recursive resolvers to use > > Note: the use of "validating resolver" is my suggested change in > this sense, so I'll consistently use it throughout my comments. But > I understand it's not the only way to address the point. DONE. Great, thanks. I made this change (and also a similar one in the abstract). > > - Section 2 > > Many of the specialized terms used in this document are defined in > DNS Terminology [RFC7719]. In this document we are using the terms > "recursive resolver" or "recursive server" as a more readable > alternative to the more formal[RFC7719] "full-service resolver" > > See the general comment. At least in the context of my previous > comment, this is not about readability but about applicability, so > changing "full-service resolver" to "recursive resolver/server" > doesn't address the point. My primary suggestion is to just remove > the second sentence. DONE. Thanks. > Or, if we want to make some note about a > terminology regarding "resolver", it may be that this document uses > the term "validating resolver" as it's used in RFC4035. Nah, no need, think that that is now clear enough, thanks. > > - Section 3: this section also has an issue of "recursive resolver". > Although it may not be as critical as other part of the draft since > it's only used as an example scenario, it's probably better to not > limit the role of resolver to avoid misleading. Maybe "recursive > resolver" is just changed to "validating resolver", and > "authoritative server" is changed to, e.g., "external servers" > (meaning either authoritative or or other recursive servers). DONE. I did some fix up - how do you like: "If a validating resolver gets a query for cat.example.com, it will query the example.com servers and will get back an NSEC (or NSEC3) record starting that there are no records between apple and elephant. The resolver then knows that cat.example.com does not exist; however, it does not use the fact that the proof covers a range (apple to elephant) to suppress queries for other labels that fall within this range. This means that if the validating resolver gets a query for ball.example.com (or dog.example.com) it will once again go off and query the example.com servers for these names." Does that cover it sufficiently? (and I think I now better understand your concern). > > - Section 4: s/recursive server/validating resolver/ DONE. > > - Section 4: is this perhaps some leftover and should be removed? > > [RFC4035]; Section 4.5 states: > > For a zone signed with NSEC, it would be possible to use the > ... > > There doesn't seem to be text starting with "For a zone..." in > Section 4.5 of RFC4035. And, even if there's such text, "However, > such use is discouraged by Section 4.5 of RFC4035." in that context > is really awkward. DONE. Actually that whole paragraph was awkward. See below. > > - Section 4 > > We believe this > recommendation can be relaxed because lookups for the specific name > could have come in during the normal negative cache time and so > operators should have no expectation that an added name would work > immediately. We think that the TTL of the NSEC record is the > authoritative statement of how quickly a name can start working > within a zone. > > I'm not necessarily opposed to this claim per se, but IMO it should > provide some more careful justification. It's true that "specific > name could have come in during the normal negative cache time", but > nsec-aggressiveuse could make such accidental disruption more likely > to happen. Even if it should be considered an operational error, I > believe we should at least note the difference, and, ideally, > provide an explanation of why it should be still acceptable. IIRC I > raised the same point for the cheese shop draft. I don't remember > the conclusion at that time, but if it was an introduction of some > more explanation, the same resolution can apply here. DONE I copied and pasted some text from Cheese Shop and also cleaned up this section somewhat. I think that I have now managed to successfully explain the reasoning, please let me know if you disagree / have suggested text. > > - Section 5.2 > > Implementations SHOULD enable aggressive use of NSEC by default. > > On a fresh re-read of the draft, I'm now not so sure if this is > clear enough and the requirement is reasonable. First, does this > also implies an implementation SHOULD implement aggressive use of > NSEC? Secondly, and especially if the answer to the first point is > 'yes', I'm not sure if SHOULD is reasonable. Since this is just an > optimization, it may be just up to the discretion of the > implementor. Only implementations which want to support Aggressive NSEC should implement Aggressive NSEC. It's up to an implementer to decide if they want to have this feature or not. I've tried to clarify this with: "Implementations which support aggressive use of NSEC SHOULD enable this by default. Implementations MAY provide a configuration switch to disable aggressive use of NSEC and allow it to be enabled or disabled per domain." > > - Section 5.4 > > Such aggressive use of cached deduced wildcard can be employed > independently from aggressive use of NSEC. But, it will be more > effective when both are enabled since the resolver can determine the > name subject to wildcard would not otherwise exist more efficiently. > > I've seen a comment in a previous thread that the second sentence > (I suggested this text) isn't very readable. I tend to agree, and > although I suspect there should be a better English writer than me > to improve it, I wonder this might be better: > > Such aggressive use of cached deduced wildcard can be employed > independently from aggressive use of NSEC. However, the resolver > still needs to determine the name subject to wildcard would not > otherwise exist. Aggressive use of NSEC will help determine it > more effectively. > > - Section 5.4: I suspect this is a leftover from a previous version > and should now be removed: > > Furthermore, when aggressive use of NSEC is enabled, the aggressive > use of cached deduced wildcard will be more effective. DONE (this whole section). I've simply removed the whole "positve" section, and so all of this icky text can go. If the WG wants it back, I'll steal and use your text, it is much better than what we had... > > - Section 6: s/recursive server/resolver/ (or validating resolver) > > Decreased recursive server load By answering negative queries from DONE. Thank you. > > - Section 6: > > The technique described in this document may also mitigate so-called > "random QNAME attacks", in which attackers send many queries for > ... > > IMO this paragraph is unnecessarily too verbose. Now that the > mitigation effect is just a better-than-nothing kind of measure > rather than a major sales point of the technique, I don't think we > have to provide detailed discussions on cases where it may not work > well, etc (and, however hard we try it, it won't be complete > anyway). I'd make it much more concise, e.g.: > > The technique described in this document may also mitigate so-called > "random QNAME attacks", in which attackers send many queries for > random sub-domains to resolvers. As the resolver will not have the > answers cached it has to ask external servers for each random > query, leading to a DoS on the authoritative servers (and often > resolvers). Aggressive NSEC may help mitigate these attacks by > allowing the resolver to answer directly from cache for any random > queries which fall within already requested ranges. It will not > always work as an effective defense, not least because not many > zones are DNSSEC signed at all, but it will still provide an > additional layer of defense. > > (I also made the "recursive server to resolver" cleanup here). DONE. Thank you, I used your text verbatim. Thanks for that. > > - Section 7: s/recursive resolvers/validating resolvers/ > > | Once the records are validated, DNSSEC enabled recursive | > | resolvers MAY use wildcards and NSEC/NSEC3 resource records | > > This is also more consistent with the text shown in Section 5, and > more compatible with RFC4035 itself (in my understanding the RFC > doesn't unnecessarily limit discussions to recursive servers). DONE. Thank you. Somehow over-enthusiastic editing had managed to remove that entire section. > > - Section 9 > > Aggressive use of NSEC / NSEC3 resource records without DNSSEC > validation may cause security problems. It is highly recommended to > apply DNSSEC validation. > > This paragraph is awkward. I pointed this out several times, so I > won't repeat it here - please refer to my previous comments. One > possibly new perspective is that this tries to cover cases where > NSEC or NSEC3 is somehow cached before/without DNSSEC validation and > note that such records shouldn't be used for the purpose of > nsec-aggressiveuse. If so, it might make some sense, but in that > case it should be totally rephrased to avoid confusion or > misleading. DONE. How is: "Aggressive use of NSEC / NSEC3 resource records without DNSSEC validation may create serious security issues, and so this technique requires DNSSEC validation."? I don't love it, additional suggestions or text welcomed. Thank you again for your comments / edits. I apologize for not having understood them initially, hopefully I have them all good now. W > > -- > JINMEI, Tatuya > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
