IETF Logo Mail Archive

Re: [DNSOP] KSK rollover choices

Russ Housley <housley@vigilsec.com> Thu, 01 November 2018 14:37 UTC

Return-Path: <housley@vigilsec.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 349CA130DE7 for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 07:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 KQyx7HoBSvTM for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 07:37:49 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0702130DC0 for <dnsop@ietf.org>; Thu, 1 Nov 2018 07:37:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 73A35300AB4 for <dnsop@ietf.org>; Thu, 1 Nov 2018 10:37:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2tHummtm0YiQ for <dnsop@ietf.org>; Thu, 1 Nov 2018 10:37:46 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 0DC86300AA5; Thu, 1 Nov 2018 10:37:46 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <3C97B346-B042-41D3-8E32-CFE17F305DE1@isc.org>
Date: Thu, 01 Nov 2018 10:37:46 -0400
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <20A6D389-C460-45B6-821D-BDDA6E8FD47E@vigilsec.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> <E67B15B3-76EB-4857-B400-4CEAA4E46E78@rfc1035.com> <3C97B346-B042-41D3-8E32-CFE17F305DE1@isc.org>
To: Mark Andrews <marka@isc.org>, Jim Reid <jim@rfc1035.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xYHY4-lzZiuuXFfDaveu03WR0no>
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: Thu, 01 Nov 2018 14:37:56 -0000


> On Oct 30, 2018, at 8:27 PM, Mark Andrews <marka@isc.org> wrote:
> 
>> 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.

It is a good time to do rfc5011-bis.  Real world experience from the KSK roll makes a lot os sense to me.

And, an operational considerations section can address the bootstrap issue.

Russ

v2.23.0 | Report a Bug | By Email