Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

Warren Kumari <warren@kumari.net> Tue, 06 December 2016 21:57 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52A1295E4 for <dnsop@ietfa.amsl.com>; Tue, 6 Dec 2016 13:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 li659jtJAcS3 for <dnsop@ietfa.amsl.com>; Tue, 6 Dec 2016 13:57:12 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE871295E1 for <dnsop@ietf.org>; Tue, 6 Dec 2016 13:57:11 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id q130so207329451qke.1 for <dnsop@ietf.org>; Tue, 06 Dec 2016 13:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IlQhgUbca0rgdkPtCCD7qsxEdudYzNNLz7LqAyTRnVo=; b=TH9yPXI2LUQwd9lzsTqPFZnCSFryydw9exGYt8W6LLnQdh6yHflKEjifG6DbkTMxdX tZWuopooTBBbWMbOK4JkreWeQDn1iXOMu67PqiUoTikLqPwsBkalh765I+u36VaqjCus RVGN9Z4tVDF+KRbgwW758BW1atUZuL6sNDu4obgIDV2NbXTDJDGimgTOk9OMBt8rSG0L 1ob6YXSsAzvQ0VZ0M4493TAKZdsOFEV7Wdkoi+N0UZ3DMK6gOm4v6+N9Dx0ztkBIWVP3 9Fk2rgfx1F19hazrA+tZHIbuoSM23OdiImRNlVhIHJpJl/iDx8YYyD1thhtBw1eYl/i7 uyTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IlQhgUbca0rgdkPtCCD7qsxEdudYzNNLz7LqAyTRnVo=; b=gR09R5L8H7JFa2ZV/P4qqkKQJLGroYA7GDr1SN2j2SEclLfijyx0fSIdBf9tcPIlnV 3eVX2l1Szw2ew8Lw5zbhgg1IzB/hczm4TkTJNIEM5+HaeJiC9ar/ugwAvH75xpAquknb kDClS4eDbxtBga8sJppgR/Dsh/VafL4rhyg2SJvRSUy7s6+5MW1q4aeZv88yKpEjWDxw JwtaG39kaLDhpuuYM+l5Jt7MHl2rdgXsjVZxNWAdj58XUsH0PVyYhQ0uz+s/1wSXIhT8 Pavll6XxIaHUGEoojj9SsdJtzj4WxJEIjvsQgtzyF/KmW9+hRfyD30ZcYExrtjyBq95U xZRQ==
X-Gm-Message-State: AKaTC02S+4zMu9oSr05pxGVdHGm1p0IQvaJR1q5GCJT6NgmdU7vAAYQKVfOTlVmFYDoyE57eee0A03Pv+mE/m71n
X-Received: by 10.55.42.196 with SMTP id q65mr49548855qkq.267.1481061430635; Tue, 06 Dec 2016 13:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.146.16 with HTTP; Tue, 6 Dec 2016 13:56:40 -0800 (PST)
In-Reply-To: <4606d21d-8130-80f2-bd9b-0f35783a6489@nlnetlabs.nl>
References: <147926408975.10235.12024991884745160541.idtracker@ietfa.amsl.com> <4606d21d-8130-80f2-bd9b-0f35783a6489@nlnetlabs.nl>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 06 Dec 2016 16:56:40 -0500
Message-ID: <CAHw9_i+E=mUeUu=Go+Qxu81hL=wH7b+-2kOFXVajpSTHz72_9g@mail.gmail.com>
To: Ralph Dolmans <ralph@nlnetlabs.nl>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w75waSI2Vw61hlTofCnP_ZIEL6g>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 21:57:14 -0000

On Thu, Nov 17, 2016 at 5:36 AM, Ralph Dolmans <ralph@nlnetlabs.nl> wrote:
> Hi,
>
> Maybe I'm missing something, but it is not clear to me whether this
> document (-06) allows generation of NODATA answers using matching NSEC
> records that do not have the QTYPE set in the type bitmap.
>
> I don't see it explicitly mentioned. The RFC4035 update in section 7
> seems to allow it (or at least not disallow it). However, Section 4 only
> mentions covering (not matching) NSEC records. Same in section 5.1: "The
> validating resolver needs to check the existence [...] and an NSEC RR
> covering the query name.".
>
> Section 5.1 does mention using NSEC to return NODATA responses, but that
> might also be the result of an ENT answer. Section 5.3 seems to disallow
> NODATA answers for wildcards: "If the corresponding wildcard record is
> not in the cache, it MUST fall back to send the query to the
> authoritative DNS servers.".
>
> I hope the intention is to allow NODATA responses for wildcards,
> otherwise random QNAME attacks are possible on wildcard records.

Yup, that is the intent, and I have just posted a new version to
Github clarifying this -
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse

Apologies for this taking so long -- I asked my co-authors for text,
they quickly provided some. I was wondering why no-one commented, and
then realized that I'd (stupidly) done that all off-list.

I *think* that I have now addressed all open questions / comments /
suggestions, *please* let me know if I missed anything.
I've gotten lots of helpful comments (thanks!), if I missed any it was
not intentional...

W

>
> And some nits, for which I'll submit a pull request:
>   - In the abstract: s/negative based/nagative answers based/
>   - Section 1: s/with NXDOMAIN immediately/with negative answers
> immediately/ (this also catches NODATA answers for ENTs)
>   - Section 2: "Closest Encloser" and "Next closer name" are not used in
> this document.
>   - Section 3: s/starting/stating/
>   - Section 4, sentence of 4th paragraph ends abruptly "(for the"
>   - Section 4, last paragraph: s/the TTL of the NSEC record is the
> authoritative statement/the TTL of the NSEC/NSEC3 record and the
> SOA.MINIMUM field are the authoritative statement/ (and/or a reference
> to section 5.4?)
>
> Regards,
> -- Ralph
>
> On 16-11-16 03:41, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>>
>>         Title           : Aggressive use of NSEC/NSEC3
>>         Authors         : Kazunori Fujiwara
>>                           Akira Kato
>>                           Warren Kumari
>>       Filename        : draft-ietf-dnsop-nsec-aggressiveuse-06.txt
>>       Pages           : 16
>>       Date            : 2016-11-15
>>
>> Abstract:
>>    The DNS relies upon caching to scale; however, the cache lookup
>>    generally requires an exact match.  This document specifies the use
>>    of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers
>>    to generate negative answers within a range, and positive answers
>>    from wildcards.  This increases performance / decreases latency,
>>    decreases resource utilization on both authoritative and recursive
>>    servers, and also increases privacy.  It may also help increase
>>    resilience to certain DoS attacks in some circumstances.
>>
>>    This document updates RFC4035 by allowing validating resolvers to
>>    generate negative based upon NSEC/NSEC3 records (and positive answers
>>    in the presence of wildcards).
>>
>>    [ Ed note: Text inside square brackets ([]) is additional background
>>    information, answers to frequently asked questions, general musings,
>>    etc.  They will be removed before publication.This document is being
>>    collaborated on in Github at: https://github.com/wkumari/draft-ietf-
>>    dnsop-nsec-aggressiveuse.  The most recent version of the document,
>>    open issues, etc should all be available here.  The authors
>>    (gratefully) accept pull requests.]
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-06
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf