IETF Logo Mail Archive

[DNSOP] KSK rollover choices

Jim Reid <jim@rfc1035.com> Wed, 31 October 2018 00:17 UTC

Return-Path: <jim@rfc1035.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 E77CA130DC0 for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 17:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KPZtW4_57HZx for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 17:17:01 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733121277CC for <dnsop@ietf.org>; Tue, 30 Oct 2018 17:17:01 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id B3C022420FD8; Wed, 31 Oct 2018 00:16:58 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <A54BF075-89AB-4460-B0B8-15BA18C5DC18@isc.org>
Date: Wed, 31 Oct 2018 00:16:56 +0000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E67B15B3-76EB-4857-B400-4CEAA4E46E78@rfc1035.com>
References: <00E03DAE-9403-49B2-8489-6F7F35D18534@icann.org> <CAJhMdTP-bh1yeOOCS+08rAMhkgyk6yZa9tpQvZ36rR7N=RoQow@mail.gmail.com> <23511.13515.365128.519464@gro.dd.org> <23511.14092.990015.593983@gro.dd.org> <CABf5zv+1XFPWaaX1x=W5pAK7rC4HYQ2OsQ4vvoADgKaQufjmBw@mail.gmail.com> <A800B089-EC3C-4DEF-95FD-3314ACB311A5@hopcount.ca> <CABf5zvL=VJdzJybYGR6pQFpapS=A9nQuPK-+vR2T7cptRkx5AQ@mail.gmail.com> <alpine.DEB.2.20.1810301103240.24450@grey.csi.cam.ac.uk> <A54BF075-89AB-4460-B0B8-15BA18C5DC18@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fdwBN92x_DBj_FYZyHX1UQyDugI>
Subject: [DNSOP] KSK rollover choices
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: Wed, 31 Oct 2018 00:17:03 -0000

On 30 Oct 2018, at 22:31, Mark Andrews <marka@isc.org> wrote:
> 
> Ultra frequent key rolls are not necessary.  It takes years the latest releases of name servers to make it into shipping OS’s.

So what? Key rollover policies cannot and should not be driven by vendor OS release schedules. Or the BIND/whatever version they choose to distribute. If key rollovers became dependent on these considerations, we’d never be able to roll the root’s KSK.

Software that had hard-wired the old key caused trouble for the recent rollover so we simply have to be in a much better place next time. I hope you don't want to perpetuate that legacy behaviour, albeit in a slightly different form.

If the (hypothetical) problem is DNS software gets shipped with the current KSK on the release date and that might lurk in vendor distributions long after the KSK has rolled, the solution is obvious. Don’t do that.

v2.23.0 | Report a Bug | By Email