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

Sandra Murphy <sandy@tislabs.com> Thu, 30 March 2017 20:49 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2A8129552; Thu, 30 Mar 2017 13:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQaG43sGcSip; Thu, 30 Mar 2017 13:49:36 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366AB12951B; Thu, 30 Mar 2017 13:49:26 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7E49628B003B; Thu, 30 Mar 2017 16:49:25 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 787831F8036; Thu, 30 Mar 2017 16:49:14 -0400 (EDT)
Subject: Re: secdir review of draft-ietf-dnsop-nsec-aggressiveuse
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 <sandy@tislabs.com>
In-Reply-To: <CAHw9_iL-UdKNsBSP1imzOg1PcjAvhk=b7Uw+nG-gDeQSOfgUxQ@mail.gmail.com>
Date: Thu, 30 Mar 2017 16:47:00 -0400
Cc: Sandra Murphy <sandy@tislabs.com>, IETF Security Directorate <secdir@ietf.org>, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, dnsop-chairs@ietf.org, The IETF <ietf@ietf.org>
Message-Id: <C40CFD27-6EF1-4925-8E0E-375796DE0220@tislabs.com>
References: <F8D0F7F4-414B-44A4-B6D0-428D506D97C7@tislabs.com> <CAHw9_iL-UdKNsBSP1imzOg1PcjAvhk=b7Uw+nG-gDeQSOfgUxQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/g0Rs_P9dY-ToavuQnNz-fBoL0dU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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 <warren@kumari.net> wrote:
> 
> On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy <sandy@tislabs.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