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

[Carl Clements <[e-mail]>]

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 <[e-mail]> 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