[DNSOP] Waiting for DNSSEC...

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 02 November 2018 18:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C9200129385 for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 11:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GBUcjqf3TkBp for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 11:30:17 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F5512EB11 for <dnsop@ietf.org>; Fri, 2 Nov 2018 11:30:17 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id A04674551C; Fri, 2 Nov 2018 14:30:15 -0400 (EDT)
Date: Fri, 02 Nov 2018 14:30:15 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <20181102183015.GH4122@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y9O1I0TfhlOa5eiw6LpLqtB5Wn8>
Subject: [DNSOP] Waiting for DNSSEC...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Nov 2018 18:30:20 -0000

[ Was: Fundamental ANAME problems
  Dropped In-Reply-To:, to ensure a new thread. ]

On Fri, Nov 02, 2018 at 06:28:52PM +0100, Måns Nilsson wrote:

> > I'll defer to other people, but it seems to me that anything that depends on
> > recursive DNS servers being updated isn't a realistic solution.  We're still
> > waiting for DNSSEC, after all.
> Be as pessimistic as you like, but in Sweden, more than 80% of the ISP
> resolvers validate. The DNS can change, at a sometimes glacial speed,
> but it does change.

I rather think that updates DNSSEC-capable software are not the
bottleneck for DNSSEC.  The real bottleneck is disincentives to
signing in the form of difficult to use tools, and barriers to KSK
enrollment and rollover at registrars.

To move DNSSEC adoption higher, CDS/CDNSKEY/... need to be supported
by most registries and the signing and key rollover tooling needs
to become less brittle and more user-friendly.

Updates of ZSKs are still too manual.  For example, BIND's "auto-dnssec
maintain" should be able to automatically generate new ZSKs on
master server from time to time, completely without user intervention.

If a zone's parent supports CDS, the same should be possible with
KSKs, but now the server would need to poll the parent zone
periodically to determine whether it can proceed with the key
rollover.  Regardless of CDS support, generating the new KSK and
incorporating it into the zone apex DNSKEY RRset should also be
something that the nameserver can handle internally.  It then
remains only for either CDS, or a manual action by the user to
upload the corresponding DS RRs, to complete the process.

Users *should not* have to run any manual key generation or key
rollover steps, unless they are sophisticated enough to want more

All the magic incantations I have to invoke to keep my zone signed
and rotate keys periodically are I expect a big part of the reason
why many operators shy away from deployment.  With the relevant
bits automated, and a zone audit tool to report whether automated
re-signing is happening in a timely manner as expected, operating
a DNSSEC-signed zone can be no harder than operating one that is
not.  If more zones are signed, the resolvers will come along, they
often already are capable of doing validation, it just needs to be
turned on.

Yes, the ISP-provided CPE router/DNS resolvers will be the long
tail of the adoption curve...  But the ISPs first need to see that
a large fraction of zones are signed, and that those zones are
operating reliably, so that enabling validation is safe and useful.
This gets back to the incentives for the authoritative zones.