IETF Logo Mail Archive

Re: [DNSOP] KSK rollover choices

Mark Andrews <marka@isc.org> Wed, 31 October 2018 00:27 UTC

Return-Path: <marka@isc.org>
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 E8AD61277CC for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 17:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 bvJoMPixjlPr for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 17:27:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C29D130DC7 for <dnsop@ietf.org>; Tue, 30 Oct 2018 17:27:43 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 47A503AB040; Wed, 31 Oct 2018 00:27:43 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 325E6160067; Wed, 31 Oct 2018 00:27:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1562916007D; Wed, 31 Oct 2018 00:27:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d6iCSoJRx4iF; Wed, 31 Oct 2018 00:27:43 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6CABC160067; Wed, 31 Oct 2018 00:27:42 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <E67B15B3-76EB-4857-B400-4CEAA4E46E78@rfc1035.com>
Date: Wed, 31 Oct 2018 11:27:40 +1100
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C97B346-B042-41D3-8E32-CFE17F305DE1@isc.org>
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> <E67B15B3-76EB-4857-B400-4CEAA4E46E78@rfc1035.com>
To: Jim Reid <jim@rfc1035.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QHtNFYsnKHch-1n5G5mVpON-7AQ>
Subject: Re: [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:27:47 -0000


> On 31 Oct 2018, at 11:16 am, Jim Reid <jim@rfc1035.com> wrote:
> 
> 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.

Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.

I think we would replace RFC 5011 with something else before we roll the root key next while using RFC 5011 timings for the roll for legacy implementations.  We really need a way to signal how long a TA is expected to be valid for.  This allows machines to safely fail to insecure if they have been off for too long.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email