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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.
4.2) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc docmapping="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-dnsop-must-not-ecc-gost-07" number="9906" updates="" obsoletes="" xml:lang ="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" so rtRefs="true" symRefs="true" version="3">
<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 thin DNSSEC</title>
<!--[rfced] We have updated the short title that spans the header of
the PDF file to more closely match the title. Please let us know
of any objection.
Original:
MUST NOT DNSSEC with ECC-GOST
Current:
Deprecate Usage of ECC-GOST
-->
<title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate Usage of ECC-GOST wi
thin DNSSEC</title>
<seriesInfo name="RFC" value="9906"/>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker"> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/ISI</organization> <organization>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>Google</organization>
<address> <address>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<date year="2025" month="November"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<date year="2025" month="June" day="03"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<abstract> <abstract>
<?line 53?> <!--[rfced] This document discusses no longer using the GOST R 34.10-2001
and GOST R 34.11-94 algorithms but only "GOST R 34.10-2001" is
mentioned in the first sentence of the Abstract. Is that
intended, or should GOST R 34.11-94 also be included?
<t>This document retires the use of GOST R 34.10-2001 (mnemonic Original:
"ECC-GOST") within DNSSEC.</t> This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-
GOST") within DNSSEC.
<t>RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11- Perhaps:
94 This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-
algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933 GOST") and GOST R 34.11-94 within DNSSEC.
by deprecating the use of ECC-GOST.</t> -->
</abstract> <t>This document retires the use of GOST R 34.10-2001 (mnemonic
"ECC-GOST") within DNSSEC.</t>
<t>RFC 5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R
34.11-94
algorithms with DNS Security Extensions (DNSSEC).
</front> <!--[rfced] We note that this document does not "update" RFC 5933 but
rather moves it to Historic status. For clarity, may we update
the Abstract to reflect this as shown below?
Current:
RFC 5933 (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 RFC 5933 by deprecating the use of ECC-GOST.
Perhaps:
RFC 5933 defined the use of the GOST R 34.10-2001 and GOST R 34.11-94
algorithms with DNS Security Extensions (DNSSEC). This document
moves RFC 5933 to Historic status by deprecating the use of ECC-GOST.
-->
This document updates RFC 5933
by deprecating the use of ECC-GOST.</t>
</abstract>
</front>
<middle> <middle>
<?line 62?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <!--[rfced] This sentence reads oddly as it sounds like the DNS
Security Extensions were documented in RFC 5933 yet there is a
reference to RFC 9364. For clarity, may we rephrase this as shown
below?
<t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with Original:
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"></xref> was document The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with
ed in the DNS Security Extensions (DNSSEC) [RFC9364] was documented in
[RFC5933].
Perhaps:
The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are
documented in [RFC5933] and their use with DNS Security
Extensions (DNSSEC) is further described in [RFC9364].
-->
<t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"/> was documented in
<xref target="RFC5933"/>. These two algorithms were deprecated by the Orders of the <xref target="RFC5933"/>. These two algorithms were deprecated by the Orders of 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"/>, and their associ
ted ated
requirement levels are not changed by this document.</t> requirement levels are not changed by this document.</t>
<t>Thus, the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.
<t>Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and GOST R 34.11-94 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"/>.</t>
<section anchor="requirements-notation">
<name>Requirements Notation</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec">
<name>Deprecating ECC-GOST Algorithms in DNSSEC</name>
<t>The GOST R 34.11-94 algorithm <xref target="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
cryptographic algorithms are available, the DNS records below the
delegation point <bcp14>MUST</bcp14> be treated as insecure.</t>
<section anchor="requirements-notation"><name>Requirements notation</name> <!--[rfced] Would it be clearer to include the descriptive name "GOST
R 34.10-2001" (instead of the mnemonic "ECC-GOST") here for clarity?
We ask because "GOST R 34.11-94" was used in the previous paragraph.
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Also, we updated "these algorithms" to "this algorithm" as we assume
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", it is referring to the ECC-GOST algorithm.
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh
en, they appear
in all capitals, as shown here.</t>
</section> Original:
</section> The ECC-GOST [RFC5933] algorithm MUST NOT be used when creating
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec"><name>Deprecating EC DNSKEY and RRSIG records. Validating resolvers MUST treat RRSIG
C-GOST algorithms in DNSSEC</name> records created from DNSKEY records using these algorithms as an
unsupported algorithm.
<t>The GOST R 34.11-94 <xref target="RFC5933"/> algorithm MUST NOT be used when Perhaps:
creating DS records. Validating resolvers MUST treat GOST R 34.11-94 The GOST R 34.10-2001 algorithm [RFC5933] MUST NOT be used when creating
DS records as insecure. If no other DS records of accepted DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.
cryptographic algorithms are available, the DNS records below the Validating resolvers MUST treat RRSIG records created from DNSKEY
delegation point MUST be treated as insecure.</t> records using this algorithm as an unsupported algorithm.
-->
<t>The ECC-GOST <xref target="RFC5933"/> algorithm MUST NOT be used when creatin <t>The ECC-GOST algorithm <xref target="RFC5933"/> <bcp14>MUST NOT</bcp14> be us
g ed when creating
DNSKEY and RRSIG records. Validating resolvers MUST treat DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. Validati
RRSIG records created from DNSKEY records using these algorithms as an ng resolvers <bcp14>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 anchor="security-considerations">
<name>Security Considerations</name>
<t>This document potentially increases the security of the DNSSEC ecosyste
m by
deprecating algorithms that are no longer recommended for use.</t>
</section>
<section anchor="operational-considerations">
<name>Operational Considerations</name>
<t>This document removes support for ECC-GOST. Zone operators currently ma
king use
of ECC-GOST-based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing
ECC-GOST-based DS records to ensure that they are using algorithms that are
supported by DNSSEC validators and thus can be DNSSEC validated.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
</section> <!--[rfced] Section 5. For clarity, may we update this text to reflect
<section anchor="security-considerations"><name>Security Considerations</name> all of IANA's updates? Also, should "DEPRECATED" be added to the
Description column for "GOST R 34.11-94" (to match the entry for
"GOST R 34.10-2001 (DEPRECATED)") as shown below?
<t>This document potentially increases the security of the DNSSEC ecosystem by Current:
deprecating algorithms that are no longer recommended for use.</t> IANA has set the "Use for DNSSEC Signing", "Use for DNSSEC
Validation", "Implement for DNSSEC Signing", and "Implement for
DNSSEC Validation" columns in the "DNS Security Algorithm Numbers"
registry [DNSKEY-IANA] [RFC9904] to MUST NOT for ECC-GOST (12). Note
that the "Use for DNSSEC Signing" and "Implement for DNSSEC
Delegation" columns were already set to MUST NOT.
</section> IANA has set the "Use for DNSSEC Delegation", "Use for DNSSEC
<section anchor="operational-considerations"><name>Operational Considerations</n Validation", "Implement for DNSSEC Delegation", and "Implement for
ame> DNSSEC Validation" columns in the "Digest Algorithms" registry
[DS-IANA] to MUST NOT for GOST R 34.11-94 (3). Note that the "Use
for DNSSEC Signing" and "Implement for DNSSEC Delegation" columns
were already set to MUST NOT.
<t>This document removes support for ECC-GOST. Zone operators currently making u Perhaps:
se IANA has updated the GOST R 34.10-2001 (12) entry in the "DNS
of ECC-GOST based algorithms should switch to algorithms that remain supported. Security Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] as
DNS registries should prohibit their clients from uploading and publishing follows:
ECC-GOST based DS records to ensure that they are using algorithms which are
supported by DNSSEC validators, and so can be DNSSEC validated.</t>
</section> Number: 12
<section anchor="iana-considerations"><name>IANA Considerations</name> 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], [Change the status of GOST Signature
Algorithms in DNSSEC in the IETF stream to Historic], and RFC 9906
<t>[Note to IANA, to be removed by the RFC Editor: the registry fields Note that the "Use for DNSSEC Signing" and "Implement for DNSSEC
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t> Delegation" columns were already set to MUST NOT.
<t>IANA is requested to set the "Use for DNSSEC Signing", "Use for DNSSEC IANA has updated the GOST R 34.11-94 (3) entry in the "Digest Algorithms"
registry [DS-IANA] [RFC9904] as follows:
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], and RFC 9906
Note that the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already set to MUST NOT.
-->
<t>IANA has set the "Use for DNSSEC Signing", "Use for DNSSEC
Validation", "Implement for DNSSEC Signing", and "Implement for DNSSEC Validation", "Implement for DNSSEC Signing", and "Implement for DNSSEC
Validation" columns of the DNS Security Algorithm Numbers registry Validation" columns in the "DNS Security Algorithm Numbers" registry
<xref target="DNSKEY-IANA"/> <xref target="draft-ietf-dnsop-rfc8624-bis"/> for E <xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> to <bcp14>MUST NOT</bcp14>
CC-GOST (12) for ECC-GOST (12). Note that
to MUST NOT. Note that previously
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already MUST NOT.</t> columns were already set to <bcp14>MUST NOT</bcp14>.</t>
<t>IANA has set the "Use for DNSSEC Delegation", "Use for DNSSEC
<t>IANA is requested to set the "Use for DNSSEC Delegation", "Use for DNSSEC
Validation", "Implement for DNSSEC Delegation", and "Implement for DNSSEC Validation", "Implement for DNSSEC Delegation", and "Implement for DNSSEC
Validation" columns of the "Digest Algorithms" registry <xref target="DS-IANA"/> Validation" columns in the "Digest Algorithms" registry <xref target="DS-IANA"/>
for GOST R 34.11-94 (3) to MUST NOT. Note that previously to <bcp14>MUST NOT</bcp14> for GOST R 34.11-94 (3). Note that
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already MUST NOT.</t> columns were already set to <bcp14>MUST NOT</bcp14>.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references">
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
933.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
364.xml"/>
<references title='References' anchor="sec-combined-references"> <!-- [rfced] FYI: We updated the reference entries for the IANA
registries to reflect the names of the registries rather than the
<references title='Normative References' anchor="sec-normative-references"> registry group names to match the running text. Please let us
know of any objection.
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the
requirements in the specification. These words are often capitalized. This docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5933">
<front>
<title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC</title>
<author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov
"/>
<author fullname="A. Chuprina" initials="A." surname="Chuprina"/>
<author fullname="I. Ustinov" initials="I." surname="Ustinov"/>
<date month="July" year="2010"/>
<abstract>
<t>This document describes how to produce digital signatures and hash func
tions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRS
IG, and DS resource records, for use in the Domain Name System Security Extensio
ns (DNSSEC).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5933"/>
<seriesInfo name="DOI" value="10.17487/RFC5933"/>
</reference>
<reference anchor="RFC9364">
<front>
<title>DNS Security Extensions (DNSSEC)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2023"/>
<abstract>
<t>This document describes the DNS Security Extensions (commonly called "D
NSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of
others. One purpose is to introduce all of the RFCs in one place so that the re
ader can understand the many aspects of DNSSEC. This document does not update an
y of those RFCs. A second purpose is to state that using DNSSEC for origin authe
ntication of DNS data is the best current practice. A third purpose is to provid
e a single reference for other documents that want to refer to DNSSEC.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
<reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec Current:
-alg-numbers/dns-sec-alg-numbers.xhtml"> [DNSKEY-IANA]
<front> IANA, "DNS Security Algorithm Numbers",
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title> <https://www.iana.org/assignments/dns-sec-alg-numbers>.
<author initials="" surname="IANA" fullname="IANA">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types"
>
<front>
<title>Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</t
itle>
<author initials="" surname="IANA" fullname="IANA">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="draft-ietf-dnsop-rfc8624-bis" target="https://datatracker.iet
f.org/doc/html/draft-ietf-dnsop-rfc8624-bis">
<front>
<title>DNS Security Algorithm Numbers</title>
<author initials="K." surname="W." fullname="Kumari, W.">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
</references> [DS-IANA] IANA, "Digest Algorithms",
<http://www.iana.org/assignments/ds-rr-types>.
-->
<references title='Informative References' anchor="sec-informative-reference <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments
s"> /dns-sec-alg-numbers">
<front>
<title>DNS Security Algorithm Numbers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-r
r-types">
<front>
<title>Digest Algorithms</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="RFC9558"> <!--
<front> draft-ietf-dnsop-rfc8624-bis-13
<title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Re companion doc RFC 9904
cords for DNSSEC</title> AUTH48 as of 10/30/25
<author fullname="B. Makarenko" initials="B." surname="Makarenko"/> -->
<author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov <reference anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9
"/> 904">
<date month="April" year="2024"/> <front>
<abstract> <title>DNSSEC Cryptographic Algorithm Recommendation Update Process<
<t>This document describes how to produce digital signatures and hash func /title>
tions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, R <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
RSIG, and DS resource records, for use in the Domain Name System Security Extens <organization>USC/ISI</organization>
ions (DNSSEC).</t> </author>
</abstract> <author initials="W." surname="Kumari" fullname="Warren Kumari">
</front> <organization>Google</organization>
<seriesInfo name="RFC" value="9558"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC9558"/> <date month='November' year='2025'/>
</reference> </front>
<reference anchor="RFC8174"> <seriesInfo name="RFC" value="9904"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC9904"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> </reference>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
558.xml"/>
</references>
</references> </references>
</references> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<?line 135?>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>The authors appreciate the comments and suggestions from the following IETF
participants in helping produce this document: Mark Andrews, Steve Crocker,
Brian Dickson, Thomas Graf, Russ Housely, Shumon Huque, Paul Hoffman, S Moonesam
y, Peter
Dickson, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the
many members of the DNSOP working group that discussed this draft.</t>
</section>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage l
evels</name>
<t>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.</t>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t> <!--[rfced] Since most of the names in the Acknowledgments were in
alphabetical order, we reordered a few names so that the full
list is now in alphabetical order. If this is not desired,
please let us know.
</section> Original:
<section anchor="github-version-of-this-document"><name>Github Version of this d The authors appreciate the comments and suggestions from the
ocument</name> following IETF participants in helping produce this document: Mark
Andrews, Steve Crocker, Brian Dickson, Thomas Graf, Russ Housely,
Shumon Huque, Paul Hoffman, S Moonesamy, Peter Dickson, Peter
Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the many
members of the DNSOP working group that discussed this draft.
<t>While this document is under development, it can be viewed, tracked, Current:
fill here:</t> The authors appreciate the comments and suggestions from the
following IETF participants in helping produce this document: Mark
Andrews, Steve Crocker, Brian Dickson, Peter Dickson, Thomas Graf,
Paul Hoffman, Russ Housely, Shumon Huque, S. Moonesamy, Peter
Thomassen, Stefan Ubbink, Tim Wicinski, Paul Wouters, and the many
members of the DNSOP Working Group that discussed this
specification.
-->
<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-gost</t> <t>The authors appreciate the comments and suggestions from the
following IETF participants in helping produce this document: <contact
fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
fullname="Brian Dickson"/>, <contact fullname="Peter Dickson"/>, <contact
fullname="Thomas Graf"/>, <contact fullname="Paul Hoffman"/>, <contact
fullname="Russ Housely"/>, <contact fullname="Shumon Huque"/>, <contact fu
llname="S. Moonesamy"/>, <contact fullname="Peter Thomassen"/>,
<contact fullname="Stefan Ubbink"/>,
<contact fullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, an
d the many members of the DNSOP
Working Group that discussed this specification.</t>
</section>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t> </back>
</section> <!-- [rfced] FYI - To match the companion documents, we have added
expansions for the following abbreviations per Section 3.6 of RFC
7322 ("RFC Style Guide"). Please review these and each expansion
in the document carefully to ensure correctness.
</back> DNS Public Key (DNSKEY)
Delegation Signer (DS)
Resource Record Signature (RRSIG)
-->
<!-- ##markdown-source: <!-- [rfced] Please review the "Inclusive Language" portion of the online
H4sIAAAAAAAAA81YbW/jNhL+zl8xcL8kgOW8bPqyxuGuqZPdDbpJ9uxsF72i Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
ONDUWOKZIlUOZVcI/N+LIWVbzubSl/tynyxT5GieZx7ODJllmQg6GBzD4Apr and let us know if any changes are needed. Updates of this nature typically
j0oGhIZkgeAWcD2ZZG/vZw+w1qHUFq7uZrPryUDI+dzjagy3H2cPcHf/0L2I result in more precise language, which is helpful for readers.
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=
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 57 change blocks. 
293 lines changed or deleted 326 lines changed or added

This html diff was produced by rfcdiff 1.48.