Re: [DNSOP] Updated NSEC5 protocol spec and paper

Shumon Huque <shuque@gmail.com> Fri, 10 March 2017 18:15 UTC

Return-Path: <shuque@gmail.com>
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 7CEDF1296A9 for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 10:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zLr0Ya2cQc02 for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 10:15:44 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 8A249129692 for <dnsop@ietf.org>; Fri, 10 Mar 2017 10:15:44 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id p77so28749711ywg.1 for <dnsop@ietf.org>; Fri, 10 Mar 2017 10:15:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k/lrLSTf389g994Qo0TS9qNljd4sMaLAnaViGZbPz1g=; b=STbRPhquHw2H2DSe8HjhvcNZ1KJVSJXQ57v/2+g4DqRxgxJhFs3d6cIV8j4gzLyqTI 3z2O1rKBAPQEthiy6bgJOqKxMD3/tbJKD7Nq5Bm5uUohhvjwNKsCeQCmXWjodNYtPRcm 8E8WYjEiT6VRrGc1HPSt/SpxJJT5PCFHvCOo03N7hpSboBBiAwv2a/t6sC51ca+Fhfat PUVExjNiXpO4EoU79LLN/TIUD9c7OuUy7MTxH0iWaMVPy4Zv9Pg26GMo3DXWbnZ2Zi1b ooIHQrFBUejteu81hYyKoYOpLw8du7bEYmBInPn6Kcu+kmmLNqRxG2Dywf5n3YwOoLQr 3X+w==
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; bh=k/lrLSTf389g994Qo0TS9qNljd4sMaLAnaViGZbPz1g=; b=kgWaxl9YaUVWwyEiIOL82pMBUH1TFfD4Zj+HyR/7a+efSEYCsUv3LUnLkkSOvLoeCV YRNXVZ0hjr5gTv3Ci834XOUm/VOYtfjxfbRoTVyZXAecpwgbVMg2KQKh5Bwy3lczHuZT wzTHZKts0O1oi+EZjXNXvdb0kL7AHjI2yJQwIkEgU1avRdH6XTT33GTYvXc6644CCBub QH8O+tbIyL/Y4ZTV2sc2kS2jsKNoa6dzkzKNU68jZC6SG+2mn/1Ms8EeIum4O8KmXhj0 2Tdf70XS4BpCQhLR1cQK8p5gti+mRfc3B8Uj/sw0LwJLmLraaff63rTlXOIEfYixSKc3 XCUg==
X-Gm-Message-State: AMke39ky21EmsQbhQlclIxWT5FstPAZoBsC0xR961uEFoU6jwKxfM6RwCLFerGcYGoPqVn2dLrsiHhlh8gsugg==
X-Received: by 10.37.50.148 with SMTP id y142mr8437419yby.49.1489169743449; Fri, 10 Mar 2017 10:15:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.50.205 with HTTP; Fri, 10 Mar 2017 10:15:42 -0800 (PST)
In-Reply-To: <CAHw9_i+1TLLAkGP_D23R9kLq+0yacXVz70h1SO6CxZcrL4E+RA@mail.gmail.com>
References: <CAHPuVdXTcSaVcN6fBbPy3e=PgRvg8=GemSN_YFhzX387x8YW-A@mail.gmail.com> <CFBF172D-FDD7-4DE1-B5C5-7C76A7792549@vpnc.org> <A05B583C828C614EBAD1DA920D92866BD06F4468@PODCWMBXEX501.ctl.intranet> <20170310172655.GA92236@isc.org> <CAHw9_i+1TLLAkGP_D23R9kLq+0yacXVz70h1SO6CxZcrL4E+RA@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Fri, 10 Mar 2017 13:15:42 -0500
Message-ID: <CAHPuVdWXGLM6JjR3J53X50W4rcTndiw0UJTKWPxe16WR3znM9Q@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a1146ce52919711054a6459dd
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZMeXRBj0GLsKKAtkkjQwYakhaWY>
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 18:15:46 -0000

Here are some of my arguments in support of NSEC5.

I would like to see us deploy an authenticated denial of existence
mechanism that is not eminently susceptible to offline dictionary
attack. My experience so far is that most people in the crypto
community do not look favorably on NSEC3. Not just Dan Bernstein,
whose strong criticisms are well known (and correct in my opinion).
IETF protocols should pass muster with the professional cryptographer
community.

I don't mean to bash NSEC3 - I think it was the best solution at the
time given the constraints we imposed on ourselves. But it might be
time to look forward.

I certainly agree that the deployment challenges are significant.
But we have several similar challenges already on the radar, which
we will have to tackle:

  - EdDSA

  - NSEC3 hash replacement

    (The recent SHA-1 collision news does not pose an immediate threat
    to NSEC3, but will surely put pressure on us to upgrade the hash
    algorithm on the well known principle that attacks will inevitably
    get better fast.)

  - Post Quantum Crypto algorithms (slightly longer term, but something we
    need to start designing very soon).

I also wonder, given the challenges of deploying new algorithms, and
the downsides to multiple signing due to packet size concerns - is it
time to design an algorithm negotiation protocol for DNSSEC? It would
have the same initial deployment challenge, but then could help out with
new algorithm transitions going forward.

Arguably, there is an additional "implementation challenge" for NSEC5,
which is a bit more complex than rolling out just a new DNSSEC algorithm.
But I think the implementation work already done presents a positive
picture.

I know several additional folks who have expressed interest in NSEC5 -
I hope they'll speak up.

On Fri, Mar 10, 2017 at 12:46 PM, Warren Kumari <warren@kumari.net> wrote:

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

Apparently there are many folks in the community who think so, otherwise
NSEC3 would not have been developed. I personally don't care for any zones
that I run. But if we are providing a solution for folks that do care, we
should
have the most secure (yet practical) solution we know how to design.

-- 
Shumon Huque