[DNSOP] Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-rfc8624-bis-09: (with DISCUSS and COMMENT)

[Wes Hardaker <[e-mail]>]

Mohamed Boucadair via Datatracker <[e-mail]> writes:

Thanks for the review Med...

Comments inline:

> ## Redundant with 8624?
> 
> I spent some time to understand whether this is a bis or an update vs. 8624.
> The diff at
> https://author-tools.ietf.org/diff?doc_1=rfc8624&doc_2=draft-ietf-dnsop-rfc8624-bis
> shows several sections that are common (1.2, 5, 6) with some minor tweaks.
> There is also other text that is in 8624 but was moved around (e.g., 2nd and
> 3rd para of 1.1 or the 2nd para in 1.3).
> 
> If this is an update, then we should explain why redundant text is
> included/needed. Adding a clarification early in the document to explain the
> intent would be sufficient, IMO. Ideally, I'd remove redundant text (e.g., be
> replaced with references to the relevant sections in 8624).

So we [Warren and I] think you're right about the confusion and this is
document actually obsoleting 8624 not updating it.  So we'll change the
reference from "update" to "obsolete" accordingly.  It is a complete
replacement and 8624 shouldn't be used after this.

> ## Deprecated values
> 
> ###
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1
> has the following:
> 
> 12      GOST R 34.10-2001 (DEPRECATED)  ECC-GOST        Y       *      
> [RFC5933][proposed standard][Change the status of GOST Signature Algorithms in
> DNSSEC in the IETF stream to Historic]

So this is where the confusion really comes in and one of the reasons we
wanted to change how this is done.  In the past there were two sources
of information that specified where you should look for current status
of a given algorithm:

1. the IANA tables (which you note deprecates GOST R 34.10-2001).
2. RFC8624 (which talks about implementation requirements and has GOST R
34.10-2001 still listed as MAY)

Thus, the WG decided to:

1. Update 8624 so it no longer contained the implementation guidance and
moved the requirements into the IANA table itself, to address this very
source of confusion.  To ensure that 8624bis would get through without
diving into a debate about particular algorithms, the WG concluded that
8624bis should not change any values at all from 8624 and should just be
about switching how things were done.

2. Issue future documents about changing the values could then be
created to actually make value changes once the IANA registry update was
complete.  The first two documents doing so are the must-not-gost and
must-not-sha1 documents.  These were intentionally written as separate
documents for two reasons:  A) because we didn't know if the WG would
actually want to change those values (IE, it was an independent
discussion) and B) to test the process of the new 862bis procedures.

Technically, the documents could be combined but the history is much
cleaner as 3 separate documents.  In our humble opinion, of course, and
is what the consensus was as well.

> CURRENT:
>  |12|ECC-GOST       |MUST NOT   |MAY        |MUST NOT   |MAY        |
[...]
> CURRENT:
>    |1 |RSAMD5         |MUST NOT   |MUST NOT   |MUST NOT   |MUST NOT   |

You're right that the ECC-GOST algorithm was deprecated in the IANA
table, but it was NOT reflected in 8624, which was the authoritative
source for implementation guidance.  This breakage is exactly what we're
trying to fix.  Future RFCs that deprecate algorithms can now directly
modify the table, as republishing 8624 was deemed to be a heavy lift
fraught with discussions about every list algorithm every time.
Problems solved!

> ## Modification policy
> 
> The registration policy for the two registries is "RFC Required", while the
> deprecated values were modified with a status-change in the past. Should be
> update the policy to be consistent with the practice?

This was intentional and was discussed in the WG and is what we came to
consensus on.  We (the WG) wanted to require RFC updates for any change
to the requirements.

> ## Instructions to fill new columns for some entries in the registry
> 
> There are no instructions about which values to use of the following entries in
> the registry

[...re: private values 252-254...]

This is a fair point, and we will change the document to put MAYs in
thees columns for the two private algorithms.  Note that neither were in
the original 8624 (and thus didn't have values to copy in).

The "reserved for indirect keys" row isn't a zone signing algorithm and
thus not relevant to the new columns and shouldn't have a row.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Abstract
> 
> CURRENT:
>    The document does not change the status (MUST, MAY, RECOMMENDED, etc)
>    of any of the algorithms listed in RFC8624; that is the work of
>    future documents.
> 
> * I would delete the last part of this sentence. No need to commit on something
> that may or may not happen :-) * s/etc/etc.

I think it adds clarification to the purpose of the document and no one
else mentioned it, so I'll leave it unless you have a very strong
opinion about it and want further discussion.

> # Section 1.3
> 
> CURRENT:
>    [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and
>    SHOULD NOT equivalent to NOT RECOMMENDED.  The authors of this
>    document have chosen to use the terms RECOMMENDED and NOT
>    RECOMMENDED, as this more clearly expresses the recommendations to
>    implementers.
> 
> De we really need to say this? This is covered by 2119.

Yes, because we actually added that text directly because of reader
confusion in the past.

> Also, the document when published will reflect the IETF consensus, not authors
> preference.

Good point.  Changed to "This document has chosen..."

> # Section 2:
> 
> ## Table 1 is redundant with Sections 7.1/7.2. I would delete and add a point
> to these sections. Keep the content in one single place.

You're right that it is redundant, but is helpful to the reader in our opinion.

> ## Normative language for IANA considerations
> 
> Section 2 contains many statements that usually fall under an IANA
> considerations section. Example of such text is (but there are other
> occurrences):

Yes, fair point...  most of the document is essentially an IANA updates document.
Some of the text targets implementers/operators but the IANA
considerations really is targeting just what IANA has to do.

> CURRENT:
>    "Implement for DNSSSEC Validation" columns SHALL follow the
>    "Specification Required" policy as defined in [RFC8126] in order to
>    promote continued evolution of DNSSEC algorithms and DNSSEC agility.
>    New entries added through the "Specification Required" process will
>    have the value of "MAY" for all columns.
> 
> When such text is in an IANA cons section, the use of the normative language
> (SHALL) is avoided.

This is text targeting the reader (aka implementers and operators)
though.

> # Section 3: Consider adding IANA notes
> 
> Given that the registry will be authoritative and that this text is important
> to interpret the table, I wonder whether we need to transform some of the text
> into IANA sections. For example,
> 
> CURRENT:
>    When there are multiple RECOMMENDED algorithms in the "use" column,
>    operators should choose the best algorithm according to local policy.

But that's not a recommendation to IANA.  That's (in the sentence
itself) talking to operators.

> # Section 4: [*] meaning
> 
> CURRENT:
>    |0     |NULL (CDS |MUST NOT   |MUST NOT   |MUST NOT  | MUST NOT    |
>    |      |only)     |[*]        |[*]        |[*]       | [*]         |
> 
> Unless I missed, I don’t see where we explain the meaning of [*].

Good catch!  Those were copied from 8624, but the footnote was dropped.
We discussed this and are just going to remove the [*]'s rather than
adding the footnote.

> # Section 6
> 
> The wording in rfc8624  seems more accurate (“a new” instead of “the key”, for
> example).

Changed to something that should work:

   DS algorithm rollover in a live zone is also a complex process.
   Upgrading algorithm at the same time as rolling to the new KSK key will
   lead to DNSSEC validation failures, and users MUST upgrade the DS
   algorithm first before rolling to a new Key Signing Key.

> As indicated above, my preference is to simply point the relevant section in
> 8624.

As indicated above, this is a complete replacement (and now obsoletes 8624).

> ## Nits
> 
> ## idnits is not happy with citations in the abstract
> 
> CURRENT:
>   revised IANA DNSSEC considerations from [RFC9157].

Changed the reference to straight text.

> ## Section 2: Many "register"
> 
> OLD: registries registered with IANA
> 
> NEW: registries maintained by IANA

Done!

Thanks for the comments.
-- 
Wes Hardaker                                     
USC/ISI