[DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-automation-02

[Catherine Meadows via Datatracker <[e-mail]>]

Reviewer: Catherine Meadows
Review result: Has Issues

I have reviewed draft-ietf-cose-type-header-parameters as part of
the security directorate's ongoing effort to review all IETF
documents being processed by the IESG. These comments were written
primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any
other last call comments

I do not see any serious problems with this draft.  However, there are a number
of minor things that need changing that go beyond nits, so I am rating this as
having issues.

1. Comments in the security considerations are all relevant and necessary.  My
only suggestion is to mention that it also inherits the security considerations
of 8901, 8078, and 7477.

2.All acronyms should be defined, e.g. in a glossary.

3. The terms “parent should be defined.

4.  The term “trust mechanism” should be defined.  I assume that goes beyond
just authenticating a principal but determining that it is authorized to do its
job, but this should be stated clearly.

5.  In section 4.2.2 it says

The minimum DNSKEY Waiting Time is the maximum of all DNSKEYS TTL
values from all signers plus the time it takes to publish the zone
on all secondaries.

How is the latter computed?  Or is the way the it is computed left up to the
implementor?

6.  This is the one I had the most trouble with. 4.9.  appears to be saying
that a setup in which different signers use different key  algorithms either
MUST NOT be allowed, or SHOULD be allowed, depending on which RFC you read. 
But then it says “So a Multi-Signer setup where different signers use different
key algorithms should still validate.”   I’m not sure why this conclusion is
made, unless it’s because SHOULD always outranks MUST NOT.  But I don’t see
anything in RFC 2119 about that.  That should be clarified.  Note that this
does not mean I see anything wrong with the reasoning with the rest of 4.9; it
seems reasonable.  But it seems to be discussing a scenario that is already
ruled out by the RFCs, and there no instructions for handling this case in the
current draft.  This needs be clarified.

Finally, some nits:

1. 4.1 number 4: signer or controller, number 4.  I think “signer controller”
should be “signer or controller”

Each Signer to be added, including the initial Signer, must meet the
following prerequisites before joining the Multi-Signer Group
   1. A working setup of the zone, including DNSSEC signing.

If the zone is the zone the Signer is entering, then it can’t be considered an
attribute of the signer.   This is confusing and the wording should be changed.

2. Section 4.9 doesn’t have any content.

3. Security considerations, second paragraph:  “steps to allows” should be
“steps to allow”