Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt

Carl Clements <> Tue, 11 April 2017 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2500212ECA9 for <>; Tue, 11 Apr 2017 12:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lwFB-YgBR8hf for <>; Tue, 11 Apr 2017 12:27:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EE8B12F24E for <>; Tue, 11 Apr 2017 12:27:22 -0700 (PDT)
Received: from ([] by with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88) (envelope-from <>) id 1cy1Rh-0009RL-59 for; Tue, 11 Apr 2017 19:27:21 +0000
Received: from ([]) by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1cy1Rh-0007mn-4j for; Tue, 11 Apr 2017 19:27:21 +0000
Received: by with SMTP id o79so7882956ioo.14 for <>; Tue, 11 Apr 2017 12:27:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ebRlmicV1hlZDOPKckSVvHniwD1ahzKYTv0zG1n8iSA=; b=W1I1a2Ct5OmkP8ndQ8dbpBzOIEtD2YsX/kqsUJB2x6yY4yBT7o+NsJNEkJl8hOB3wH owWzegEdQNoDmwf79IyjdGv3X6v4zhVIGT2MvxbKBx50xZ2DWMxsZQP8Skw7EJU1XUgy AGwzjYtkl1jniMtCZ3duJ9bXyBeBQhtgXvWO3puSD9xA5VeJLPpvPUz5JNS5aZm2C548 Sq6LkjmF6myzhknRYaYvnsy/B3Cz4ChoJcToOYwlc+guAY7aNkbi8Qr5buRHKlkWEWXy v0MpXN81zOvWBGcSIQKnhPUVzXFc/yL1xRZVHncoKR7VhpTZdfS3rgQpUD2puqGXQu0t MCGg==
X-Gm-Message-State: AFeK/H2nTkUQs/BwpTUiMnCYXKs1X9s4o+3ZSnpuBCY5nf+pAtv+l2nAhkmxbmXG7j3HmfjnXMMxkFIaLWkLL0fJsNM5Y5xdP9iF6rZndpFyfNMe+tE0UmVFVZWzJyTEuHFwwuKp3mKtsNg+ZjQ=
X-Received: by with SMTP id n67mr57647111ion.114.1491938835932; Tue, 11 Apr 2017 12:27:15 -0700 (PDT)
X-Received: by with SMTP id n67mr57647094ion.114.1491938835704; Tue, 11 Apr 2017 12:27:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 11 Apr 2017 12:27:15 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Carl Clements <>
Date: Tue, 11 Apr 2017 15:27:15 -0400
Message-ID: <>
To: Matthew Pounsett <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary=001a1140853c5444d8054ce9146c
Archived-At: <>
X-Mailman-Approved-At: Tue, 11 Apr 2017 12:46:09 -0700
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Apr 2017 19:29:07 -0000

Thanks for this Matt,

My familiarity with IETF I-D best practices is lacking, so I am not sure I
can be of any help regarding most of your questions. However, I do have
some thoughts on this draft.

On 2 August 2016 at 08:38, Matthew Pounsett <> wrote:

> Second, the draft as it currently stands follows the style of 6781 in that
> it doesn't spell out TTL waits between steps in the operator change
> procedure, and leaves it as an exercise for the reader to incorporate
> information from the key roll sections of 6781.  I'm of two minds on this,
> and think it may be useful to spell out the details of the operator change
> procedure even though a thorough reading of the key roll procedures could
> provide the necessary information.

There is one detail that I feel is not explicit enough in 6781 that is
extremely relevant during a DNSSEC operator migration. It is assumed in
this document that DNSKEY_*_A and DNSKEY_*_B use the same signature
algorithm. That assumption is derived from the implication that this
document describes a Double-DS KSK rollover, which is incompatible with an
algorithm rollover even with the liberal approach to Section 2.2 of RFC 4035
<>. I think it would be
helpful to at least reference this implication in section 2.1 of your draft.

My other thought is regarding the instruction to pre-publish DNSKEY_K_B and
post publish DNSKEY_K_A. As far as I can tell, and we have discussed this a
little out of band, the only value provided by publishing and signing this
KSK is to satisfy any over-conservative DS checks performed by the
maintainers of the parent zone. The essential chain of trust "cross
pollination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the
either KSK.

Perhaps there is a reason to publish the other operator's KSK, and so we
leave it as is for good measure? Is it best to avoid mention of this detail
so as to not unnecessarily complicate the document? In my personal opinion
any parent that does not allow addition of DS (for the same algorithm)
before the corresponding KSK appears in the child zone should be corrected,
and thus the document should not recommend the pre- and post-publish of KSK.

Lastly, it looks as though you opted to spell out TTL waits, for example.
For what is it worth, I am in favour of this choice.

Carl Clements