Subject: [DNSOP] [Technical Errata Reported] RFC8624 (6227)

From: RFC Errata System <[email-masked]>
Date: Fri, 10 Jul 2020 01:31:52 -0700 (PDT)

The following errata report has been submitted for RFC8624,
"Algorithm Implementation Requirements and Usage Guidance for DNSSEC".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6227

--------------------------------------
Type: Technical
Reported by: Mats Dufberg <[email-masked]>

Section: 6

Original Text
-------------
   This document has no IANA actions.

Corrected Text
--------------
   This document updates the IANA registry "Delegation Signer (DS) Resource 
   Record (RR) Type Digest Algorithms". The registry has been updated by
   the following table from section 3.3:

   +--------+-----------------+-------------------+-------------------+
   | Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |
   +--------+-----------------+-------------------+-------------------+
   | 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |
   | 1      | SHA-1           | MUST NOT          | MUST              |
   | 2      | SHA-256         | MUST              | MUST              |
   | 3      | GOST R 34.11-94 | MUST NOT          | MAY               |
   | 4      | SHA-384         | MAY               | RECOMMENDED       |
   +--------+-----------------+-------------------+-------------------+

   [*] - This is a special type of CDS record signaling removal of DS at
         the parent in [RFC8078].

   This document updates the IANA registry "DNS Security Algorithm Numbers". 
   The registry has been updated by the following table from section 3.1:

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

Notes
-----
The document clearly has the intention to update the IANA registers, which is also stated in the document, but not in section 6 ("IANA Considerations").

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8624 (draft-ietf-dnsop-algorithm-update-10)
--------------------------------------
Title               : Algorithm Implementation Requirements and Usage Guidance for DNSSEC
Publication Date    : June 2019
Author(s)           : P. Wouters, O. Sury
Category            : PROPOSED STANDARD
Source              : Domain Name System Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jul 2020 10:06:40 -0400 (EDT)

On Fri, 10 Jul 2020, RFC Errata System wrote:

> Subject: [DNSOP] [Technical Errata Reported] RFC8624 (6227)
> 

> Original Text

[...]

> The document clearly has the intention to update the IANA registers, which is also stated in the document, but not in section 6 ("IANA Considerations").

The document did NOT add any columns to the IANA registry. Whether a
successor of this document should do that or not is up to the working
group. Some WG's prefer that recommendations stay in RFC's and IANA
just stays numbers. Other WGs add a column for deprecated/obsoleted

So I think technically, this errata is not correct.

I do agree that a future RFC should add a Notes column where we can
mark an entry as deprecated/obsolete. I do not think we should add
recommended, not recommended here, as the iANA registry itself does
not allow us to explain and clarify why we come to such recommendations
and an implementor cannot really decide on whether to implement a
MAY or NOT REOMMENDED or RECOMMENDED without having more context.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jul 2020 14:18:14 +0000

> The document clearly has the intention to update the IANA registers, which is also stated in the document, but not in section 6 ("IANA Considerations").

This is not true. There is literally no wording in the text that shows such intention.

If the author of this incorrect "errata" wants the IANA registries to reflect the values in RFC 8624, they should create a new Internet Draft saying such. I believe there will be both support and opposition, but it is a good discussion to have now that we have consensus on what the implementation guidance is.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Jul 2020 14:05:34 -0400

Dear DNSOP,

The IESG statement on Errata is here:
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
Some cherry-picks:
"Errata are meant to fix "bugs" in the specification and should not be
used to change what the community meant when it approved the RFC."
"Changes that modify the working of a protocol to something that might
be different from the intended consensus when the document was
approved should be either Hold for Document Update or Rejected.
Deciding between these two depends on judgment. Changes that are
clearly modifications to the intended consensus, or involve large
textual changes, should be Rejected. In unclear situations, small
changes can be Hold for Document Update.
Changes that modify the working of a process, such as changing an IANA
registration procedure, to something that might be different from the
intended consensus when the document was approved should be Rejected."

I personally think it would be useful for the registry to reflect what
is said in RFC 8624, but I don't think that this can be done with an
errata.
Seeing as I have not seen any support / "Oh, dur, that's that we
meant..." I'm going to be closing this as Rejected.

Please let me know by Friday July 24th if you strongly disagree...
W

On Fri, Jul 10, 2020 at 10:18 AM Paul Hoffman <[email-masked]> wrote:
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf