Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse

[Sandra Murphy <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy <[e-mail]> 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