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

Sandra Murphy <> Thu, 30 March 2017 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF2A8129552; Thu, 30 Mar 2017 13:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQaG43sGcSip; Thu, 30 Mar 2017 13:49:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 366AB12951B; Thu, 30 Mar 2017 13:49:26 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 7E49628B003B; Thu, 30 Mar 2017 16:49:25 -0400 (EDT)
Received: from [] (localhost.localdomain []) by (Postfix) with ESMTP id 787831F8036; Thu, 30 Mar 2017 16:49:14 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_271850B6-8E28-403F-8932-A8747B257FB4"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Sandra Murphy <>
In-Reply-To: <>
Date: Thu, 30 Mar 2017 16:47:00 -0400
Cc: Sandra Murphy <>, IETF Security Directorate <>,,, The IETF <>
Message-Id: <>
References: <> <>
To: Warren Kumari <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Mar 2017 20:49:39 -0000

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


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.