| rfc9906.original | rfc9906.txt | |||
|---|---|---|---|---|
| Network Working Group W. Hardaker | Internet Engineering Task Force (IETF) W. Hardaker | |||
| Internet-Draft USC/ISI | Request for Comments: 9906 USC/ISI | |||
| Intended status: Standards Track W. Kumari | Category: Standards Track W. Kumari | |||
| Expires: 5 December 2025 Google | ISSN: 2070-1721 Google | |||
| 3 June 2025 | November 2025 | |||
| Deprecate usage of ECC-GOST within DNSSEC | Deprecate Usage of ECC-GOST within DNSSEC | |||
| draft-ietf-dnsop-must-not-ecc-gost-07 | ||||
| Abstract | Abstract | |||
| This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- | This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- | |||
| GOST") within DNSSEC. | GOST") and GOST R 34.11-94 within DNSSEC. | |||
| RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST | RFC 5933 (Historic) defined the use of GOST R 34.10-2001 and GOST R | |||
| R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This | 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This | |||
| document updates RFC5933 by deprecating the use of ECC-GOST. | document updates RFC 5933 by deprecating the use of ECC-GOST. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
| provisions of BCP 78 and BCP 79. | ||||
| Internet-Drafts are working documents of the Internet Engineering | ||||
| Task Force (IETF). Note that other groups may also distribute | ||||
| working documents as Internet-Drafts. The list of current Internet- | ||||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
| and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
| time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
| material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | ||||
| This Internet-Draft will expire on 5 December 2025. | Information about the current status of this document, any errata, | |||
| and how to provide feedback on it may be obtained at | ||||
| https://www.rfc-editor.org/info/rfc9906. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
| described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
| provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
| in the Revised BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
| 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 | 1.1. Requirements Notation | |||
| 2. Deprecating ECC-GOST algorithms in DNSSEC . . . . . . . . . . 3 | 2. Deprecating ECC-GOST Algorithms in DNSSEC | |||
| 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | 3. Security Considerations | |||
| 4. Operational Considerations . . . . . . . . . . . . . . . . . 3 | 4. Operational Considerations | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | 5. IANA Considerations | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. References | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 6.1. Normative References | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 4 | 6.2. Informative References | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 | Acknowledgments | |||
| Appendix B. Current algorithm usage levels . . . . . . . . . . . 5 | Authors' Addresses | |||
| Appendix C. Github Version of this document . . . . . . . . . . 5 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
| 1. Introduction | 1. Introduction | |||
| The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with | The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented | |||
| the DNS Security Extensions (DNSSEC) [RFC9364] was documented in | in [RFC5933] and their use with DNS Security Extensions (DNSSEC) is | |||
| [RFC5933]. These two algorithms were deprecated by the Orders of the | further described in [RFC9364]. These two algorithms were deprecated | |||
| Federal Agency for Technical Regulation and Metrology of Russia | by the Orders of the Federal Agency for Technical Regulation and | |||
| (Rosstandart) in August 2012, and were superseded by GOST 34.10-2012 | Metrology of Russia (Rosstandart) in August 2012 and were superseded | |||
| and GOST 34.11-2012 respectively. The use of these newer two | by GOST 34.10-2012 and GOST 34.11-2012, respectively. The use of | |||
| algorithms in DNSSEC is documented in [RFC9558] and their associated | these two newer algorithms in DNSSEC is documented in [RFC9558], and | |||
| requirement levels are not changed by this document. | their associated requirement levels are not changed by this document. | |||
| Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and GOST R | Thus, the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R | |||
| 34.11-94 is no longer recommended for use in DNSSEC [RFC9364]. | 34.11-94 is no longer recommended for use in DNSSEC [RFC9364]. | |||
| 1.1. Requirements notation | 1.1. Requirements Notation | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Deprecating ECC-GOST algorithms in DNSSEC | 2. Deprecating ECC-GOST Algorithms in DNSSEC | |||
| The GOST R 34.11-94 [RFC5933] algorithm MUST NOT be used when | The GOST R 34.11-94 algorithm [RFC5933] MUST NOT be used when | |||
| creating DS records. Validating resolvers MUST treat GOST R 34.11-94 | creating Delegation Signer (DS) records. Validating resolvers MUST | |||
| DS records as insecure. If no other DS records of accepted | treat GOST R 34.11-94 DS records as insecure. If no other DS records | |||
| cryptographic algorithms are available, the DNS records below the | of accepted cryptographic algorithms are available, the DNS records | |||
| delegation point MUST be treated as insecure. | below the delegation point MUST be treated as insecure. | |||
| The ECC-GOST [RFC5933] algorithm MUST NOT be used when creating | The GOST R 34.10-2001 algorithm [RFC5933] (mnemonic "ECC-GOST") MUST | |||
| DNSKEY and RRSIG records. Validating resolvers MUST treat RRSIG | NOT be used when creating DNS Public Key (DNSKEY) and Resource Record | |||
| records created from DNSKEY records using these algorithms as an | Signature (RRSIG) records. Validating resolvers MUST treat RRSIG | |||
| unsupported algorithm. If no other RRSIG records of accepted | records created from DNSKEY records using these algorithms as | |||
| unsupported algorithms. If no other RRSIG records of accepted | ||||
| cryptographic algorithms are available, the validating resolver MUST | cryptographic algorithms are available, the validating resolver MUST | |||
| consider the associated resource records as insecure. | consider the associated resource records as insecure. | |||
| 3. Security Considerations | 3. Security Considerations | |||
| This document potentially increases the security of the DNSSEC | This document potentially increases the security of the DNSSEC | |||
| ecosystem by deprecating algorithms that are no longer recommended | ecosystem by deprecating algorithms that are no longer recommended | |||
| for use. | for use. | |||
| 4. Operational Considerations | 4. Operational Considerations | |||
| This document removes support for ECC-GOST. Zone operators currently | This document removes support for ECC-GOST. Zone operators currently | |||
| making use of ECC-GOST based algorithms should switch to algorithms | making use of ECC-GOST-based algorithms should switch to algorithms | |||
| that remain supported. DNS registries should prohibit their clients | that remain supported. DNS registries should prohibit their clients | |||
| from uploading and publishing ECC-GOST based DS records to ensure | from uploading and publishing ECC-GOST-based DS records to ensure | |||
| that they are using algorithms which are supported by DNSSEC | that they are using algorithms that are supported by DNSSEC | |||
| validators, and so can be DNSSEC validated. | validators and thus can be DNSSEC validated. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| [Note to IANA, to be removed by the RFC Editor: the registry fields | IANA has updated the GOST R 34.10-2001 (12) entry in the "DNS | |||
| listed above will be created by draft-ietf-dnsop-rfc8624-bis.] | Security Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] as | |||
| follows: | ||||
| IANA is requested to set the "Use for DNSSEC Signing", "Use for | Number: 12 | |||
| DNSSEC Validation", "Implement for DNSSEC Signing", and "Implement | Description: GOST R 34.10-2001 (DEPRECATED) | |||
| for DNSSEC Validation" columns of the DNS Security Algorithm Numbers | Mnemonic: ECC-GOST | |||
| registry [DNSKEY-IANA] [draft-ietf-dnsop-rfc8624-bis] for ECC-GOST | Zone Signing: Y | |||
| (12) to MUST NOT. Note that previously the "Use for DNSSEC Signing" | Trans. Sec.: * | |||
| and "Implement for DNSSEC Delegation" columns were already MUST NOT. | 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 | ||||
| (https://datatracker.ietf.org/doc/status-change-gost-dnssec-to- | ||||
| historic/), and RFC 9906 | ||||
| IANA is requested to set the "Use for DNSSEC Delegation", "Use for | Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC | |||
| DNSSEC Validation", "Implement for DNSSEC Delegation", and "Implement | Delegation" columns were already set to MUST NOT. | |||
| for DNSSEC Validation" columns of the "Digest Algorithms" registry | ||||
| [DS-IANA] for GOST R 34.11-94 (3) to MUST NOT. Note that previously | IANA has updated the GOST R 34.11-94 (3) entry in the "Digest | |||
| the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" | Algorithms" registry [DS-IANA] as follows: | |||
| columns were already MUST NOT. | ||||
| Value: 3 | ||||
| Description: GOST R 34.11-94 (DEPRECATED) | ||||
| Use for DNSSEC Delegation: MUST NOT | ||||
| Use for DNSSEC Validation: MUST NOT | ||||
| Implement for DNSSEC Delegation: 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 | ||||
| (https://datatracker.ietf.org/doc/status-change-gost-dnssec-to- | ||||
| historic/), and RFC 9906 | ||||
| Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC | ||||
| Delegation" columns were already set to MUST NOT. | ||||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [DNSKEY-IANA] | [DNSKEY-IANA] | |||
| IANA, "Domain Name System Security (DNSSEC) Algorithm | IANA, "DNS Security Algorithm Numbers", | |||
| Numbers", n.d., <https://www.iana.org/assignments/dns-sec- | <https://www.iana.org/assignments/dns-sec-alg-numbers>. | |||
| alg-numbers/dns-sec-alg-numbers.xhtml>. | ||||
| [draft-ietf-dnsop-rfc8624-bis] | ||||
| W., K., "DNS Security Algorithm Numbers", n.d., | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- | ||||
| rfc8624-bis>. | ||||
| [DS-IANA] IANA, "Delegation Signer (DS) Resource Record (RR) Type | [DS-IANA] IANA, "Digest Algorithms", | |||
| Digest Algorithms", n.d., | ||||
| <http://www.iana.org/assignments/ds-rr-types>. | <http://www.iana.org/assignments/ds-rr-types>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of | [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of | |||
| GOST Signature Algorithms in DNSKEY and RRSIG Resource | GOST Signature Algorithms in DNSKEY and RRSIG Resource | |||
| Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July | Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July | |||
| 2010, <https://www.rfc-editor.org/rfc/rfc5933>. | 2010, <https://www.rfc-editor.org/info/rfc5933>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, | [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, | |||
| RFC 9364, DOI 10.17487/RFC9364, February 2023, | RFC 9364, DOI 10.17487/RFC9364, February 2023, | |||
| <https://www.rfc-editor.org/rfc/rfc9364>. | <https://www.rfc-editor.org/info/rfc9364>. | |||
| 6.2. Informative References | [RFC9904] Hardaker, W. and W. Kumari, "DNSSEC Cryptographic | |||
| Algorithm Recommendation Update Process", RFC 9904, | ||||
| DOI 10.17487/RFC9904, November 2025, | ||||
| <https://www.rfc-editor.org/info/rfc9904>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | 6.2. Informative References | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | ||||
| [RFC9558] Makarenko, B. and V. Dolmatov, Ed., "Use of GOST 2012 | [RFC9558] Makarenko, B. and V. Dolmatov, Ed., "Use of GOST 2012 | |||
| Signature Algorithms in DNSKEY and RRSIG Resource Records | Signature Algorithms in DNSKEY and RRSIG Resource Records | |||
| for DNSSEC", RFC 9558, DOI 10.17487/RFC9558, April 2024, | for DNSSEC", RFC 9558, DOI 10.17487/RFC9558, April 2024, | |||
| <https://www.rfc-editor.org/rfc/rfc9558>. | <https://www.rfc-editor.org/info/rfc9558>. | |||
| Appendix A. Acknowledgments | Acknowledgments | |||
| The authors appreciate the comments and suggestions from the | The authors appreciate the comments and suggestions from the | |||
| following IETF participants in helping produce this document: Mark | following IETF participants in helping produce this document: Mark | |||
| Andrews, Steve Crocker, Brian Dickson, Thomas Graf, Russ Housely, | Andrews, Steve Crocker, Brian Dickson, Peter Dickson, Thomas Graf, | |||
| Shumon Huque, Paul Hoffman, S Moonesamy, Peter Dickson, Peter | Paul Hoffman, Russ Housely, Shumon Huque, S. Moonesamy, Peter | |||
| Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the many | Thomassen, Stefan Ubbink, Tim Wicinski, Paul Wouters, and the many | |||
| members of the DNSOP working group that discussed this draft. | members of the DNSOP Working Group that discussed this specification. | |||
| Appendix B. Current algorithm usage levels | ||||
| The DNSSEC scanning project by Viktor Dukhovni and Wes Hardaker | ||||
| highlights the current deployment of various algorithms on the | ||||
| https://stats.dnssec-tools.org/ website. | ||||
| <RFC Editor: please delete this section upon publication> | ||||
| Appendix C. Github Version of this document | ||||
| While this document is under development, it can be viewed, tracked, | ||||
| fill here: | ||||
| https://github.com/hardaker/draft-hardaker-dnsop-must-not-gost | ||||
| <RFC Editor: please delete this section upon publication> | ||||
| Authors' Addresses | Authors' Addresses | |||
| Wes Hardaker | Wes Hardaker | |||
| USC/ISI | USC/ISI | |||
| Email: ietf@hardakers.net | Email: ietf@hardakers.net | |||
| Warren Kumari | Warren Kumari | |||
| Email: warren@kumari.net | Email: warren@kumari.net | |||
| End of changes. 30 change blocks. | ||||
| 121 lines changed or deleted | 119 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||