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

From: Carl Clements <[email-masked]>
Date: Tue, 11 Apr 2017 15:27:15 -0400

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 <[email-masked]> 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
<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.

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

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 11 Apr 2017 17:09:41 -0400

On 11 April 2017 at 15:27, Carl Clements <[email-masked]> wrote:

> 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

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.

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