rfc9906xml2.original.xml   rfc9906.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3. cName="draft-ietf-dnsop-must-not-ecc-gost-07" number="9906" updates="" obsoletes
4.2) --> ="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclu
de="true" sortRefs="true" symRefs="true" prepTime="2025-11-30T16:09:17" indexInc
<!DOCTYPE rfc [ lude="true" scripts="Common,Latin" tocDepth="3">
<!ENTITY nbsp "&#160;"> <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-ecc-gos
<!ENTITY zwsp "&#8203;"> t-07" rel="prev"/>
<!ENTITY nbhy "&#8209;"> <link href="https://dx.doi.org/10.17487/rfc9906" rel="alternate"/>
<!ENTITY wj "&#8288;"> <link href="urn:issn:2070-1721" rel="alternate"/>
]>
<?rfc docmapping="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-dnsop-must-not-ecc-gost-07" category=
"std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" s
ymRefs="true">
<front> <front>
<title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate usage of ECC-GOST wi <title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate Usage of ECC-GOST wi
thin DNSSEC</title> thin DNSSEC</title>
<seriesInfo name="RFC" value="9906" stream="IETF"/>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker"> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/ISI</organization> <organization showOnFrontPage="true">USC/ISI</organization>
<address> <address>
<email>ietf@hardakers.net</email> <email>ietf@hardakers.net</email>
</address> </address>
</author> </author>
<author initials="W." surname="Kumari" fullname="Warren Kumari"> <author initials="W." surname="Kumari" fullname="Warren Kumari">
<organization>Google</organization> <organization showOnFrontPage="true">Google</organization>
<address> <address>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<date month="11" year="2025"/>
<date year="2025" month="June" day="03"/> <area>OPS</area>
<workgroup>dnsop</workgroup>
<abstract> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document retires the use of GOS
<?line 53?> T R 34.10-2001 (mnemonic
"ECC-GOST") and GOST R 34.11-94 within DNSSEC.</t>
<t>This document retires the use of GOST R 34.10-2001 (mnemonic <t indent="0" pn="section-abstract-2">RFC 5933 (Historic) defined the use
"ECC-GOST") within DNSSEC.</t> of GOST R 34.10-2001 and GOST R 34.11-94
algorithms with DNS Security Extensions (DNSSEC).
<t>RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11- This document updates RFC 5933
94
algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933
by deprecating the use of ECC-GOST.</t> by deprecating the use of ECC-GOST.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9906" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
quirements-notation">Requirements Notation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-deprecating-ec
c-gost-algori">Deprecating ECC-GOST Algorithms in DNSSEC</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-operational-considerations">Operat
ional Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments
</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addr
esses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
<?line 62?> ude" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t indent="0" pn="section-1-1">The GOST R 34.10-2001 and GOST R 34.11-94 a
lgorithms are documented in <xref target="RFC5933" format="default" sectionForma
<t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with t="of" derivedContent="RFC5933"/> and their use with DNS Security Extensions (DN
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"></xref> was document SSEC) is further described in <xref target="RFC9364" format="default" sectionFor
ed in mat="of" derivedContent="RFC9364"/>. These two algorithms were deprecated by the
<xref target="RFC5933"/>. These two algorithms were deprecated by the Orders of Orders of the
the
Federal Agency for Technical Regulation and Metrology of Russia Federal Agency for Technical Regulation and Metrology of Russia
(Rosstandart) in August 2012, and were superseded by GOST 34.10-2012 (Rosstandart) in August 2012 and were superseded by GOST 34.10-2012
and GOST 34.11-2012 respectively. The use of these newer two and GOST 34.11-2012, respectively. The use of these two newer
algorithms in DNSSEC is documented in <xref target="RFC9558"/> and their associa algorithms in DNSSEC is documented in <xref target="RFC9558" format="default" se
ted ctionFormat="of" derivedContent="RFC9558"/>, and their associated
requirement levels are not changed by this document.</t> requirement levels are not changed by this document.</t>
<t indent="0" pn="section-1-2">Thus, the use of GOST R 34.10-2001 (mnemoni
<t>Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and GOST R 34.11-94 c "ECC-GOST") and GOST R 34.11-94
is no longer recommended for use in DNSSEC <xref target="RFC9364"/>.</t> is no longer recommended for use in DNSSEC <xref target="RFC9364" format="defaul
t" sectionFormat="of" derivedContent="RFC9364"/>.</t>
<section anchor="requirements-notation"><name>Requirements notation</name> <section anchor="requirements-notation" numbered="true" removeInRFC="false
" toc="include" pn="section-1.1">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name slugifiedName="name-requirements-notation">Requirements Notation</
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", name>
and "OPTIONAL" in this document are to be interpreted as described <t indent="0" pn="section-1.1-1">
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
en, they appear IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
in all capitals, as shown here.</t> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
</section> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec"><name>Deprecating EC described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
C-GOST algorithms in DNSSEC</name> f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
<t>The GOST R 34.11-94 <xref target="RFC5933"/> algorithm MUST NOT be used when when, and only when, they appear in all capitals, as shown here.
creating DS records. Validating resolvers MUST treat GOST R 34.11-94 </t>
</section>
</section>
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec" numbered="true"
removeInRFC="false" toc="include" pn="section-2">
<name slugifiedName="name-deprecating-ecc-gost-algori">Deprecating ECC-GOS
T Algorithms in DNSSEC</name>
<t indent="0" pn="section-2-1">The GOST R 34.11-94 algorithm <xref target=
"RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/> <bcp14>
MUST NOT</bcp14> be used when
creating Delegation Signer (DS) records. Validating resolvers <bcp14>MUST</bcp1
4> treat GOST R 34.11-94
DS records as insecure. If no other DS records of accepted DS records as insecure. If no other DS records of accepted
cryptographic algorithms are available, the DNS records below the cryptographic algorithms are available, the DNS records below the
delegation point MUST be treated as insecure.</t> delegation point <bcp14>MUST</bcp14> be treated as insecure.</t>
<t indent="0" pn="section-2-2">The GOST R 34.10-2001 algorithm <xref targe
<t>The ECC-GOST <xref target="RFC5933"/> algorithm MUST NOT be used when creatin t="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/> (mnem
g onic "ECC-GOST") <bcp14>MUST NOT</bcp14> be used when creating DNS Public Key (D
DNSKEY and RRSIG records. Validating resolvers MUST treat NSKEY) and Resource Record Signature (RRSIG) records. Validating resolvers <bcp
RRSIG records created from DNSKEY records using these algorithms as an 14>MUST</bcp14> treat
unsupported algorithm. If no other RRSIG records of accepted cryptographic RRSIG records created from DNSKEY records using these algorithms as
algorithms are available, the validating resolver MUST consider the unsupported algorithms. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver <bcp14>MUST</bcp14> consider t
he
associated resource records as insecure.</t> associated resource records as insecure.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" removeInRFC="false
<section anchor="security-considerations"><name>Security Considerations</name> " toc="include" pn="section-3">
<name slugifiedName="name-security-considerations">Security Considerations
<t>This document potentially increases the security of the DNSSEC ecosystem by </name>
<t indent="0" pn="section-3-1">This document potentially increases the sec
urity of the DNSSEC ecosystem by
deprecating algorithms that are no longer recommended for use.</t> deprecating algorithms that are no longer recommended for use.</t>
</section>
</section> <section anchor="operational-considerations" numbered="true" removeInRFC="fa
<section anchor="operational-considerations"><name>Operational Considerations</n lse" toc="include" pn="section-4">
ame> <name slugifiedName="name-operational-considerations">Operational Consider
ations</name>
<t>This document removes support for ECC-GOST. Zone operators currently making u <t indent="0" pn="section-4-1">This document removes support for ECC-GOST.
se Zone operators currently making use
of ECC-GOST based algorithms should switch to algorithms that remain supported. of ECC-GOST-based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing DNS registries should prohibit their clients from uploading and publishing
ECC-GOST based DS records to ensure that they are using algorithms which are ECC-GOST-based DS records to ensure that they are using algorithms that are
supported by DNSSEC validators, and so can be DNSSEC validated.</t> supported by DNSSEC validators and thus can be DNSSEC validated.</t>
</section>
</section> <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<section anchor="iana-considerations"><name>IANA Considerations</name> c="include" pn="section-5">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>[Note to IANA, to be removed by the RFC Editor: the registry fields <t indent="0" pn="section-5-1"> IANA has updated the GOST R 34.10-2001 (1
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t> 2) entry in the "DNS
Security Algorithm Numbers" registry <xref target="DNSKEY-IANA" format="defau
<t>IANA is requested to set the "Use for DNSSEC Signing", "Use for DNSSEC lt" sectionFormat="of" derivedContent="DNSKEY-IANA"/> <xref target="RFC9904" for
Validation", "Implement for DNSSEC Signing", and "Implement for DNSSEC mat="default" sectionFormat="of" derivedContent="RFC9904"/> as
Validation" columns of the DNS Security Algorithm Numbers registry follows: </t>
<xref target="DNSKEY-IANA"/> <xref target="draft-ietf-dnsop-rfc8624-bis"/> for E <dl spacing="compact" indent="3" newline="false" pn="section-5-2">
CC-GOST (12) <dt pn="section-5-2.1">Number:</dt>
to MUST NOT. Note that previously <dd pn="section-5-2.2"> 12</dd>
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" <dt pn="section-5-2.3">Description:</dt>
columns were already MUST NOT.</t> <dd pn="section-5-2.4"> GOST R 34.10-2001 (DEPRECATED)</dd>
<dt pn="section-5-2.5">Mnemonic:</dt>
<t>IANA is requested to set the "Use for DNSSEC Delegation", "Use for DNSSEC <dd pn="section-5-2.6"> ECC-GOST </dd>
Validation", "Implement for DNSSEC Delegation", and "Implement for DNSSEC <dt pn="section-5-2.7">Zone Signing:</dt>
Validation" columns of the "Digest Algorithms" registry <xref target="DS-IANA"/> <dd pn="section-5-2.8"> Y </dd>
for GOST R 34.11-94 (3) to MUST NOT. Note that previously <dt pn="section-5-2.9">Trans. Sec.:</dt>
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" <dd pn="section-5-2.10"> * </dd>
columns were already MUST NOT.</t> <dt pn="section-5-2.11">Use for DNSSEC Signing:</dt>
<dd pn="section-5-2.12">
</section> <bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-2.13">Use for DNSSEC Validation:</dt>
<dd pn="section-5-2.14">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-2.15">Implement for DNSSEC Signing:</dt>
<dd pn="section-5-2.16">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-2.17">Implement for DNSSEC Validation:</dt>
<dd pn="section-5-2.18">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-2.19">Reference:</dt>
<dd pn="section-5-2.20">
<xref target="RFC5933" format="default" sectionFormat="of" derivedCont
ent="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-go
st-dnssec-to-historic/" brackets="none">Change the status of GOST
Signature Algorithms in DNSSEC in the IETF stream to
Historic</eref>, and RFC 9906</dd>
</dl>
<t indent="0" pn="section-5-3">
Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC
Delegation" columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
<t indent="0" pn="section-5-4">
IANA has updated the GOST R 34.11-94 (3) entry in the "Digest Algorithms"
registry <xref target="DS-IANA" format="default" sectionFormat="of" derivedCo
ntent="DS-IANA"/> as follows:
</t>
<dl spacing="compact" indent="3" newline="false" pn="section-5-5">
<dt pn="section-5-5.1">Value:</dt>
<dd pn="section-5-5.2"> 3</dd>
<dt pn="section-5-5.3">Description:</dt>
<dd pn="section-5-5.4"> GOST R 34.11-94 (DEPRECATED)</dd>
<dt pn="section-5-5.5">Use for DNSSEC Delegation:</dt>
<dd pn="section-5-5.6">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-5.7">Use for DNSSEC Validation:</dt>
<dd pn="section-5-5.8">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-5.9">Implement for DNSSEC Delegation:</dt>
<dd pn="section-5-5.10">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-5.11">Implement for DNSSEC Validation:</dt>
<dd pn="section-5-5.12">
<bcp14>MUST NOT</bcp14></dd>
<dt pn="section-5-5.13">Reference:</dt>
<dd pn="section-5-5.14">
<xref target="RFC5933" format="default" sectionFormat="of" derivedCont
ent="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-go
st-dnssec-to-historic/" brackets="none">Change the status of GOST
Signature Algorithms in DNSSEC in the IETF stream to
Historic</eref>, and RFC 9906</dd>
</dl>
<t indent="0" pn="section-5-6">
Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references" pn="section-6">
<references title='References' anchor="sec-combined-references"> <name slugifiedName="name-references">References</name>
<references anchor="sec-normative-references" pn="section-6.1">
<references title='Normative References' anchor="sec-normative-references"> <name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2119"> <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments
<front> /dns-sec-alg-numbers" quoteTitle="true" derivedAnchor="DNSKEY-IANA">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <front>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <title>DNS Security Algorithm Numbers</title>
<date month="March" year="1997"/> <author>
<abstract> <organization showOnFrontPage="true">IANA</organization>
<t>In many standards track documents several words are used to signify the </author>
requirements in the specification. These words are often capitalized. This docu </front>
ment defines these words as they should be interpreted in IETF documents. This d </reference>
ocument specifies an Internet Best Current Practices for the Internet Community, <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-r
and requests discussion and suggestions for improvements.</t> r-types" quoteTitle="true" derivedAnchor="DS-IANA">
</abstract> <front>
</front> <title>Digest Algorithms</title>
<seriesInfo name="BCP" value="14"/> <author>
<seriesInfo name="RFC" value="2119"/> <organization showOnFrontPage="true">IANA</organization>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> </author>
</reference> </front>
<reference anchor="RFC5933"> </reference>
<front> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records 119" quoteTitle="true" derivedAnchor="RFC2119">
for DNSSEC</title> <front>
<author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov <title>Key words for use in RFCs to Indicate Requirement Levels</tit
"/> le>
<author fullname="A. Chuprina" initials="A." surname="Chuprina"/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<author fullname="I. Ustinov" initials="I." surname="Ustinov"/> <date month="March" year="1997"/>
<date month="July" year="2010"/> <abstract>
<abstract> <t indent="0">In many standards track documents several words are
<t>This document describes how to produce digital signatures and hash func used to signify the requirements in the specification. These words are often cap
tions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRS italized. This document defines these words as they should be interpreted in IET
IG, and DS resource records, for use in the Domain Name System Security Extensio F documents. This document specifies an Internet Best Current Practices for the
ns (DNSSEC).</t> Internet Community, and requests discussion and suggestions for improvements.</t
</abstract> >
</front> </abstract>
<seriesInfo name="RFC" value="5933"/> </front>
<seriesInfo name="DOI" value="10.17487/RFC5933"/> <seriesInfo name="BCP" value="14"/>
</reference> <seriesInfo name="RFC" value="2119"/>
<reference anchor="RFC9364"> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<front> </reference>
<title>DNS Security Extensions (DNSSEC)</title> <reference anchor="RFC5933" target="https://www.rfc-editor.org/info/rfc5
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> 933" quoteTitle="true" derivedAnchor="RFC5933">
<date month="February" year="2023"/> <front>
<abstract> <title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource
<t>This document describes the DNS Security Extensions (commonly called "D Records for DNSSEC</title>
NSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of <author fullname="V. Dolmatov" initials="V." role="editor" surname="
others. One purpose is to introduce all of the RFCs in one place so that the re Dolmatov"/>
ader can understand the many aspects of DNSSEC. This document does not update an <author fullname="A. Chuprina" initials="A." surname="Chuprina"/>
y of those RFCs. A second purpose is to state that using DNSSEC for origin authe <author fullname="I. Ustinov" initials="I." surname="Ustinov"/>
ntication of DNS data is the best current practice. A third purpose is to provid <date month="July" year="2010"/>
e a single reference for other documents that want to refer to DNSSEC.</t> <abstract>
</abstract> <t indent="0">This document describes how to produce digital signa
</front> tures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorit
<seriesInfo name="BCP" value="237"/> hms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name Syste
<seriesInfo name="RFC" value="9364"/> m Security Extensions (DNSSEC).</t>
<seriesInfo name="DOI" value="10.17487/RFC9364"/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="5933"/>
<reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec <seriesInfo name="DOI" value="10.17487/RFC5933"/>
-alg-numbers/dns-sec-alg-numbers.xhtml"> </reference>
<front> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title> 174" quoteTitle="true" derivedAnchor="RFC8174">
<author initials="" surname="IANA" fullname="IANA"> <front>
<organization></organization> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
</author> tle>
<date year="n.d."/> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
</front> <date month="May" year="2017"/>
</reference> <abstract>
<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types" <t indent="0">RFC 2119 specifies common key words that may be used
> in protocol specifications. This document aims to reduce the ambiguity by clari
<front> fying that only UPPERCASE usage of the key words have the defined special meanin
<title>Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</t gs.</t>
itle> </abstract>
<author initials="" surname="IANA" fullname="IANA"> </front>
<organization></organization> <seriesInfo name="BCP" value="14"/>
</author> <seriesInfo name="RFC" value="8174"/>
<date year="n.d."/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</front> </reference>
</reference> <reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9
<reference anchor="draft-ietf-dnsop-rfc8624-bis" target="https://datatracker.iet 364" quoteTitle="true" derivedAnchor="RFC9364">
f.org/doc/html/draft-ietf-dnsop-rfc8624-bis"> <front>
<front> <title>DNS Security Extensions (DNSSEC)</title>
<title>DNS Security Algorithm Numbers</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author initials="K." surname="W." fullname="Kumari, W."> <date month="February" year="2023"/>
<organization></organization> <abstract>
</author> <t indent="0">This document describes the DNS Security Extensions
<date year="n.d."/> (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as w
</front> ell as a handful of others. One purpose is to introduce all of the RFCs in one p
</reference> lace so that the reader can understand the many aspects of DNSSEC. This document
does not update any of those RFCs. A second purpose is to state that using DNSS
</references> EC for origin authentication of DNS data is the best current practice. A third p
urpose is to provide a single reference for other documents that want to refer t
<references title='Informative References' anchor="sec-informative-reference o DNSSEC.</t>
s"> </abstract>
</front>
<reference anchor="RFC9558"> <seriesInfo name="BCP" value="237"/>
<front> <seriesInfo name="RFC" value="9364"/>
<title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Re <seriesInfo name="DOI" value="10.17487/RFC9364"/>
cords for DNSSEC</title> </reference>
<author fullname="B. Makarenko" initials="B." surname="Makarenko"/> <reference anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9
<author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov 904" quoteTitle="true" derivedAnchor="RFC9904">
"/> <front>
<date month="April" year="2024"/> <title>DNSSEC Cryptographic Algorithm Recommendation Update Process<
<abstract> /title>
<t>This document describes how to produce digital signatures and hash func <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
tions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, R <organization showOnFrontPage="true">USC/ISI</organization>
RSIG, and DS resource records, for use in the Domain Name System Security Extens </author>
ions (DNSSEC).</t> <author initials="W." surname="Kumari" fullname="Warren Kumari">
</abstract> <organization showOnFrontPage="true">Google</organization>
</front> </author>
<seriesInfo name="RFC" value="9558"/> <date month="November" year="2025"/>
<seriesInfo name="DOI" value="10.17487/RFC9558"/> </front>
</reference> <seriesInfo name="RFC" value="9904"/>
<reference anchor="RFC8174"> <seriesInfo name="DOI" value="10.17487/RFC9904"/>
<front> </reference>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> </references>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <references anchor="sec-informative-references" pn="section-6.2">
<date month="May" year="2017"/> <name slugifiedName="name-informative-references">Informative References
<abstract> </name>
<t>RFC 2119 specifies common key words that may be used in protocol specif <reference anchor="RFC9558" target="https://www.rfc-editor.org/info/rfc9
ications. This document aims to reduce the ambiguity by clarifying that only UPP 558" quoteTitle="true" derivedAnchor="RFC9558">
ERCASE usage of the key words have the defined special meanings.</t> <front>
</abstract> <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Res
</front> ource Records for DNSSEC</title>
<seriesInfo name="BCP" value="14"/> <author fullname="B. Makarenko" initials="B." surname="Makarenko"/>
<seriesInfo name="RFC" value="8174"/> <author fullname="V. Dolmatov" initials="V." role="editor" surname="
<seriesInfo name="DOI" value="10.17487/RFC8174"/> Dolmatov"/>
</reference> <date month="April" year="2024"/>
<abstract>
<t indent="0">This document describes how to produce digital signa
tures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algor
ithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name Sys
tem Security Extensions (DNSSEC).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9558"/>
<seriesInfo name="DOI" value="10.17487/RFC9558"/>
</reference>
</references>
</references> </references>
<section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="
</references> include" pn="section-appendix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<?line 135?> <t indent="0" pn="section-appendix.a-1">The authors appreciate the comment
s and suggestions from the
<section anchor="acknowledgments"><name>Acknowledgments</name> following IETF participants in helping produce this document: <contact ful
lname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact fullname="
<t>The authors appreciate the comments and suggestions from the following IETF Brian Dickson"/>, <contact fullname="Peter Dickson"/>, <contact fullname="Thomas
participants in helping produce this document: Mark Andrews, Steve Crocker, Graf"/>, <contact fullname="Paul Hoffman"/>, <contact fullname="Russ Housely"/
Brian Dickson, Thomas Graf, Russ Housely, Shumon Huque, Paul Hoffman, S Moonesam >, <contact fullname="Shumon Huque"/>, <contact fullname="S. Moonesamy"/>, <cont
y, Peter act fullname="Peter Thomassen"/>,
Dickson, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the <contact fullname="Stefan Ubbink"/>,
many members of the DNSOP working group that discussed this draft.</t> <contact fullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, an
d the many members of the DNSOP
</section> Working Group that discussed this specification.</t>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage l </section>
evels</name> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<t>The DNSSEC scanning project by Viktor Dukhovni and Wes Hardaker <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
highlights the current deployment of various algorithms on the <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
https://stats.dnssec-tools.org/ website.</t> <organization showOnFrontPage="true">USC/ISI</organization>
<address>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t> <email>ietf@hardakers.net</email>
</address>
</section> </author>
<section anchor="github-version-of-this-document"><name>Github Version of this d <author initials="W." surname="Kumari" fullname="Warren Kumari">
ocument</name> <organization showOnFrontPage="true">Google</organization>
<address>
<t>While this document is under development, it can be viewed, tracked, <email>warren@kumari.net</email>
fill here:</t> </address>
</author>
<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-gost</t> </section>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81YbW/jNhL+zl8xcL8kgOW8bPqyxuGuqZPdDbpJ9uxsF72i
ONDUWOKZIlUOZVcI/N+LIWVbzubSl/tynyxT5GieZx7ODJllmQg6GBzD4Apr
j0oGhIZkgeAWcD2ZZG/vZw+w1qHUFq7uZrPryUDI+dzjagy3H2cPcHf/0L2I
03aLRO6UlRWOIfdyETKNYZHlllydVQ2FzLqQoVJZ4Shkp18L/nThfDsGCrnQ
tR9D8A2F89PT16fngoJHWY3h5vrhjRCCgrT5v6VxFsfQIolaj+Gn4NQQyPng
cUFDoLZKD7lTlaxrbYufhZBNKJ0fC4BMAABoS2P4NIJ30udyiT4OJs8/IR0O
O1+M4eNscnIzu4kDWEltxsDgvi27mTSyGD4z/31TSa/7xqX3aPvj0fpb5wqD
fePrOPHbZZwYbQvrfCWDXiHDmL6ZnJ+dve4ev3z96lX3+PrVVxdjIYDj8/31
j9nN5d3lOFrec7D3h9/GgSB9gWEMgzKEmsYnJ+v1eqSllSPnixNJpAtboQ10
klvKCFUmTZHZppqjf3Zs9GsZKjNIxpPcrlwltYU7WSHMWgpYwQxV43Vo4SjJ
6RguTeG8DmUFd8kQQ5n9JRgvoqDM+yy0NdKhj2iwkEE7CzNdWPRwdDU7himS
a7xCmKJyPoej6fQYHtoa4UoXSGHvNjH3n6nfL9Q3X51fZHNNByjgAMZWdkP4
NDp4kfSyG96i3MYql0EGL9US/Yg/GtHmTp1wCE5ecuYA+t1sH4/nwgAghLaL
JzJ8/eWX34yFEFmWgZwT+xGEeCg18RZsmG7wGLRHglBypol5JuaYKby6GJ2d
Zuenp2dwVFmsnNVKDLb5ZHB8mIZGQnRqhyPr1lBqCs5rdQw5LrTF/OUvSJv3
R8+y1xdC7gKXUtkBC9e/BrSknaWdQEdwCK2pcxmQtrtQzFvIu6yqbdH3Zwtq
lLiqdJ4bFOILuLHBu7xRrDpmbreCF/8hFPAEheCVv4cEfurSxc+wlntEmIO2
4vGxA7TZMGIkhLB2B99BjzuomMO8jf7e+xw9dd6LN5ijlwYuC7SqhYXz8ICq
tFpJA1MsGpP2GmO6xeCdcUXLi6cNkZbiaOoopn3pwzFoC5dN0VCA89Oz82Fc
Fd2gpkZPmCc3Ijlbws7OxY6wRBePgUeqUbGMTRsB9jgnBItr9Iy4r4+dDEE/
oQsiXbwTNpvoVShRe5BETmlmR3j8pdEeo2QMrtAQSI9gXQBVSltsCexZHrEW
Ghr+wV0T32XXk8nxszrXBNaBcbZADx6Vqyq0TBjHhK3v0SUwr7662GxGQogv
voDp3ns2E2SSKkBkboktrJ3PCQbcHQyG6Ze7BH6eXv/z4830+oqfZ+8u37/f
PaQZbGYwe3f/8X03hZ/2iyf3t7fXd1dpPTceT4ZuL39MNhj14P7Dw8393eX7
AeM5oDPyHRzMGWpAX3vk4LHykZTXc8xFLN3w3eQDnF0kGrjIbjbw+PiP6ZvJ
N2dfX2w2sC7RJvE5a9rubyixBVnXKH1nRhoDStY6SEND/g6Vbm2hRI8j3vZX
vTSx67qek1vKCU+3fG+H7lft27N51EwevRPKY/rO1SzG3uc0AvhBGp2ncY/k
zIo3bjTAfVf4TEL7xYxGW+LkgiOAmwVry4USfe8LrFepFNasf+XbOrjCy7rU
qo+SoyJXUhs5N5i0zolra2OOxq1jKsn3lbl22obk6RyTsymSO58SZTtW/wRX
sOVKpAYqxnk6nd28/ePMiYP5ySLvNO+qri3bvWuoqxKEB6wQSCsaS01dOx/R
bV+ODug+/FKPcThgXLzM+OpzPAmOcpZ0zqmwRLFPZ3FW7IeeEwSLe1d4Jp2F
GDl62hjULqANWhrTgrZMFHVtAm0NdHWwy02oHKXWcd6KfqHtAQylDF12fSHh
RTfv684zaX7HU4+VWyFBF5FoZVfR4V/OIrhozHkC1XD3HkwLlVyydw2h6B+u
5pL6MY25oTE50FoHVXKaeorHY2yed4IYibRNCk3Ba9xZqL0r9VyHrgQpo2PS
jtprauNkHtmyOdTN3GgqWepP/Ort4eAALTWcOtmLlOU8drrttwOlViW/EnvN
zttt2DqBOU8pcZIDJS1vvMMJjIs7osu7y8/i8dOdCzGD89thl8pTWHbdx/TN
BK5zHbi15v8dPy0sNJqchNEUN9PcrRDW2hi2sd2f3Lq90CuPfhYiOqYJuJxj
NBUcEEZiYPCRMOqiw8QHCG0LLlKHb8Q2fzjLL2+q2qTO4NnFsa49N6dvBpQz
TWWpt11eaOZ3vIjHx945MRa6lyjYbA50D0dn58cggtul0hFAihKLpfa40q4h
04qX6PnvAHunsYHYAowNnzQeZd7uv/snQ9Mz/Jeic7D+LwVo8NnBcbBX6+Nj
d+TdbASbe1r7j14dw/8H63ySmUu15F17qZbWrQ3mRWwUUw1OB13i1shjrB4R
fkrHgVI2aArmIp5OYqLiGQtnjFtzlonXP7X0QStdS16kuY0yfLfD+S5vFB72
emO4lX4Jlzb3uKYhzAKuECbe8RF5KL7zWlq40mpJzg7hoXSVJHjr5WIYDx7w
zjWEph3CrGwqZ+Fd80uDQ/ggGwPv3GJRSTuEGdw6Z5Fk1Q7hAwb0Ymcy/u0M
E7eHs4ALaeHjfK7tsrP0yTUBOSM+6Ao+aaUtLfUQtgcIUUnbQoVpx+739f0H
7rZjWSm8a+oU9lyTaojiEZiZ4F0cc+kk1aJe35Pu+tIpJAWpCzwpaW1H6n9Q
Bc6IP+hlYGk0y9KtrI7OHVyRlboojS7KkOp2V/r4ZGhcG6XlFrCSnjXZLxjO
RpDbOwwKMtAot8T3SME5Q/EWA9Y4Jx24Wv+tn9xrw60CcFMYuuATxhM0NDW3
iFzcVBTx35mFtzqUzRx+QM+H4MRmTzBCfCq1eaIiziaN5e4nZ65czYND0GFb
u1Ya15gPId295EOx4IrCDf5Y7IAV8csj5aqT7WVhdyWz/fv0hpRvR/8XuL8B
elkXheIVAAA=
</rfc> </rfc>
 End of changes. 19 change blocks. 
346 lines changed or deleted 475 lines changed or added

This html diff was produced by rfcdiff 1.48.