Top note: My original message misspelled the dnsop-chairs alias. Warren replied to everyone, so I’m guessing that he got a bounce from my error. Anyone responding to Warren’s message, please note. > On Mar 30, 2017, at 2:59 PM, Warren Kumari <warren@xxxxxxxxxx> wrote: > > On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy <sandy@xxxxxxxxxxx> wrote: >> >> 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. Yes, silly of me, sorry, (Ill) thought retracted. >> >> 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). So you are going to take out the normative language? Otherwise, well, it confused me. > >> >> 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? >> > > 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. Quibble: I still don’t see that RC2308 sets 3 as a maximum, just “have been found to work well”. Could be elsewhere in RFC2308, and I missed it. —Sandy
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail