ietf
[Top] [All Lists]

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

2017-03-30 15:50:44
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(_at_)kumari(_dot_)net> 
wrote:

On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy 
<sandy(_at_)tislabs(_dot_)com> 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

<Prev in Thread] Current Thread [Next in Thread>