Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

Tony Finch <dot@dotat.at> Wed, 19 September 2012 15:17 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
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 BD63121F874C for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2012 08:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.159
X-Spam-Level:
X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOAluiotEyFM for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2012 08:17:24 -0700 (PDT)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FB21F8754 for <dnsop@ietf.org>; Wed, 19 Sep 2012 08:17:22 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58358) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TEM1h-0000LL-qR (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 19 Sep 2012 16:17:21 +0100
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TEM1g-0005iA-Rb (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 19 Sep 2012 16:17:20 +0100
Date: Wed, 19 Sep 2012 16:17:20 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Peter Koch <pk@DENIC.DE>
In-Reply-To: <20120823214924.GL30725@x28.adm.denic.de>
Message-ID: <alpine.LSU.2.00.1209191537390.1469@hermes-1.csi.cam.ac.uk>
References: <20120823214924.GL30725@x28.adm.denic.de>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Subject: Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 19 Sep 2012 15:17:25 -0000

Sorry, late again, but I have read through the draft and I did not find
any errors. I found an earlier version very useful in getting to grips
with DNSSEC's timing constraints, so I'm keen to see it published. I
really like the formalism and careful presentation style.

I have a couple of observations:

The timelines cover the entire lifetime of a key. This means they
typically cover one and a half rollovers: the key is introduced (then
there's nothing about retiring the old key) then its successor is
introduced, then the key is retired. I find this a bit distracting and I
would prefer it if the timelines were oriented around a single rollover.


Secondly, there is a fairly simple set of rules underlying all rollovers,
which I don't think I have seen written down - the existing descriptions
explain the processes that result from these rules, but leave them
implicit.


For ZSKs, the rules are:

(1) You must remove the old ZSK after adding the new ZSK.

(2) You must remove the old RRSIGs after adding the new RRSIGs.

(3) You must wait for the new ZSK to propagate before removing the old RRSIGs.

(4) You must wait for the new RRSIGs to propagate before removing the old ZSK.

By "propagate" I'm including propagation to all authority servers and
expiration of previous versions of the records from all caches.

Each kind of rollover comes from adding an extra criterion:

Pre-Publication: minimise the time between adding the new RRSIGs and
deleting the old RRSIGs.

Double-Signature: minimise the overall time taken by the process, or
minimise the number of phases.

Double-RRSIG: minimise the time between adding the new ZSK and deleting
the old ZSK.


For KSKs, the rules are:

(5) You must remove the old DS after adding the new DS.

(6) You must remove the old KSK after adding the new KSK.

(7) You must wait for the new DS to propagate before removing the old KSK.

(8) You must wait for the new KSK to propagate before removing the old DS.

Each kind of rollover comes from adding an extra criterion:

Double-Signaure: minimise the time between adding the new DS and removing
the old one.

Double-DS: minimise the time between adding the new KSK and removing the
old one.

Double-RRset: minimise the overall time taken by the process, or
minimise the number of phases.


If you have a single key-type signing model, you need to take the union of
the rules (and rules 1 and 6 combine). The same applies when rolling both
keys at once, e.g. when changing operators. When you are changing
operators, changing the NS records effectively does the adding and
removing implied by the differences between the zones at the old and new
operators.


Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.