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

[Shumon Huque <[e-mail]>]

On Fri, Mar 15, 2024 at 11:56 AM Catherine Meadows via Datatracker <
[e-mail]> wrote:
> 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

Thank you for detailed review Catherine, and apologies for our very
belated response.

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

Yes, I think that's a reasonable suggestion. One other thing I'd like to
do is to expand all acronyms and initialisms at first encounter. And where
a pre-existing definition exists (e.g. in RFC 8499 "DNS Terminology"),
we should reference that.

> 3. The terms “parent should be defined.

Indeed. And we can refer to the definition in RFC 8499, Section 7, which
defines parent, child, and related miscellany.

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

I guess this refers to the following in 4.4:

"Establish a trust mechanism between the Multi-Signer group and the Signer".

I agree that this is unclear and deserves elaboration. We will add some
appropriate text for this. And yes, this is mainly about the zone owner
authorizing
a signer to be part of a multi-signer group.

In the "centralized model", all trust is established by the zone owner,
who has authenticated access to the DNS providers, can verify the
keying material, and exchange it with the other parties in the multi-signer
group (as well as updating the NS set to include the signer's name
servers).

The decentralized model, where DNS providers directly communicate with
each other is not yet fully developed, and has some bootstrapping challenges
that we should be clear about in the document. My co-author, Johan Stenstam,
actually has a more fully fleshed out proposal for this, so let me have a
chat with
him and see if we can incorporate that.

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

Ok, we'll elaborate on this.

For TTLs:

In the centralized model, this is straightforward. The zone owner (or
a central controller acting on behalf of the zone owner) can easily
 performs this computation, since it knows when it has updated the DNSKEY
RRset at each provider and what their TTLs are. In the distributed model,
each signer can note the TTL as the remote ZSKs from other providers are
queried and/or imported.

(Ideally, the DNSKEY RRset TTLs should be the same across all
providers in a multi-signer group, but it's possible that some only
support a fixed value, and the protocol should allow that to work with
the appropriate timing constraints).

For the zone propagation time to all servers:

I don't think there is a precise way to calculate this. Rather, I
think this it typically based on the expected zone update propagation
performance of each provider. Commercial providers often provide SLAs
or SLOs providing such numbers. I took a look at past DNSSEC specs
that deal with timing issues to see if any of them cover this and they
don't appear to. Both RFC 6781 (DNSSEC Operational Practices) and
RFC 7583 (DNSSEC Key Rollover Timing Considerations) mention
propagation delay many times but neither states how to compute it.

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

I understand your confusion.

SHOULD definitely does not outrank MUST. The issue is that some folks in
the DNS protocol community disagree with what is currently specified as a
MUST in this case. In the real world we will come across situations where
providers are using disjoint algorithms only and we want the DNSSEC
automation mechanisms described in this draft to work for them. In
addition to the RFCs quoted, there is also RFC 6781 (DNSSEC Operational
Practices) which outlines a "liberal" approach to algorithm rollovers that
also arguably clashes with the MUST clause.

My personal feeling is that this discussion about what violates the
spec but can work in the field belongs in other documents that are
attempting to formally revise the spec. This document for now could
just state that presently, the signers in a multi-signer group need to
all use the same algorithms. If there is a successful update to the
spec that (conditionally) relaxes the MUST, we can come back and
update this doc.

(Just as an aside though, I've personally set up multi-signer zones in
the field, where each party signed with a different well known algorithm,
and they work fine with all validators I've tested).

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

Yes, thanks.

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

I think what this sentence is trying to say is: if a new signer is being
added
to a multi-signer group for a specific zone, it must first be configured to
serve
that zone, and the zone needs to be signed with its own keys. Does that make
sense? We'll rewrite this section to make that clearer.

>
> 2. Section 4.9 doesn’t have any content.

I'm not sure what was supposed to go there, since timing considerations
are present throughout other sections of the doc. Let me check with my
co-authors. Otherwise, we can delete the section.

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

Ok.

Thanks!
Shumon Huque