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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-rfc8624-bis and RFC 9904, changed IESG state to RFC Published)

RFC Editor Note was changed to
RFC Editor Note

When allocating RFC numbers for this I-D and for the related draft-ietf-dnsop-must-not-ecc-gost, draft-ietf-dnsop-must-not-sha1 , please use three consecutive RFC numbers starting with draft-ietf-dnsop-rfc8624-bis, then draft-ietf-dnsop-must-not-sha1, then draft-ietf-dnsop-must-not-ecc-gost.

Thanks

-éric

[Ballot comment]
Thanks for the discussion on my DISCUSS and COMMENTS raised. While I'm a bit sad none of it was taken in, I have updated my ballot to Yes

[Ballot comment]
Hi Wes/Warren,

Thanks for the discussion and for the changes to address the comments raised in my previous ballot [1].

Please find below some new comments based on a complete review of -11:

# Avoid depending on an obsoleted RFC

OLD:

9.1.  Normative References
  ..
  [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              .

NEW:
9.2.  Informative References
  ..
  [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              .

# Inappropriate use of normative language for IANA actions

CURRENT:
2.2.  Adding and Changing Values

  Adding a new entry to the "DNS System Algorithm Numbers" registry
  with a recommended value of "MAY" in the "Use for DNSSEC Signing",
  "Use for DNSSEC Validation", "Implement for DNSSEC Signing", or
  "Implement for DNSSEC 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.

It is IANA who will follow this policy. I don't see how this targets users. I would reword.

# Add an IANA action to list this document as reference for the two registries.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/WJe09_q64XLCGLgdN189GVf1yXg/

[Ballot comment]
Hi Wes/Warren,

Thanks for the discussion and for the changes to address the comments raised in my previous ballot [1].

Please find below some new comments based on a complete review of -11:

# Avoid depending on an obsoleted RFC

OLD:

9.1.  Normative References
  ..
  [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              .

9.2.  Informative References
  ..
  [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              .

# Inappropriate use of normative language for IANA actions

CURRENT:
2.2.  Adding and Changing Values

  Adding a new entry to the "DNS System Algorithm Numbers" registry
  with a recommended value of "MAY" in the "Use for DNSSEC Signing",
  "Use for DNSSEC Validation", "Implement for DNSSEC Signing", or
  "Implement for DNSSEC 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.

It is IANA who will follow this policy. I don't see how this targets users. I would reword.

# Add an IANA action to list this document as reference for the two registries.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/WJe09_q64XLCGLgdN189GVf1yXg/

[Ballot discuss]
I have some questions I would like to see a short discussion on before balloting Yes


        The columns added to the IANA "DNS Security Algorithm Numbers" [DNSKEY-IANA]

While doing IANA updates, can this document perhaps also update the name "DNS Security
Algorithm Numbers" because it is very confusing. It is only the DNSKEY algorithm numbers,
used in some other records too (eg RRSIG). But there are other algorithm numbers in DNSSEC
too, and which are not covered by this one (eg DS algorithm numbers).

Perhaps "DNS Signature Algorithm Numbers" ?


RECOMMENDED / MUST / MAY

I wonder why the document uses the levels RECOMMENDED with MAY and MUST, instead of either
MAY/SHOULD/MUST or RECOMMENDED/NOT RECOMMENDED/MAY.


        Validating recursive resolvers are encouraged to retain support
        for all algorithms not marked as MUST NOT.

Why "encouraged"? This is a perfect spot to use SHOULD or RECOMMENDED, since
it is aimed at implementers of resolvers.

        When there are multiple RECOMMENDED algorithms in the "use"
        column, operators should choose the best algorithm according to
        local policy.

This reads weird. An operator for a resolver has no real choices for
selecting the best algorithm - the algorithm is set by zone owner, not
the operator of the resolver. I think this sentence should be rewritten
to be signer specific (and publisher specific for DS in the next section),
and a new sentence for resolvers should be added to say something.


It seems the section on Operational Considerations has nothing to do with
this document, as this document doesn't handle algorithm rollovers at all?

What I would consider a related Operational Considerations is for implementers
to start throwing warnings on algorihtms that they plan to remove from their
code before actually removing it from their code causing errors as to give
operators the time to migrate away from them.

[Ballot comment]
        Implementations need to be conservative in the selection
        of algorithms they implement in order to minimize both code
        complexity and the attack surface.

I don't think this is particularly true or relevant. The real issue is that DNS
has a long tail and it becomes very difficult to remove old algorithms, so
introducing new ones should be done with constraint.

        The perspective of implementers may differ from that of an
        operator who wishes to deploy and configure DNSSEC with only
        the safest algorithm.

I think this mixes up implementers/operators with the actual real difference
of resolvers/signers. Signers wish to use the best ones, but resolvers need
to handle older/worse stuff as well.

        Since the effect of using an unknown DNSKEY algorithm is that
        the zone is treated as insecure

I would use "unsigned" instead of "insecure" here.

[Ballot discuss]
Hi Wes, Warren,

Many thanks for the effort put into this specification.

Thanks to Nabeel Cocker for his first OPSDIR review and Wes for promptly engaging with Nabeel.

Also, thanks to Éric, Tim, and authors for taking care comments shared as part of IETF LC (extended LC to PS instead of Info + tag as this update 9157).

I will definitely ballot “Yes”, but I’d like to quickly discuss few points.

# DISCUSS

## Redundant with 8624? (CLOSED)

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

## 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]

While deprecation seems is no reflected in Table 2.

CURRENT:
|12|ECC-GOST      |MUST NOT  |MAY        |MUST NOT  |MAY        |

Note that this deprecated value:

1 RSA/MD5 (DEPRECATED, see 5) RSAMD5 N Y [RFC3110][proposed standard][RFC4034][proposed standard]

was adequately handled in Table 2:

CURRENT:
  |1 |RSAMD5        |MUST NOT  |MUST NOT  |MUST NOT  |MUST NOT  |

### Idem, https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml has the following:

3 GOST R 34.11-94 DEPRECATED [RFC5933][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic]

While, deprecation is not explicitly reflected in Table 3:

CURRENT:
  |3    |GOST R    |MUST NOT  |MAY        |MUST NOT  | MAY        |
  |      |34.11-94  |          |          |          |            |

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

## Instructions to fill new columns for some entries in the registry  (CLOSED)

There are no instructions about which values to use of the following entries in the registry

252 Reserved for Indirect Keys INDIRECT N N [RFC4034][proposed standard]
253 private algorithm PRIVATEDNS  Y Y [RFC4034][proposed standard]
254 private algorithm OID PRIVATEOID Y Y [RFC4034][proposed standard]

[Ballot comment]
# 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
```

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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 :-)

[Ballot comment]

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

[Ballot discuss]
Hi Wes, Warren,

Many thanks for the effort put into this specification.

Thanks to Nabeel Cocker for his first OPSDIR review and Wes for promptly engaging with Nabeel.

Also, thanks to Éric, Tim, and authors for taking care comments shared as part of IETF LC (extended LC to PS instead of Info + tag as this update 9157).

I will definitely ballot “Yes”, but I’d like to quickly discuss few points.

# DISCUSS

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

## 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]

While deprecation seems is no reflected in Table 2.

CURRENT:
|12|ECC-GOST      |MUST NOT  |MAY        |MUST NOT  |MAY        |

Note that this deprecated value:

1 RSA/MD5 (DEPRECATED, see 5) RSAMD5 N Y [RFC3110][proposed standard][RFC4034][proposed standard]

was adequately handled in Table 2:

CURRENT:
  |1 |RSAMD5        |MUST NOT  |MUST NOT  |MUST NOT  |MUST NOT  |

### Idem, https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml has the following:

3 GOST R 34.11-94 DEPRECATED [RFC5933][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic]

While, deprecation is not explicitly reflected in Table 3:

CURRENT:
  |3    |GOST R    |MUST NOT  |MAY        |MUST NOT  | MAY        |
  |      |34.11-94  |          |          |          |            |

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

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

252 Reserved for Indirect Keys INDIRECT N N [RFC4034][proposed standard]
253 private algorithm PRIVATEDNS  Y Y [RFC4034][proposed standard]
254 private algorithm OID PRIVATEOID Y Y [RFC4034][proposed standard]

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

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

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

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

## 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):

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.

You have this right for other parts in that same section, e.g.,

CURRENT:
  Adding a new entry to, or changing existing values in, the "DNS
  System Algorithm Numbers" registry for the "Use for DNSSSEC Signing",
  "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", or
  "Implement for DNSSSEC Validation" columns to any other value than
  "MAY" requires a Standards Action.

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

The are other similar occurrences that are worth considered as well.

# 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 [*].

# Section 6

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

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


## Nits

## idnits is not happy with citations in the abstract

CURRENT:
  revised IANA DNSSEC considerations from [RFC9157].

## Section 2: Many "register"

OLD: registries registered with IANA

NEW: registries maintained by IANA


Cheers,
Med

[Ballot comment]
# 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.

[Ballot comment]
# 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> Can one assume that the recommendation is based upon current experience? w.o.w. will the recommendations age well when experience increases and better crypto is implemented? Potentially add a reference on how well the recommendations will age over time

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> a personal detailed idnit is that i do not like using the word 'we' in formal procedure specs as it leaves open for interpretation who exactly is 'we'? is it the authors, is it the WG or the maybe the IETF. Feel free to ignore this observation or to slightly rephrase the text removing the word 'we' to make it sound more specification style

[Ballot comment]
# 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.

[Ballot comment]
  This document is part of a group of 3 I-Ds. I suggest to start
  reviewing draft-ietf-dnsop-rfc8624-bis first, then the SHA1 and GOST I-Ds.

(1)  RFC is Proposed Standard, and this is the correct RFC type. They are updating an existing document which is on Standards Track.

(2)

Technical Summary:

The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs.

Working Group Summary:

WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict.

Document Quality:

Document quality is very good.  As this document is updating IANA tables, it is
more about documenting existing usage and not about implemenetations.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will update RFC8624, and is listed in all correct places.

(17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries.  The details for updating the registries are clearly laid out.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

The following Last Call announcement was sent out (ends 2025-03-16):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc8624-bis@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Extended Last Call:  (DNSSEC Cryptographic Algorithm Recommendation Update Process) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNSSEC Cryptographic Algorithm
Recommendation Update Process'
  as Proposed Standard

*** The IETF Last Call period is extended until the 16th of March
as the intended status has changed from "informational" to "proposed
standard".***

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-03-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The DNSSEC protocol makes use of various cryptographic algorithms to
  provide authentication of DNS data and proof of non-existence.  To
  ensure interoperability between DNS resolvers and DNS authoritative
  servers, it is necessary to specify both a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document updates RFC8624 by moving the canonical source of algorithm
  implementation requirements and usage guidance for DNSSEC from
  RFC8624 to an IANA registry.  This is done both to allow the list to
  be more easily updated, and to allow the list to be more easily
  referenced.  Future extensions to this registry can be made under
  new, incremental update RFCs.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/



No IPR declarations have been submitted directly on this I-D.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-rfc8624-bis-07. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the DNS Security Algorithm Numbers registry in the Domain Name System Security (DNSSEC) Algorithm Numbers registry group located at:

https://www.iana.org/assignments/dns-sec-alg-numbers/

four new columns will be added to the registry:

Use for DNSSEC Signing
Use for DNSSEC Validation
Implement for DNSSEC Signing
Implement for DNSSEC Validation

The values for these new columns are as follows:

Number Mnemonics Use for DNSSEC Signing Use for DNSSEC Validation Implement for DNSSEC Signing Implement for DNSSEC Validation
--------+-----------+------------------------+---------------------------+-------------------------------+----------------------------------
1 RSAMD5 MUST NOT MUST NOT MUST NOT MUST NOT
3 DSA MUST NOT MUST NOT MUST NOT MUST NOT
5 RSASHA1 NOT RECOMMENDED RECOMMENDED NOT RECOMMENDED MUST
6 DSA-NSEC3-SHA1 MUST NOT MUST NOT MUST NOT MUST NOT
7 RSASHA1-NSEC3-SHA1 NOT RECOMMENDED RECOMMENDED NOT RECOMMENDED MUST
8 RSASHA256 RECOMMENDED RECOMMENDED MUST MUST
10 RSASHA512 NOT RECOMMENDED RECOMMENDED NOT RECOMMENDED MUST
12 ECC-GOST MUST NOT MAY MUST NOT MAY
13 ECDSAP256SHA256 RECOMMENDED RECOMMENDED MUST MUST
14 ECDSAP384SHA384 MAY RECOMMENDED MAY RECOMMENDED
15 ED25519 RECOMMENDED RECOMMENDED RECOMMENDED RECOMMENDED
16 ED448 MAY RECOMMENDED MAY RECOMMENDED

The following note will be added to the registry:

"Adding a new entry to the "DNS System Algorithm Numbers" registry with a recommended value of "MAY" in the "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", or "Implement for DNSSSEC Validation" columns is via the "Specification Required" policy as defined in [RFC8126]. Adding a new entry to, or changing existing values in, the "DNS System Algorithm Numbers" registry for the "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", or "Implement for DNSSSEC Validation" columns to any other value than "MAY" requires a Standards Action."

IANA Question -> IANA understands that for entries that are deprecated or reserved, there are no entries for the new columns. What are the values to be entered for N=17 (SM2 signing algorithm with SM3 hashing algorithm) and N=23 (GOST R 34.10-2012)?

IANA Question -> Are we to keep the "Description" column already existing in the registry?

Second, in the Digest Algorithms registry in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry group located at:

https://www.iana.org/assignments/ds-rr-types/

four new columns are to be added as follows:

Use for DNSSEC Delegation
Use for DNSSEC Validation
Implement for DNSSEC Delegation
Implement for DNSSEC Validation

one existing column will be removed: the "Status" column.

Values 128 - 252 will be marked as "Reserved." Values 253 and 254 as "Reserved for Private Use."

The values for these four new columns are as follows:

Number Description Use for DNSSEC Signing Use for DNSSEC Validation Implement for DNSSEC Signing Implement for DNSSEC Validation
--------+-----------+------------------------+---------------------------+-------------------------------+----------------------------------
0 NULL (CDS only) MUST NOT [*] MUST NOT [*] MUST NOT [*] MUST NOT [*]
1 SHA-1 MUST NOT RECOMMENDED MUST NOT MUST
2 SHA-256 RECOMMENDED RECOMMENDED MUST MUST
3 GOST R 34.11-94 MUST NOT MAY MUST NOT MAY
4 SHA-384 MAY RECOMMENDED MAY RECOMMENDED
5 GOST R 34.11-2012 MAY MAY MAY MAY
6 SM3 MAY MAY MAY MAY

IANA Question --> In the current registry N=0 is given the Description, "Reserved." Should it be changed to "NULL (CDS only)?"

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-03-06):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc8624-bis@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNSSEC Cryptographic Algorithm Recommendation Update Process) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNSSEC Cryptographic Algorithm
Recommendation Update Process'
  as Informational RFC

This document is part of a cluster of 3 DNSOP WG documents and it is
recommended to start with draft-ietf-dnsop-rfc8624-bis before any of
the others (draft-ietf-dnsop-must-not-sha1 and
draft-ietf-dnsop-must-not-ecc-gost).

Abstract


  The DNSSEC protocol makes use of various cryptographic algorithms to
  provide authentication of DNS data and proof of non-existence.  To
  ensure interoperability between DNS resolvers and DNS authoritative
  servers, it is necessary to specify both a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document updates RFC8624 by moving the canonical source of algorithm
  implementation requirements and usage guidance for DNSSEC from
  RFC8624 to an IANA registry.  This is done both to allow the list to
  be more easily updated, and to allow the list to be more easily
  referenced.  Future extensions to this registry can be made under
  new, incremental update RFCs.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/



No IPR declarations have been submitted directly on this I-D.

(1)  RFC is Informational, and this is the correct RFC type. They are updating an Informational draft, hence it is informational.

(2)

Technical Summary:

The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs.

Working Group Summary:

WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict.

Document Quality:

Document quality is very good.  As this document is updating IANA tables, it is
more about documenting existing usage and not about implemenetations.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will update RFC8624, and is listed in all correct places.

(17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries.  The details for updating the registries are clearly laid out.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1)  RFC is Informational, and this is the correct RFC type. They are updating an Informational draft, hence it is informational.

(2)

Technical Summary:

The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs.

Working Group Summary:

WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict.

Document Quality:

Document quality is very good.  As this document is updating IANA tables, it is
more about documenting existing usage and not about implemenetations.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will update RFC8624, and is listed in all correct places.

(17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries.  The details for updating the registries are clearly laid out.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1)  RFC is Informational, and this is the correct RFC type.

(2)

Technical Summary:

The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs.

Working Group Summary:

WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict.

Document Quality:

Document quality is very good.  As this document is updating IANA tables, it is
more about documenting existing usage and not about implemenetations.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will update RFC8624, and is listed in all correct places.

(17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries.  The details for updating the registries are clearly laid out.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1)  RFC is Informational, and this is the correct RFC type.

(2)

Technical Summary:

The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs.

Working Group Summary:

WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict.

Document Quality:

Document quality is very good.  As this document is updating IANA tables, it is
more about documenting existing usage and not about implemenetations.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will update RFC8624, and is listed in all correct places.

(17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries.  The details for updating the registries are clearly laid out.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang