Deprecate usage of ECC-GOST within DNSSEC
draft-ietf-dnsop-must-not-ecc-gost-06

[Ballot comment]
** Abstract
  This document retires the use of ECC-GOST within DNSSEC.

I acknowledge that neither “retired” or “historic” (as used in -04) are well defined.  In my view, "ECC-GOST" is already "retired".  RFC5933 has historic status.  Additionally, even without this document making registry updates:

-- https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml already records this code point as deprecated, “GOST R 34.10-2001 (DEPRECATED)”.

-- https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml does the same with “GOST R 34.11-94” by noting a status of “DEPRECATED”.

Practically, I don’t understand the rationale for a separate document to explicitly map “DEPRECATED” to “MUST NOT” and why this couldn’t have just been done with draft-ietf-dnsop-rfc8624-bis-09.  In his ballot on draft-ietf-dnsop-rfc8624-bis, Med points out that RSAMD5, also marked as DEPRECATED, was updated in the registry without a separate document.

** Section 1.
  Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and and GOST R
  34.11-94 is no longer recommended for use in DNSSEC [RFC9364].

-- The text here says, “no longer recommended”, but in Section 2 a much strong statement of “MUST NOT” is use.  Those don’t seem congruent.

** Section 1.  These sentences appear to conflict:

(a) The use of GOST 34.10-2012 and
  GOST 34.11-2012 in DNSSEC is documented in [RFC9558], and so
  [RFC5933] has been made Historic.

(b)  Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and GOST R
  34.11-94 is no longer recommended for use in DNSSEC [RFC9364].

(c)  Note that this document does not change or discuss the use of GOST
  34.10-2012 and GOST 34.11-2012.

By citing RFC9558, sentence (a) "discusses" the use of GOST 34.10-2012/GOST 34.11-2012 which sentence (c) said the text would not do.

Recommend removing sentences (a) and (c).

[Ballot comment]
** Abstract
  This document retires the use of ECC-GOST within DNSSEC.

I acknowledge that neither “retired” or “historic” (as used in -04) are well defined.  In my view, "ECC-GOST" is already "retired".  RFC5933 has historic status.  Additionally, even without this document making registry updates:

-- https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml already records this code point as deprecated, “GOST R 34.10-2001 (DEPRECATED)”.

-- https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml does the same with “GOST R 34.11-94” by noting a status of “DEPRECATED”.

Practically, I don’t understand the rationale for a separate document to explicitly map “DEPRECATED” to “MUST NOT” and why this couldn’t have just been done with draft-ietf-dnsop-rfc8624-bis-09.  In his ballot on draft-ietf-dnsop-rfc8624-bis, Med points out that RSAMD5, also marked as DEPRECATED, was updated in the registry without a separate document.

** Section 1.
  Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and and GOST R
  34.11-94 is no longer recommended for use in DNSSEC [RFC9364].

-- The text here says, “no longer recommended”, but in Section 2 a much strong statement of “MUST NOT” is use.  Those don’t seem congruent.

** Section 1.  The second sentence conflicts with the text in the first.

-- “The use of GOST 34.10-2012 and GOST 34.11-2012 in DNSSEC is documented in [RFC9558], …”

-- “Note that this document does not change or discuss the use of GOST 34.10-2012 and GOST 34.11-2012.”

Recommend removing the reference to RFC9558.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-dnsop-must-not-ecc-gost-04
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-must-not-ecc-gost-04.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.

I support Roman's discuss, and Ketan's comments.

### insecure vs not recognized

```
99   The GOST R 34.11-94 [RFC5933] algorithm MUST NOT be used when
100   creating DS records.  Validating resolvers MUST treat GOST R 34.11-94
101   DS records as insecure.  If no other DS records of accepted
102   cryptographic algorithms are available, the DNS records below the
103   delegation point MUST be treated as insecure.
```

Perhaps use similar text to draft-ietf-dnsop-must-not-sha1-06:

```
Validating resolvers deployed in more security strict environments MAY wish to treat these RRSIG records as an unsupported algorithm.
```

I'm not familiar with the differences between these cases, but it seems like an opportunity to use similar language.

[Ballot discuss]
I agree with the intuition of the authors expressed in the abstract.  Formally updating a document (RFC5922) marked as “historic” doesn’t make sense.

[Ballot comment]
** Abstract
  This document retires the use of ECC-GOST within DNSSEC.

I acknowledge that neither “retired” or “historic” are well defined.  In my view, "ECC-GOST" is already "retired".  RFC5933 has historic status.  Additionally, even without this document making registry updates:

-- https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml already records this code point as deprecated, “GOST R 34.10-2001 (DEPRECATED)”.

-- https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml does the same with “GOST R 34.11-94” by noting a status of “DEPRECATED”.

Practically, I don’t understand the rationale for a separate document to explicitly map “DEPRECATED” to “MUST NOT” and why this couldn’t have just been done with draft-ietf-dnsop-rfc8624-bis-09.  In his ballot on draft-ietf-dnsop-rfc8624-bis, Med points out that RSAMD5, also marked as DEPRECATED, was updated in the registry without a separate document.

** Section 1.
  Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and and GOST R
  34.11-94 is no longer recommended for use in DNSSEC [RFC9364].

-- Editorial. s/and and/

-- The text here says, “no longer recommended”, but in Section 2 a much strong statement of “MUST NOT” is use.  Those don’t seem congruent.

** Section 1.  The second sentence conflicts with the text in the first.

-- “The use of GOST 34.10-2012 and GOST 34.11-2012 in DNSSEC is documented in [RFC9558], …”

-- “Note that this document does not change or discuss the use of GOST 34.10-2012 and GOST 34.11-2012.”

Recommend removing the reference to RFC9558.

[Ballot comment]
Thanks to the authors and the WG for the work on this document.

My comments are specifically related to the document status and not the sum and substance.

1) It seems odd (even wrong?) to update an RFC that has been marked historic. I would suggest to not do that please.

2) Instead this document could update RFC 9364 which is the BCP for DNSsec. It can do that by "inserting" an section related to obsoleted (and MUST NOT use) technologies into that BCP. Start off by putting the ones that are being obsoleted in this document in their and perhaps there may be more such that come up down the line (with future documents that keep that "obsoleted" section up to date?). It seemed to me like a better way to go about this?

3) The IANA marking part could be done in the parallelly progressing document draft-ietf-dnsop-rfc8624-bis with a reference to this document. I am assuming that doing just this step is not sufficient as we want additional text/color about this obsolesce?

Please do correct my understanding if I've misunderstood the game here ... for my own education :-)

[Ballot comment]
Hi Wes/Warren,

Thank you for effort put into this specification.

Please find below some comments:

# Update

CURRENT:
  Updates: 5933 (if approved)

The update to 5933 is not needed here given that the registry already tags 12 as deprecated.

# Why a separate document?

It is tempting to ask why this is not handled as part of draft-ietf-dnsop-rfc8624, though.

Cheers,
Med

[Ballot comment]
Thank you for preparing this short and clear document.

The abstract mentions “ECC-GOST” “DNSSEC” in the first line, it would be helpful to define each when they are first used.

[Ballot comment]

      This document retires the use of ECC-GOST within DNSSEC.

I know ECC-GOST is the mnemonic for value 12, but I think it is confusing since there is another GOST that is also ECC?
Maybe say:

      retures the use of GOST R 34.10-2001 (mnemonic "ECC-GOST")

In the Security or Operational considerations, it would be mentioned this was never deployed beyond a few test zones and the Russian NIC?
And it should say those using it fall back from DNSSEC to DNS, but that is not a big concern because it never saw any real deployment.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-must-not-ecc-gost-03. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-ietf-dnsop-rfc8624-bis.

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/

the existing registration (after execution of the IANA actions in draft-ietf-dnsop-rfc8624-bis) is:

Number: 12
Description: GOST R 34.10-2001 (DEPRECATED)
Mnemonic: ECC-GOST
Zone Signing: Y
Trans. Sec.: *
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: MAY
Implement for DNSSEC Signing: MUST NOT
Implement for DNSSEC Validation: MAY
Reference: [RFC5933][proposed standard][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic]

This registration will be changed to:

Number: 12
Description: GOST R 34.10-2001 (DEPRECATED)
Mnemonic: ECC-GOST
Zone Signing: Y
Trans. Sec.: *
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: MUST NOT
Implement for DNSSEC Signing: MUST NOT
Implement for DNSSEC Validation: MUST NOT
Reference: [RFC5933][proposed standard][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic][ RFC-to-be ]

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/

the existing registration (after execution of the IANA actions in draft-ietf-dnsop-rfc8624-bis) is:

Value: 3
Description: GOST R 34.11-94
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: MAY
Implement for DNSSEC Signing: MUST NOT
Implement for DNSSEC Validation: MAY
Reference: [RFC5933][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic]

This registration will be changed to:

Value: 3
Description: GOST R 34.11-94
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: MUST NOT
Implement for DNSSEC Signing: MUST NOT
Implement for DNSSEC Validation: MUST NOT
Reference: [RFC5933][Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic][ RFC-to-be ]

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-must-not-ecc-gost@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deprecate usage of ECC-GOST within DNSSEC) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Deprecate usage of ECC-GOST
within DNSSEC'
  as 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-06. 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.

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


  This document retires the use of ECC-GOST within DNSSEC.

  RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST
  R 34.11-94 algorithms with DNS Security Extensions (DNSSEC).  This
  document updates RFC5933 by deprecating the use of ECC-GOST.

  [RFC Editor: please remove this before publication: It is unclear if
  updating RFC5933 (a Historic document) is the correct thing to do or
  not.  We did it so that it shows up in Datatracker and similar, but
  this may be a mistake.  We are happy to change this if the RFC Editor
  / IESG / whoever thinks this is a bad idea.]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-ecc-gost/



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

(1)  RFC is Standards Track, and this is the correct RFC type. They are updating Proposed Standards hence it is Proposed Standards.

(2)

Technical Summary:

This document retires the use of ECC-GOST algorithm within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

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) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference Historic 5933, but this is correct.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

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

(2)

Technical Summary:

This document retires the use of ECC-GOST algorithm within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

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) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference Historic 5933, but this is correct.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

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

(2)

Technical Summary:

This document retires the use of ECC-GOST algorithm within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

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) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference Historic 5933, but this is correct.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang