DNSSEC Cryptographic Algorithm Recommendation Update Process
draft-ietf-dnsop-rfc8624-bis-13

Thanks to Magnus Nyström for their multiple secdir reviews!

Section 1.1:  The text in this section is not what I expected in a section titled 'document audience'...Is this draft for implementers?  operators?  My suggestions:  move para 1 and 3 (both can go back into Section 1), put para 5 first, and combine para 2 and 4.  I will note that this suggestion is to improve readability.

Section 4:  What do the '[*]' mean?

*Section 5:  Providing a direct quote from RFC8624 is fine, but then the quote needs to be enclosed in "".  And then the authors can't make changes to it, because that makes it a paraphrase, not a quote.  My opinion, providing the quote/paraphrase here makes future work harder - harder to keep future drafts in sync.  My recommendation is to delete the last three paragraphs and the last phrase of the first paragraph ',which we quote below'.


*should have been a discuss?  maybe....

# Internet AD comments for draft-ietf-dnsop-rfc8624-bis-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3,4

* Probably too late to reorg, and this is a personal opinion, but: I think
  having Use and Implement columns next to each other for the same target
  purpose reads more intuitively.  In other words:

  | algo | Use for Sign | Impl for Sign | Use for Valid | Impl for Valid |

  scans more intuitively, I feel.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-rfc8624-bis-09

# https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8624-bis-09.txt

# General Review
# ==============

# as a general comment i found the draft reasonable easy to read and understand.

21	   RFC8624 to an IANA registry.  This is done both to allow the list to
22	   be more easily updated, and to allow the list to be more easily
23	   referenced.  Future extensions to this registry can be made under
24	   new, incremental update RFCs.  This document also incorporates the
25	   revised IANA DNSSEC considerations from [RFC9157].

GV> The text here mentions a 'list'. The list was not mentioned before and made me wonder what 'list' is intended?

124	   Implementations need to meet both high security expectations as well
125	   as provide interoperability between various vendors and with
126	   different versions.

GV> Maybe swap the word vendor with implementations? one vendor can have multiple procedure implementations that may not interop well together.. been there and done that :-/ 

s/vendors/implementations/

142	   algorithm.  As such this document also adds new recommendations about
143	   which algorithms should be deployed regardless of implementation
144	   status. 

GV> Just a quick question, is it fair to assume that the current recommendation is based on existing operational experience? In other words, do we expect these recommendations to hold up well as deployment matures and stronger cryptographic options become available?

It might be helpful to include a note or reference about how these recommendations are expected to evolve over time, just to give readers a sense of their long-term relevance.

358	   This document makes no modifications to the security of the existing
359	   protocol or recommendations described in [RFC8624].  Thus, the
360	   security considerations remain the same, which we quote below.

GV>  Just a personal and minor stylistic comment. I tend to avoid using the word "we" in formal procedure specifications, as it can be a bit ambiguous. It’s not always clear who "we" refers to, the authors, the working group, or perhaps the IETF as a whole.
Feel free to disregard this if you prefer, but you might consider rephrasing slightly to remove "we" and give the text a more specification-style tone.

Thanks for the work put into this document by the authors and the WG. It is very important and I like the idea of capturing this information in an IANA registry that is easier to consume than a zoo of RFCs with their historic/obsolete/update tags!

Please consider my comments provided for the ECC-GOST document that is running in parallel.

Also, do consider using this document as a complete replacement for 8624 (since things are being moved from that doc into IANA?) and 9157 (since it is about IANA). If this document continues to just "update" them, then we have a trifecta of documents (or may be there are more?). Do see if things could be further simplified for the community that is going to use this work.

Finally, please take this as someone that has not been involved or aware of the past discussions in the WG and more importantly has not been following DNSsec work. Therefore, feel free to just tell me that I am wrong and/or oversimplifying :-)

I want to thank the authors for working on this document. Thanks also to Magnus for providing a robust SECDIR review. I have just one comment.

Section 7.2, paragraph 10
>    *  Update the registration policy for the [DS-IANA] registry to match
>       the text describing update requirements above.
> 
>    *  Mark values 128 - 252 as "Reserved"
> 
>    *  Mark values 253 and 254 as "Reserved for Private Use"
> 
>    *  Delete the (now superfluous) column "Status" from the registry
> 
>    Additionally, the registration policy for the [DS-IANA] registry
>    should match the text describing the requirements in this document.

I think the two statements on "registration policy for the [DS-IANA] registry are confusing. Can we get rid of one of them?

Possible DOWNREF from this Standards Track doc to [DS-IANA]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [DNSKEY-IANA]. If so, the
IESG needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs in the document can probably be converted to HTTPS:

 * http://www.iana.org/assignments/ds-rr-types

"Abstract", paragraph 2
>  the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in 
>                                      ^^^
In American English, abbreviations like "etc." require a period.

"Abstract", paragraph 2
> tus (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in RFC8624;
>                                   ^^^^^^^^^
Consider simply using "of" instead.

Section 1.1, paragraph 4
> less of implementation status. In general it is expected that deployment of 
>                                   ^^^^^^^
A comma is probably missing here.

Section 1.2, paragraph 2
> thms to become used less and less over time. Once an algorithm has reached a
>                                   ^^^^^^^^^
Did you mean "overtime" (=time someone works beyond normal working hours)?

Section 1.2, paragraph 3
> C2119] considers the term SHOULD equivalent to RECOMMENDED, and SHOULD NOT eq
>                                  ^^^^^^^^^^
The word "equivalent" is a noun or an adjective. A verb is missing or
misspelled, or maybe a comma is missing.

# Orie Steele, ART AD, comments for draft-ietf-dnsop-rfc8624-bis-09 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8624-bis-09.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Barry Leiba for the ARTART review. 

### Guidance to DEs for divergence?

```
268	   and "use".  We note that the values for "Implement for" and "Use for"
269	   may diverge in the future
```

The divergence that is expected here is probably that there will be more implementation than use, right?

Some additional guidance to DEs might be helpful here.

## Nits

### KSK expand on first use.

```
391	   Upgrading algorithm at the same time as rolling the new KSK key will
```

Thank you to Gyan Mishra for the GENART review.

I support the DISCUSS position of Mohamed Boucadair.

** Section 1 (and similar text in the abstract)
   To make the current status of
   the algorithms more easily accessible and understandable, and to make
   future changes to these recommendations easier to publish, this
   document moves the canonical status of the algorithms from [RFC8624]
   to the IANA DNSSEC algorithm registries.

-- How is RFC8624 updated and what text says it is canonical?

-- The document appears to take a hybrid approach to pull values from RFC8624 or the registry.

For https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml, it uses RFC8624 as the basis to produce the new registry.  RFC8624 calls value 0 NULL (CDS Only) but the current registry uses a value of “Reserved.”

For https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, it uses the in place registry to provide updates, not RFC8624.  For example, RFC8624  makes no reference to SM3 but it is in the registry.

** Section 2.  What is the set of RFC2119 key words that are permitted?  The text already mentioned MUST, MUST NOT, RECOMMENDED, NOT RECOMMENDED and MAY.  

-- SHOULD and SHOULD NOT were explained as equivalent to RECOMMENDED.  Does that mean that it shouldn’t be used?

-- Can SHALL/SHALL NOT be used?

-- Can OPTIONAL be used?

** Section 2. The text never explicitly explains the semantics of the four new columns.  It has to be inferred from the name.

** Section 3.  What is the relationship between these new columns and the “Zone Signing” and “Trans. Sec.” columns?