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

Matthew Pounsett <matt@conundrum.com> Tue, 11 April 2017 21:09 UTC

Return-Path: <matt@conundrum.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 01415126D73 for <dnsop@ietfa.amsl.com>; Tue, 11 Apr 2017 14:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
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 Etx8CFD7cjkl for <dnsop@ietfa.amsl.com>; Tue, 11 Apr 2017 14:09:44 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49431243F6 for <dnsop@ietf.org>; Tue, 11 Apr 2017 14:09:42 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id s68so4951785vke.3 for <dnsop@ietf.org>; Tue, 11 Apr 2017 14:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LCL+EmkeV442XgovrK7vXQ6MJkIUBqGfClIB6I0Y9TY=; b=db/pKhaudscXJFD7XNtjPVbVm25FaEPvuRhPi0Nlg0fOs5oizdUJnwN9LPScP9zc2S WLcibLxrki9Ww0uM4xBsGj2i7sYgYb8syvAwdMyR9b+UvvUcfwHqWosSvltMZKx2k3hD tcjvKCTOHiyJApP639za7UI67DV8EGIl5HZ69uaUoGOVAEYPdSHDXWbUdEEKGh3BD4yo HaMVQFM4UlG1oc5plOzPAF97vGfHsW1seMZU/r9rD6uyHuWvARi+1AakUrhlx7HKyJFa 0pn/s5tatp6saXed2gMiZlYz8xrCOebOPYKj7RVNguGOESwa79vyVjmeTiEp3FInMZ6P nSFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LCL+EmkeV442XgovrK7vXQ6MJkIUBqGfClIB6I0Y9TY=; b=eR/rkFZVCLjBLEwElc50G85l3MdRpotF64FPi8P0bM7vcPurDBwSLa3mUpEZgXJQ0I NX5EzTwN3TbDTxcd5SE/EogseSF8xEv1EbP/n2oX1AW1NRpQv/XkOIAbt3cnpvHGVq8s 6mou7IzDTLgCuj754QqXDrMXIvNNJOYWA0Ky701wFe39u3dmat9Yc++V9+lFB3wy3vTl U2i/bbELQhSIPALqhHfwiaus3/macoEsWSaSNS5qMclA6bY64dlk/NoCoIux8kjPYHFd APQ+xAUSr3LA8pNnFK7veHdqVAKJxxNM/XdVK2YzW/LVOaj4EZDr+jwt1KIe3nKhuUzE eUXw==
X-Gm-Message-State: AN3rC/7XFZpM2NL5ZI+BuYmCoiNCJuUE+ezZMZ07JieZE/3+n4WXuq7xZIKNtvdDu+07mwTVpDZVLSXSY+fbmQ==
X-Received: by 10.31.107.89 with SMTP id g86mr9710063vkc.155.1491944981535; Tue, 11 Apr 2017 14:09:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.45.130 with HTTP; Tue, 11 Apr 2017 14:09:41 -0700 (PDT)
In-Reply-To: <CABTtj7P=M1U9bFghy6ZOTLDOSbcg7ozBVyuKrXR27pL+cL8Fzw@mail.gmail.com>
References: <20160802132253.27847.43026.idtracker@ietfa.amsl.com> <CAAiTEH9JL_abU_JDyiyqSYdQUv-=L+VDyix5A36_vK65i7UUuw@mail.gmail.com> <CABTtj7P=M1U9bFghy6ZOTLDOSbcg7ozBVyuKrXR27pL+cL8Fzw@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Tue, 11 Apr 2017 17:09:41 -0400
Message-ID: <CAAiTEH_FwD-vz2BDcKQ=6QzZ9EEQ377MaOWQY4U8XFMyyzoL2g@mail.gmail.com>
To: Carl Clements <cclement@afilias.info>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a11478678a63cc5054cea8241"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/30oXPGaTCYb8Qlrbm4vr9VrX0nc>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 11 Apr 2017 21:09:46 -0000

On 11 April 2017 at 15:27, Carl Clements <cclement@afilias.info> wrote:

>
> 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 <https://tools.ietf.org/html/rfc4035#section-2.2>. I think it
> would be helpful to at least reference this implication in section 2.1 of
> your draft.
>

This is an excellent point, and I'll add that to the doc ... likely in the
assumptions for now.  More below.


>
> 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.
>

Yeah, the procedure as described in the doc currently is a little
over-cautious with key handling.  It's mainly to simplify the description
of requirements, but I'm planning to change the way it's written out.

One piece of feedback I've received privately is that the document could
benefit from having the *requirements* for a clean transfer spelled out,
and that the procedure be included as an example, possibly of the shortest
path to meet the requirements.  I think that bit of reorganization would
help with the explanation of when it's actually important to
pre/post-publish keys, and coincidentally provide a good place for your
note about algo compatibility to live.

I've been working on text, but it's been a busy few months so I'm not quite
ready to roll -03.


> 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.
>
> I added that in -02 with the long-form description of the procedure.
Given that the intended audience is not intended to be able to work out
this procedure on their own, I thought it was important to be as explicit
as possible.

Thanks for the feedback!