Re: [DNSOP] Working Group Last Call

Warren Kumari <warren@kumari.net> Fri, 07 October 2016 23:08 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 3FA4812945E for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 16:08:11 -0700 (PDT)
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 GAj5U6Fvcxak for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 16:08:09 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 6C2201293D6 for <dnsop@ietf.org>; Fri, 7 Oct 2016 16:08:09 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id n189so55806447qke.0 for <dnsop@ietf.org>; Fri, 07 Oct 2016 16:08:09 -0700 (PDT)
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:content-transfer-encoding; bh=3QA8JkEy4ArdADj9mhizEjJQj5ntPiChQdpK3iTHntQ=; b=AsEKZmbNgsjm+ZyWWsHhwHQ9OcwAf0Xf3iBq+2ViSoUZeSyAUHzQAjUSTr9KPYGvkX XSf5pF1pBo4mSqwVUhbH7vfnEkbi2ImE0aG+JB/YphQ2V0e0AqK1n15x9+rMTKbWPMu3 GQ6ykNpBmFzVYDFQV5RSyTWhvuz/KRwhwoWx7YBOg7CHxGOni/sDgts6YFt8OvrV6KjJ hDgmZNr77m4oCGE99hCyLonE9+jIZLUS6Y9Vu4yvQCH2+tLVA1Tet86LEbmEHWq+gJ+y a6Mg0GQe9J1GQAzF9YS6oA9HuDsHwHKxEdqtBdGfqfZDT5fcZxSLQlVaHt6reSqZvD0w R3ww==
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:content-transfer-encoding; bh=3QA8JkEy4ArdADj9mhizEjJQj5ntPiChQdpK3iTHntQ=; b=BQZRGrNAqSNBBwfWuJPaQm004ifiTmFzqQguA4+a33Ft6LC7OW09uJqjEld5g459yL ccQSgsM3ICU4i5Viem1SQpPyqCaFNnUqFFAVC6Bc8auHBEB9o02zB0xzYvtXf52p4mcS +91gttNaGLfMQbGpc+uHB3LZlt6Rc9X61kasVAvXbQVTBhj9H0xbP0rQMPT75A8WaWqX 269bM1Kijd8YYLr4PE4ajFJSncRCGW3cSAf1SSDQEhQ8c73Fakwc0j5/0DDk18c7HPBe tU97WGhPAbvx0K/eLQGY/2FsFl8f+J3p0wC438m8zEAb6HLRLhric6cGmkonq4kJ2ISS fCxQ==
X-Gm-Message-State: AA6/9Rlxmg7CTSxM2K+yFd3N37bYCU+9Sbh15aMNUExB9oge+mywYjtVUhpntFnw2/C9EK7/DTm0cqxwo/L/6nRo
X-Received: by 10.55.176.134 with SMTP id z128mr5234348qke.180.1475881688579; Fri, 07 Oct 2016 16:08:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Fri, 7 Oct 2016 16:07:38 -0700 (PDT)
In-Reply-To: <4ef44e6e-441d-60e5-5f39-3a47b2ef6df5@gmail.com>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <CAJE_bqeEBSrFaxEVGhKbt5LFqfe_QdoQQ1u4h9r03ZB3pJ4yzg@mail.gmail.com> <CAHw9_iJDfKK3BPKw5vRc4MBJJELUceSWO4fp97gZjAuB3PZJNg@mail.gmail.com> <CAJE_bqcK_pu4eWkk80ALOeAkCuTV_AoMisFY04q2P6nmZTmGvw@mail.gmail.com> <4ef44e6e-441d-60e5-5f39-3a47b2ef6df5@gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 7 Oct 2016 19:07:38 -0400
Message-ID: <CAHw9_iLmrVMaQHfe4QS+T_wAeo+307OCFAhZ96ULRtKV1gGSnQ@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V4MIQecnno4ETaEV2As3OHjI_K4>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call
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: Fri, 07 Oct 2016 23:08:11 -0000

On Thu, Oct 6, 2016 at 2:49 AM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>
>
> On 10/5/16 2:30 PM, 神明達哉 wrote:
>>
>> At Tue, 4 Oct 2016 17:39:55 -0400,
>> Warren Kumari <warren@kumari.net> wrote:
>>
>>>> - Section 3: this section also has an issue of "recursive resolver".
>>>>   Although it may not be as critical as other part of the draft since
>>>>   it's only used as an example scenario, it's probably better to not
>>>>   limit the role of resolver to avoid misleading.  Maybe "recursive
>>>>   resolver" is just changed to "validating resolver", and
>>>>   "authoritative server" is changed to, e.g., "external servers"
>>>>   (meaning either authoritative or or other recursive servers).
>>>
>>>
>>> DONE.
>>> I did some fix up - how do you like:
>>> "If a validating resolver gets a query for cat.example.com, it will
>>> query the example.com servers and will get back an NSEC (or NSEC3)
>>> record starting that there are no records between apple and elephant.
>>> The resolver then knows that cat.example.com does not exist; however,
>>> it does not use the fact that the proof covers a range (apple to
>>> elephant) to suppress queries for other labels that fall within this
>>> range. This means that if the validating resolver gets a query for
>>> ball.example.com (or dog.example.com) it will once again go off and
>>> query the example.com servers for these names."
>>>
>>> Does that cover it sufficiently? (and I think I now better understand
>>> your concern).
>>
>>
>> To be perfectly generic, "it will query the example.com servers" is
>> not always the case.  It (= validating resolver) might query another
>> intermediate resolver (often called a "forwarder") that performs
>> recursion.  By "external server" I tried to generalize the concept.
>>
>
> Maybe this?
>
> "If a validating resolver receives a query for cat.example.com, it contacts
> its resolver (which may be itself) to query the example.com servers and will
> get back an NSEC (or NSEC3) record starting that there are no records
> between apple and elephant."
>
>> I'm not sure how we address the subtlety without being overly
>> verbose.  Perhaps we can note in the terminology section that this
>> draft generally describes (validating) resolvers as those performing
>> recursive resolution, but the proposal will also work for resolvers
>> that rely on other recursive (or "full service" if you love to use
>> this term) resolvers.  And then we can keep Section 3 as is (as of ver
>> 02).
>
>
> I'm now understanding the distinction you're trying to make.  I've spent
> some time staring at 7719 and 4035 with no better suggestion.
>
>
>>> How is:
>>> "Aggressive use of NSEC / NSEC3 resource records without DNSSEC
>>> validation may create serious security issues, and so this technique
>>> requires DNSSEC validation."? I don't love it, additional suggestions
>>> or text welcomed.
>>
>>
>> To me the main point isn't address with this text.  I might be able to
>> offer alternative text, but can't we perhaps just remove these 2
>> sentences?  In a sense these talk about the obvious, and in other
>> sense it could be even harmful as it can be misleading.
>>
>
> I think you could drop the "Aggressive" and discussing NSEC/NSEC3 records
> w/out validation.  4035 is pretty clear on that

DONE.
I now have:
"Use of NSEC / NSEC3 resource records without DNSSEC validation may
create serious security issues, and so this technique requires DNSSEC
validation."

I could just drop this sentence, but someone (Stephane?) wanted
reinforcement that validation is needed.

W


>
> tim
>



-- 
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