Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

Warren Kumari <warren@kumari.net> Tue, 04 October 2016 18:39 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 A6D3B129438 for <dnsop@ietfa.amsl.com>; Tue, 4 Oct 2016 11:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 mn-JHTUvsHLA for <dnsop@ietfa.amsl.com>; Tue, 4 Oct 2016 11:39:29 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 A300F129435 for <dnsop@ietf.org>; Tue, 4 Oct 2016 11:39:29 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id o68so58591941qkf.3 for <dnsop@ietf.org>; Tue, 04 Oct 2016 11:39:29 -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; bh=23wj7D4Mm+AlowWjYSxDHHVbV2tj/lkqiJOXsKBzV/I=; b=LTvmqdrTFCSPmp3Ot9yYDXyyncQG2jrID9719A2Myg0VpR2vI7NrJnCOF7fLSaN+zM QNCs0G8rm4XmTLpRMnQ+z6dHs/50qm+HWBFYPy1xAkFDSq5NLTz5gaHMWxHIIKVducUP u/2gY3JL5qI/UsF5/d5lB5DYv6BNmI6YMsVaQBe7b3Y3w+Jwb1HGLvFlAvdN0/+nKPcy q0I/6Rh2NEjiWMYw0POCUz83DnSwqMXj67aLR2yrkIEeAd8+A8HLCqDwAjTiW+JbBrRr 50JJHogxoftLzprP8iyIY7Xj1cOifl2dfU1htqilA+NeYIxp8Owo7s1z6CV1FXxew7eX y4hw==
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=23wj7D4Mm+AlowWjYSxDHHVbV2tj/lkqiJOXsKBzV/I=; b=RivqdNpiTPFBSATZstGBNMTpCihxpHrsKrMv+rnOqI4wz3H9sCGo6qxTmL8zTMrtCS ZIBogG9idEtDLy7aCkcKLufXgelKtO16TP7LwfGl4ITeBbnDQYtd00OTerIYbGJ8gGQj CUc3tmBiQR6d2dG5jSA48OhAyyeUDlFyQf7fXviu+AjQmI1Co0fhRWDlOyTD0ifKBEPA 7KqXJUm05ouHxuCGtE+oTmcivvg4Ujl4qzapy3xVHwN9/ZCRRuAexxSQHBYNl010TV3A lYGfWALVvOC5h2oM4PkF4L4TksuwzR/jzQHa/utk52LgU54RRTSN3pI3FzUtBpWMdvsB qBKw==
X-Gm-Message-State: AA6/9RlSRyI31ssJ5KPKCfgwJvy1SObck2FonUkE6SCW7x+eVdx9IFJBPjUiunRhov0xpM34hQwBZ1DbMUCjMfUS
X-Received: by 10.55.141.199 with SMTP id p190mr5551430qkd.185.1475606368675; Tue, 04 Oct 2016 11:39:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Tue, 4 Oct 2016 11:38:58 -0700 (PDT)
In-Reply-To: <20160925170411.GB14945@laperouse.bortzmeyer.org>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <20160925170411.GB14945@laperouse.bortzmeyer.org>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 4 Oct 2016 14:38:58 -0400
Message-ID: <CAHw9_iJrgF3w-=0e8XbBLbDNPN9Nyuw15WS7AcZO5LbzBLKR8A@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fT7tU-0P1tC9JClazcPYmCCCYc8>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]
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, 04 Oct 2016 18:39:32 -0000

Apologies all for the delay in responding / addressing comments.
Things suddenly got crazily busy and I fell behind..


On Sun, Sep 25, 2016 at 1:04 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> On Thu, Sep 22, 2016 at 08:19:17AM -0400,
>  Tim Wicinski <tjw.ietf@gmail.com> wrote
>  a message of 31 lines which said:
>
>> This starts a Working Group Last Call for:
>>       "Aggressive use of NSEC/NSEC3"
>>       draft-ietf-dnsop-nsec-aggressiveuse
>
> I like the basic idea and I think the document is good

Yay! :-)

> but I would not like it to be published as it is (-02).

Awwww.....
.
.
.
:-)

>
> My biggest concern is that it seems the original idea was to mention
> only the synthesis of _negative_ replies (NXDOMAIN), _positive_
> replies (synthesis from a wildcard) were mentioned for a long time in
> the draft but never fully integrated. Section 7 mentions this
> synthesis of positive answers but, for instance, the abstract, the
> section 1, section 3, the first paragraph of section 5.5, and the
> first paragraph of section 9 do not mention the positive answers, but
> they should (they seem to assume that only negative caching matters).
>
> Either we need to match the document to put the synthesis of negative
> and positive answers on an equal footing, or we should delete the
> synthesis of positive answers from wildcards.


DONE
Yup, my view (as can probably be guessed!) is that doing this for
negative answers is the important bit, and that wildcard synthesis was
easy to add while we had the hood open (see "shipwright's disease",
which I suffer from greatly[0]). Seeing as the large majority of the
discussion has been about the negative answers, I'm going to remove
the wildcard text.

*Please* WG, let me know if you'd rather that we keep it...

> Related to this issue is the fact that the proposed updated text for
> RFC 4035 is not the same in section 5.1 and in section 7...

DONE
... luckily, the above fixed this issues too :-)

>
> Another concern is section 9 which says "Aggressive use of NSEC /
> NSEC3 resource records without DNSSEC validation may cause security
> problems.  It is highly recommended to apply DNSSEC validation." Not
> only it fails to use RFC 2119 but allowing NXDOMAIN synthesis without
> DNSSEC validation seems dangerous. Why not a MUST instead of the
> current "informal SHOULD"?

DONE
Thank you, good catch. I was not able to figure out how to better word
this, so I rewrote it -- how is this:
"Aggressive use of NSEC / NSEC3 resource records without DNSSEC
validation may create serious security problems, and so this technique
requires DNSSEC validation."



>
> Details
> *******
>
> IMHO, it should say from the beginning that this document is only for
> validating resolvers. (It is not in section 1, for instance.)

DONE.
Yeah. I'd been assuming that all of the mention of NSEC/NSEC3 implied
that, but it doesn't hurt to be explicit. Fixed.

>
> Editorial
> *********
>
> Section 1 says "This document updates RFC 4035 to allow recursive
> resolvers to use NSEC/NSEC3 resource records to aggressively cache
> negative answers."  It would be more descriptive, IMHO, to say "This
> document updates RFC 4035 to allow recursive resolvers to use
> NSEC/NSEC3 resource records to synthetize negative answers from the
> information they have in the cache." (It is an aggressive use of the
> cache, not aggressive caching.)


DONE.
Ooooh, I like it. I used your text....

>
> Bikeshedding
> ************
>
> Section 5.2 says "Implementations SHOULD provide a configuration switch to disable
> aggressive use of NSEC and allow it to be enabled or disabled per
> domain." Such as switch (the per-domain one) seems costly and I would
> prefer a MAY here.
>

DONE.
I wondered the same thing when writing this. I figured easier to ask
for more and dial back if needed.

Thank you again for your comments, I have committed them to the
version in Github (
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse ) and
will publish a new draft soon.


W
[0]: I'm restoring a 1971 Land Rover Series IIA, and a 1980 Ferrari
308GTSi. It is a never-ending task, because I'll start on one thing,
and then, seeing as it's open I may as well do this other small
things... e.g: I have the dashboard out to replace a lamp, so I might
as well replace the ignition switch wiring - it''s slightly tatty.
While doing that, it makes sense to replace the choke cable (it's
mounted on the same panel), which means I may as well also redo the
heater system (the valve is right next to it, and the cables are
joined, so...). Seeing as that it out, there is also the radio, and
some of the wiring - no point in *not* doing it, I'd simply have to
reopen everything again. Oh, the speedometer cable is also back here,
and the speedo bounces around. Seeing as I'm replacing that, I'll
rebuild the (really cool Jaeger speedometer, and it's attached to the
gearbox, so, well, new gearbox oil and diff oil, and then repaint the
undercarriage / remove rust and POR-15 the suspension, and then, well,
those engine mounts are also attached to the gearbox. It's already up
on the lift, so.... Next thing you know it's been months... and I'm
much further from finishing than when I started....


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