On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy <sandy@xxxxxxxxxxx> wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Thank you very much for your review, and getting it in early, it makes addressing them much easier. > > This document suggests that resolvers should use NSEC/NSEC3 proof of non-existence for a domain name in a received query to generate a negative reply, rather than relying on the current spec of an exact match to the domain name. Generating positive replies from wildcard answers is also suggested. > > The motivation is improvements in latency for queriers and improvements in bandwidth and CPU load on recursive resolvers and validation servers. > > I have no serious objections about the draft. > > I am curious about my thought that an attacker might find this of benefit, as they can learn of non-existence in just one query, rather than every name in a NSEC denied range. I know zone walking is a concern to some, but I do not know if ease of determining non-existence is also a concern. I may have missed something, but I do not see the concern -- an attacker can already learn of non-existence in just one query; that is exactly what NSEC (already) provides. If an attacker queries e.g the root for .belkin they get back (trimmed): $ dig +dnssec belkin beer. 44025 IN NSEC bentley. NS DS RRSIG NSEC This tells the attacker that nothing exists between beer and bentley (in one query). All that this document does is optimize the recursive server so that, if the attacker tries to instead do e.g a dictionary attack and ask many names between beer and bentley the recursive (and auths) have less work to do. The attacker only advantage to the attacker is that they have to wait slightly less time doing a dictionary attack -- but, they would be much better off asking for the (existing) NSEC info directly. > > Section 7 explicitly spells out the changes to RFC4035 are explicitly spelled > out as to what is removed and what replaces it. Section 5 is not so clearly > delineated. Yup. At one point we had the changes explicitly spelled out in both, the WG felt that this was overly long and duplicating the text was confusing. > > The last paragraph of 5., nothing in 5.1 or 5.2, and the last paragraph of 5.3 > use SHOUD/MUST/MAY kinds of language. For the paragraphs that don’t - should > they? For the paragraphs that do, is this additional behavior or a > replacement for existing spec (i.e. like the section 7 update to RFC4035). > If a replacement, a replacement of what? If not, where do the new paragraphs > fit? > I don't think that these bits to need the 2119 language - they are more explanatory, and providing explanation / justification for the change baing made to RFC4035 (which is updated in Section 7). > The following is a sequential set of comments, not in importance order. > > page 3 > > This document updates RFC 4035 to allow recursive resolvers to use > NSEC/NSEC3 resource records to synthesize negative answers from the > information they have in the cache. > > re: recursive resolvers - is the technique not applicable to stub resolvers? > (I do see references to stub resolver caches in a web search, but you can’t > trust the web.) Good catch -- we fixed a similar issue in the Abstract, but missed it here. > > [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to > using NXDOMAIN information for more effective caching. This takes > this technique further. > > Unless rfc8020 and the vixie draft are the same thing (don’t think so), > should be “propose”. > > > Too many uses of “this” in that last sentence - I presume you mean > This draft takes those previous techniques further. Thank you. I changed these to: [RFC8020] and [I-D.vixie-dnsext-resimprove propose steps to using NXDOMAIN information for more effective caching. This document takes this technique further. > > > page 4 > > If a validating resolver receives a query for cat.example.com, it > contacts its resolver (which may be itself) > > Maybe > > If a validating resolver receives a query for cat.example.com, it > contacts its recursive resolver (which may be itself) Thank you -- I believe that the current is more correct; in most cases the validating resolver will be a recursive resolver and will be contacting a authoritative server. In a few cases (currently, in the future this may change as validating stubs become common) it will be a stub contacting a recursive, so the text in the draft covers both cases. > > About: > > and also has > privacy implications (e.g: typos leak out further than necessary). > > Does it also make certain explorations easier, where someone can find out a range > that does not exist by doing just one query rather than query every name in the > range? Or is that sort of exploration already prevented by other techniques? Nope; as above. Attackers already have the capability to find ranges which do not exist (querying for the NSEC record). > > If a query is received for leek.example.org, it contacts its resolver > (which may be itself) > > I suggest “the resolver contacts its <recursive> resolver” - the query is not > doing the contacting. Thank you. I changed it to: "If a query is received for leek.example.org, the system contacts its resolver (which may be itself) to query..." I think that this addresses your comment in a more general manner. > > > page 6 > > section 5.1 and 5.2 say “resolver can immediately return” - is this meant > to specify new behavior, should they have SHOULD/MAY/MUST kinds of words? I don't *think* so -- it means that is has the ability to; other text suggests what it actually should to. > > page 7 > > Section 5 of [RFC2308] states that the maximum number of negative > cache TTL value is 3 hours (10800). > > I don’t find a maximum in RFC2308. I do find: > Values of one to three hours have been found to work well > and would make sensible a default. > Did I miss something? > See below. > > “the maximum number of negative cache TTL value is” - a bit twisty. Did you > mean something like: > > Section 5 of [RFC2308] states that the maximum negative cache TTL value is” > > otherwise, I’d think “number of … values”, but even so I don’t think there are > multiple values here. Are there? Nope, you did not miss anything, and yes, yes that was twisty - 'twas an artifact of poor editing. I changed this to be: Section 5 of [RFC2308 suggests a maximum default negative cache TTL value of 3 hours (10800). It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to this same value. > > page 9 > > <truly nitty> > > The text says > > Thanks to Mark Andrews for providing the helpful notes for > implementors provided in Appendix B. > > The authors would like to specifically thank > … > Mark Andrews also provided the > helpful notes for implementors (https://www.ietf.org/mail- > archive/web/dnsop/current/msg18332.html) which we made into > Appendix B. > > Perhaps you intended to thank him twice? No problem, just wondering. Nope, edit fail. Fixed. Thank you again for your comments. I've posted / am just about to post a new version with them addressed / incorporated. W > > —Sandy > > > > > > -- 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