Re: [DNSOP] Updated NSEC5 protocol spec and paper

Warren Kumari <warren@kumari.net> Fri, 10 March 2017 17:47 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 40C11129417 for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 09:47:02 -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 b6Dx7Nx1gUMS for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 09:47:00 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 A5C0C129453 for <dnsop@ietf.org>; Fri, 10 Mar 2017 09:47:00 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id p64so178959135qke.1 for <dnsop@ietf.org>; Fri, 10 Mar 2017 09:47:00 -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=Vnmg0w8qWenPMW5SM8kT8d/Jn/Jcibm/MvdHUEMas3c=; b=LxaWyQKWyy/VuzbfGu/0G7R7No7r8tOtXpVOmforZKnjhBiUmHaRwcfsBzFPYUUyXY XZ/0wq1SXdIz3ECJojW80T6zILlFuN4NnvGRIzBcuwGNJ/2C9S2hObgSaDSJtXnAJfwg NzfpUtYY6i/piCdYPT26EC0VkSOFUgHaJUMP9U5rORokPRCiWk3qFnTyD5w/Oi8dpzVx 6QkAbIx3RCbMndBAn3/V9D/QnXlSoe3rvFnnUicXQtAq+ogUDxa8hy2Z8UjY3nn32Ujo eIQ1p9uWmayHt3hXJ4ZWd5VxuMIQo+CYniLhzhJhxt9HZOtDxCj5p62twdjRuUzMYDcj CKxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vnmg0w8qWenPMW5SM8kT8d/Jn/Jcibm/MvdHUEMas3c=; b=A13JLUR9hSaYHPQoTWpiwqZDfBGuIxT8XnQbEZlUw24Saiw2/TJvJd4KYLtqxV/dRe 34y1t0pQ0aZr0ie3/kMey0dqiq5bOAwD45YgnaZCS+RNyBv0sKziFQsn8xLJxpS9N4mg K84c9PwfGUvCuvVYuFwWMRT7+KRqiKT7DnNHKYqE10Hsx0ybiedVBq9atZ9C7bKUHHue w2JFKlolXQPyzPdWKdbfUS3BMT+Tqu7k7oAX+9qb4TW61tTnE2fZljBEwUMlL0ceWnT3 JlzNywypsdJhX1nunxxo5v3NCwUJLXvkgeaX//Sbtmf1Zsczc7Rcw7nvN7krWv7LhTJi 8N4g==
X-Gm-Message-State: AMke39llPISpnmXx8aY7Pi6CJxK9aCrGc1grg/9Z5MoyQ3TxYqoM+u9kKeJ0/RpNBpWdMd9yiSH9OR4O+B1+j1H9
X-Received: by 10.55.201.12 with SMTP id q12mr21078733qki.240.1489168019575; Fri, 10 Mar 2017 09:46:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.177.11 with HTTP; Fri, 10 Mar 2017 09:46:29 -0800 (PST)
In-Reply-To: <20170310172655.GA92236@isc.org>
References: <CAHPuVdXTcSaVcN6fBbPy3e=PgRvg8=GemSN_YFhzX387x8YW-A@mail.gmail.com> <CFBF172D-FDD7-4DE1-B5C5-7C76A7792549@vpnc.org> <A05B583C828C614EBAD1DA920D92866BD06F4468@PODCWMBXEX501.ctl.intranet> <20170310172655.GA92236@isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 10 Mar 2017 12:46:29 -0500
Message-ID: <CAHw9_i+1TLLAkGP_D23R9kLq+0yacXVz70h1SO6CxZcrL4E+RA@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tPCgu3uUds0fpOoEYjDi4fODjGU>
Cc: JW <jw@pcthink.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>, "Woodworth, John R" <John.Woodworth@centurylink.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "Ballew, Dean" <Dean.Ballew@centurylink.com>
Subject: Re: [DNSOP] Updated NSEC5 protocol spec and paper
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, 10 Mar 2017 17:47:02 -0000

Especially with the prevalence of passive DNS services, I believe that
publishing something in the DNS makes it "public" - sure, you can hide
some things behind split-DNS, but putting `super-skrit-key.exmaple.com
IN 600 TXT "Hunter3"` is guaranteed to end poorly.

NSEC5 has some very cute tricks, but I don't agree with the premise
that it solves a real world problem.

W

On Fri, Mar 10, 2017 at 12:26 PM, Evan Hunt <each@isc.org> wrote:
> On Fri, Mar 10, 2017 at 03:16:05PM +0000, Woodworth, John R wrote:
>> > Is there a community of zone admins who want this so much that they
>> > won't start signing until it exists?
>>
>> With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone
>> at least experimenting with this be able to provide 2 sets of keys,
>> one pre-NSEC5 and the other NSEC5 and forward?
>
> I think the question pertains to whether it's worthwhile for us to adopt
> this.
>
> If there are operators who need NSEC5 badly enough that they won't deploy
> DNSSEC until it exists, then it makes sense for the working group to take
> it on. If it turns out, however, that everyone who might like NSEC5 is also
> reasonably satisified with NSEC3, then we'd be wasting time on an academic
> exercise.  It's clever, but it's only necessary if we broadly agree that
> NSEC3 isn't meeting our needs.  I'm not sold on that point.
>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
>
> _______________________________________________
> 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