rfc9905xml2.original.xml   rfc9905.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.5) -->
<!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-sha1-10" number="9905" category="std" consensus="true" subm issionType="IETF" updates="4034, 5155" obsoletes="" xml:lang="en" tocInclude="tr ue" sortRefs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-dnsop-must-not-sha1-10" category="std " consensus="true" submissionType="IETF" updates="4034, 5155" tocInclude="true" sortRefs="true" symRefs="true">
<front> <front>
<title abbrev="MUST NOT DNSSEC with SHA-1">Deprecating the use of SHA-1 in D NSSEC signature algorithms</title>
<!--[rfced] We have updated the short title that spans the header of
the PDF file to more closely match the document title. Please let
us know of any objection.
Original:
MUST NOT DNSSEC with SHA-1
Current:
Deprecating SHA-1 in DNSSEC Signature Algorithms
-->
<title abbrev="Deprecating SHA-1 in DNSSEC Signature Algorithms">Deprecating
the Use of SHA-1 in DNSSEC Signature Algorithms</title>
<seriesInfo name="RFC" value="9905"/>
<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="October"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<date year="2025" month="September" day="10"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
<abstract> -->
<?line 48?>
<abstract>
<t>This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 <t>This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1
algorithms for the creation of DNS Public Key (DNSKEY) and Resource algorithms for the creation of DNS Public Key (DNSKEY) and Resource
Record Signature (RRSIG) records.</t> Record Signature (RRSIG) records.</t>
<t>It updates RFCs 4034 and 5155 as it deprecates the use of these algorit
<t>It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms.< hms.</t>
/t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 56?> <section anchor="introduction">
<name>Introduction</name>
<t>The security of the protection provided by the SHA-1 algorithm <xref ta
rget="RFC3174"/> has been slowly diminishing
over time as various forms of attacks have weakened its cryptographic
underpinning. DNSSEC <xref target="RFC9364"/> (originally defined in <xref targ
et="RFC3110"/>) made extensive use
of SHA-1, for example, as a
cryptographic hash algorithm in Resource Record Signature (RRSIG) and Delegation
Signer (DS)
records.
<section anchor="introduction"><name>Introduction</name> <!--[rfced] FYI: The acronyms appear to be mismatched with the
expansions, so we switched them accordingly as shown below.
<t>The security of the protection provided by the SHA-1 algorithm <xref target=" Original:
RFC3174"/> has been slowly diminishing Since then, multiple other algorithms with stronger cryptographic
over time as various forms of attacks have weakened its cryptographic strength have become widely available for DS records and for
underpinning. DNSSEC <xref target="RFC9364"/> originally <xref target="RFC3110" Resource Record Signature (DNSKEY) and DNS Public Key (RRSIG)
/> made extensive use records [RFC4034].
of SHA-1, for example as a
cryptographic hash algorithm in RRSIG and Delegation Signer (DS) Current:
records. Since then, multiple other algorithms with Since then, multiple other algorithms with stronger cryptographic
strength have become widely available for DS records and for
Resource Record Signature (RRSIG) and DNS Public Key (DNSKEY)
records [RFC4034].
-->
Since then, multiple other algorithms with
stronger cryptographic strength have become widely available for DS records stronger cryptographic strength have become widely available for DS records
and for Resource Record Signature (DNSKEY) and DNS Public Key (RRSIG) records <x and for RRSIG and DNS Public Key (DNSKEY) records <xref target="RFC4034"/>.
ref target="RFC4034"/>.
<!--[rfced] Should the names of the IANA registries be included here
for clarity?
Original:
Operators are encouraged to consider switching to one of the
recommended algorithms listed in the [DNSKEY-IANA] and [DS-IANA]
tables, respectively.
Perhaps:
Operators are encouraged to consider switching to one of the
recommended algorithms listed in the "DNS Security Algorithm
Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA]
registries, respectively.
-->
Operators are encouraged to consider switching to one of the recommended algorit hms Operators are encouraged to consider switching to one of the recommended algorit hms
listed in the <xref target="DNSKEY-IANA"/> and <xref target="DS-IANA"/> tables, respectively. listed in the <xref target="DNSKEY-IANA"/> and <xref target="DS-IANA"/> tables, respectively.
Further, support for validating SHA-1 based signatures has been Further, support for validating SHA-1-based signatures has been
removed from some systems. As a result, SHA-1 as part of a signature algorithm removed from some systems. As a result, SHA-1 as part of a signature algorithm
is no longer fully interoperable is no longer fully interoperable
in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is
no longer advisable.</t> no longer advisable.</t>
<t>This document thus deprecates the use of RSASHA1 and
<t>This document thus further deprecates the use of RSASHA1 and
RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.</t> RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.</t>
<section anchor="requirements-notation">
<section anchor="requirements-notation"><name>Requirements notation</name> <name>Requirements Notation</name>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and "OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
en, they appear "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
in all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section anchor="deprecating-sha-1-from-dnssec-signatures-and-delegation-rrs"><n </section>
ame>Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs</name> </section>
<section anchor="deprecating-sha-1-from-dnssec-signatures-and-delegation-rrs
<t>The RSASHA1 <xref target="RFC4034"></xref> and RSASHA1-NSEC3-SHA1 <xref targe ">
t="RFC5155"></xref> algorithms MUST NOT <name>Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs</name>
be used when creating DS records. Operators of validating resolvers MUST treat <t>The RSASHA1 <xref target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref targe
RSASHA1 and t="RFC5155"/> algorithms <bcp14>MUST NOT</bcp14>
RSASHA1-NSEC3-SHA1 DS records as insecure. If no other DS records of be used when creating DS records. Operators of validating resolvers <bcp14>MUST
</bcp14> treat RSASHA1
and RSASHA1-NSEC3-SHA1 DS records as insecure. If no other DS records of
accepted cryptographic algorithms are available, the DNS records below the accepted 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>The RSASHA1 <xref target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref targe
<t>The RSASHA1 <xref target="RFC4034"></xref> and RSASHA1-NSEC3-SHA1 <xref targe t="RFC5155"/> algorithms <bcp14>MUST NOT</bcp14> be
t="RFC5155"></xref> algorithms MUST NOT be
used when creating DNSKEY and RRSIG records. Validating resolver implementation s used when creating DNSKEY and RRSIG records. Validating resolver implementation s
(<xref target="RFC9499"></xref> section 10) MUST continue to support validation using these (<xref target="RFC9499" sectionFormat="comma" section="10"/>) <bcp14>MUST</bcp14 > continue to support validation using these
algorithms as they are diminishing in use but still actively in use for some algorithms as they are diminishing in use but still actively in use for some
domains as of this publication. Operators of validating resolvers MUST treat domains as of this publication. Operators of validating resolvers <bcp14>MUST</b
DNSSEC signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as cp14> treat DNSSEC signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsuppor
unsupported, rendering responses insecure if they cannot be validated ted, rendering responses insecure if they cannot be validated by other supported
by other supported signing algorithms.</t> signing algorithms.</t></section>
<section anchor="security-considerations">
<name>Security Considerations</name>
</section> <!--[rfced] Is it correct that "DNSSEC Delegation" is uppercase and
<section anchor="security-considerations"><name>Security Considerations</name> "DNSSEC signing" is lowercase in this sentence? In the companion
document (draft-ietf-dnsop-rfc8624-bis-13 / RFC-to-be 9904), we
note that "DNSSEC signers" is used in the running text and that
"DNSSEC Delegation" is uppercase as it's only used in the name of
the columns and IANA registry.
<t>This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for Original:
This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1
for DNSSEC Delegation and DNSSEC signing since these algorithms are
no longer considered to be secure.
-->
<t>This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for
DNSSEC Delegation and DNSSEC signing since these algorithms are no DNSSEC Delegation and DNSSEC signing since these algorithms are no
longer considered to be secure.</t> longer considered to be secure.</t>
</section>
<section anchor="operational-considerations">
<name>Operational Considerations</name>
</section> <!--[rfced] May we refer to the "tables" as "IANA registries" for
<section anchor="operational-considerations"><name>Operational Considerations</n clarity? Also, would "use" be clearer than "roll to"?
ame>
<t>Zone owners currently making use of SHA-1 based algorithms should Original:
immediately roll to algorithms with stronger cryptographic algorithms, Zone owners currently making use of SHA-1 based algorithms should
such as the recommended algorithms in the <xref target="DNSKEY-IANA"></xref> and immediately roll to algorithms with stronger cryptographic
<xref target="DS-IANA"></xref> tables.</t> algorithms, such as the recommended algorithms in the [DNSKEY-IANA]
and [DS-IANA] tables.
<t>Operators should take care when deploying software packages and Perhaps:
Zone owners currently making use of SHA-1-based algorithms should
immediately use algorithms with stronger cryptographic algorithms,
such as the recommended algorithms in the IANA registries
[DNSKEY-IANA] [DS-IANA].
-->
<t>Zone owners currently making use of SHA-1-based algorithms should
immediately roll to algorithms with stronger cryptographic algorithms,
such as the recommended algorithms in the <xref target="DNSKEY-IANA"/> and <xref
target="DS-IANA"/> tables.</t>
<t>Operators should take care when deploying software packages and
operating systems that may have already removed support for the SHA-1 operating systems that may have already removed support for the SHA-1
algorithm. In these situations software may need to be manually built algorithm. In these situations, software may need to be manually built
and deployed by an operator to continue supporting the required levels and deployed by an operator to continue supporting the required levels
indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC
Validation" columns, which this document is not changing.</t> Validation" columns, which this document is not changing.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
</section> <!--[rfced] Per IANA's protocol action note, should the IANA section
<section anchor="iana-considerations"><name>IANA Considerations</name> be updated as follows to capture all of IANA's updates to the
entries?
<t>[Note to IANA, to be removed by the RFC Editor: the registry fields
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t>
<t>IANA is requested to set the "Use for DNSSEC Delegation" field of the
"Digest Algorithms" registry <xref target="DS-IANA"/> <xref target="I-D.ietf-dns
op-rfc8624-bis"/>
for SHA-1 (1) to MUST NOT.</t>
<t>IANA is requested to set the "Use for DNSSEC Signing" column of the
DNS Security Algorithm Numbers registry <xref target="DNSKEY-IANA"/>
<xref target="I-D.ietf-dnsop-rfc8624-bis"/> to MUST NOT
for the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms.</t>
<t>All other columns should remain as currently specified.</t>
</section>
</middle> Current:
IANA has set the "Use for DNSSEC Delegation" column of the "Digest
Algorithms" registry [DS-IANA] [RFC9904] to MUST NOT for SHA-1 (1)
and has added this document as a reference to the entry.
<back> IANA has set the "Use for DNSSEC Signing" column of the "DNS Security
Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] to MUST NOT for
the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms and has added
this document as a reference for these entries.
<references title='Normative References' anchor="sec-normative-references"> All other columns should remain as currently specified.
<reference anchor="RFC2119"> Perhaps:
<front> IANA has updated the SHA-1 (1) entry in the "Digest Algorithms"
<title>Key words for use in RFCs to Indicate Requirement Levels</title> registry [DS-IANA] [RFC9904] as follows and has added this document
<author fullname="S. Bradner" initials="S." surname="Bradner"/> as a reference for the entry:
<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="RFC3110">
<front>
<title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
<date month="May" year="2001"/>
<abstract>
<t>This document describes how to produce RSA/SHA1 SIG resource records (R
Rs) in Section 3 and, so as to completely replace RFC 2537, describes how to pro
duce RSA KEY RRs in Section 2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3110"/>
<seriesInfo name="DOI" value="10.17487/RFC3110"/>
</reference>
<reference anchor="RFC3174">
<front>
<title>US Secure Hash Algorithm 1 (SHA1)</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
<author fullname="P. Jones" initials="P." surname="Jones"/>
<date month="September" year="2001"/>
<abstract>
<t>The purpose of this document is to make the SHA-1 (Secure Hash Algorith
m 1) hash algorithm conveniently available to the Internet community. This memo
provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3174"/>
<seriesInfo name="DOI" value="10.17487/RFC3174"/>
</reference>
<reference anchor="RFC4034">
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author fullname="R. Arends" initials="R." surname="Arends"/>
<author fullname="R. Austein" initials="R." surname="Austein"/>
<author fullname="M. Larson" initials="M." surname="Larson"/>
<author fullname="D. Massey" initials="D." surname="Massey"/>
<author fullname="S. Rose" initials="S." surname="Rose"/>
<date month="March" year="2005"/>
<abstract>
<t>This document is part of a family of documents that describe the DNS Se
curity Extensions (DNSSEC). The DNS Security Extensions are a collection of reso
urce records and protocol modifications that provide source authentication for t
he DNS. This document defines the public key (DNSKEY), delegation signer (DS), r
esource record digital signature (RRSIG), and authenticated denial of existence
(NSEC) resource records. The purpose and format of each resource record is descr
ibed in detail, and an example of each resource record is given.</t>
<t>This document obsoletes RFC 2535 and incorporates changes from all upda
tes to RFC 2535. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4034"/>
<seriesInfo name="DOI" value="10.17487/RFC4034"/>
</reference>
<reference anchor="RFC5155">
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title
>
<author fullname="B. Laurie" initials="B." surname="Laurie"/>
<author fullname="G. Sisson" initials="G." surname="Sisson"/>
<author fullname="R. Arends" initials="R." surname="Arends"/>
<author fullname="D. Blacka" initials="D." surname="Blacka"/>
<date month="March" year="2008"/>
<abstract>
<t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC
resource record (RR) for authenticated denial of existence. This document intro
duces an alternative resource record, NSEC3, which similarly provides authentica
ted denial of existence. However, it also provides measures against zone enumera
tion and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5155"/>
<seriesInfo name="DOI" value="10.17487/RFC5155"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<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>
<reference anchor="RFC9499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="March" year="2024"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of differen
t RFCs. The terminology used by implementers and developers of DNS protocols, an
d by operators of DNS systems, has changed in the decades since the DNS was firs
t defined. This document gives current definitions for many of the terms used in
the DNS in a single document.</t>
<t>This document updates RFC 2308 by clarifying the definitions of "forwar
der" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarificati
ons. Comprehensive lists of changed and new definitions can be found in Appendic
es A and B.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="9499"/>
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
</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 Value: 1
-alg-numbers/dns-sec-alg-numbers.xhtml"> Description: SHA-1
<front> Use for DNSSEC Delegation: MUST NOT
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title> Use for DNSSEC Validation: RECOMMENDED
<author initials="" surname="IANA" fullname="IANA"> Implement for DNSSEC Delegation: MUST NOT
<organization></organization> Implement for DNSSEC Validation: MUST
</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="I-D.ietf-dnsop-rfc8624-bis"> IANA has updated the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7)
<front> algorithm entries in the "DNS Security Algorithm Numbers" registry
<title>DNSSEC Cryptographic Algorithm Recommendation Update Process</title [DNSKEY-IANA] [RFC9904] as follows and has added this document as a
> reference for these entries:
<author fullname="Wes Hardaker" initials="W." surname="Hardaker">
<organization>USC/ISI</organization>
</author>
<author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization>
</author>
<date day="4" month="June" year="2025"/>
<abstract>
<t> The DNSSEC protocol makes use of various cryptographic algorithms
to
provide authentication of DNS data and proof of non-existence. To
ensure interoperability between DNS resolvers and DNS authoritative
servers, it is necessary to specify both a set of algorithm
implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This
document replaces and obsoletes RFC8624 and moves the canonical
source of algorithm implementation requirements and usage guidance
for DNSSEC from RFC8624 to an IANA registry. This is done both to
allow the list of requirements to be more easily updated, and to
allow the list to be more easily referenced. Future extensions to
this registry can be made under new, incremental update RFCs. This
document also incorporates the revised IANA DNSSEC considerations
from RFC9157.
The document does not change the status (MUST, MAY, RECOMMENDED, Number: 5
etc.) of the algorithms listed in RFC8624; that is the work of future Description: RSA/SHA-1
documents. Mnemonic: RSASHA1
Zone Signing: Y
Trans. Sec.: Y
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: RECOMMENDED
Implement for DNSSEC Signing: NOT RECOMMENDED
Implement for DNSSEC Validation: MUST
</t> Number: 7
</abstract> Description: RSASHA1-NSEC3-SHA1
</front> Mnemonic: RSASHA1-NSEC3-SHA1
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc8624-bis-13"/> Zone Signing: Y
Trans. Sec.: Y
Use for DNSSEC Signing: MUST NOT
Use for DNSSEC Validation: RECOMMENDED
Implement for DNSSEC Signing: NOT RECOMMENDED
Implement for DNSSEC Validation: MUST
-->
</reference> <t>IANA has set the "Use for DNSSEC Delegation" column of the
"Digest Algorithms" registry <xref target="DS-IANA"/> <xref target="RFC9904"/>
to <bcp14>MUST NOT</bcp14> for SHA-1 (1) and has added this document as a
reference for the entry.</t>
<t>IANA has set the "Use for DNSSEC Signing" column of the
"DNS Security Algorithm Numbers" registry <xref target="DNSKEY-IANA"/> <xref tar
get="RFC9904"/> to <bcp14>MUST NOT</bcp14>
for the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms and has added this doc
ument as a reference for these entries.</t>
<t>All other columns should remain as currently specified.</t>
</section>
</middle>
<back>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.311
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.317
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.403
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.515
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.949
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.936
4.xml"/>
<reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/d
ns-sec-alg-numbers">
<front>
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title>
<author initials="" surname="IANA" fullname="IANA">
<organization/>
</author>
</front>
</reference>
<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-
types">
<front>
<title>DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest
Algorithms</title>
<author initials="" surname="IANA" fullname="IANA">
<organization/>
</author>
</front>
</reference>
<!--
draft-ietf-dnsop-rfc8624-bis-13
companion doc RFC 9904
in AUTH48 as of 10/30/25
-->
<reference anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc990
4">
<front>
<title>DNSSEC Cryptographic Algorithm Recommendation Update Process</t
itle>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/ISI</organization>
</author>
<author initials="W." surname="Kumari" fullname="Warren Kumari">
<organization>Google</organization>
</author>
<date month='October' year='2025'/>
</front>
<seriesInfo name="RFC" value="9904"/>
<seriesInfo name="DOI" value="10.17487/RFC9904"/>
</reference>
</references> </references>
<?line 140?> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<section anchor="acknowledgments"><name>Acknowledgments</name> <t>The authors appreciate the comments and suggestions from the
following IETF participants in helping produce this document: <contact
<t>The authors appreciate the comments and suggestions from the following fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
IETF participants in helping produce this document: Mark Andrews, fullname="Peter Dickson"/>, <contact fullname="Thomas Graf"/>, <contact
Steve Crocker, Peter Dickson, Thomas Graf, Paul Hoffman, Russ Housley, Shumon fullname="Paul Hoffman"/>, <contact fullname="Russ Housley"/>, <contact
Huque, Barry Leiba, S Moonesamy, Yoav Nir, Florian Obser, Peter fullname="Shumon Huque"/>, <contact fullname="Barry Leiba"/>, <contact
Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the many fullname="S. Moonesamy"/>, <contact fullname="Yoav Nir"/>, <contact
members of the DNSOP working group that discussed this draft.</t> fullname="Florian Obser"/>, <contact fullname="Peter Thomassen"/>,
<contact fullname="Stefan Ubbink"/>, <contact fullname="Paul Wouters"/>,
</section> <contact fullname="Tim Wicinski"/>, and the many members of the DNSOP
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage l Working Group that discussed this specification.</t>
evels</name> </section>
<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>
</section>
<section anchor="github-version-of-this-document"><name>Github Version of this d
ocument</name>
<t>While this document is under development, it can be viewed, tracked,
fill here:</t>
<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-sha1</t>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t>
</section>
</back> <!-- [rfced] Because this document updates RFCs 4034 and 5155, please
review the errata reported for each
(<https://www.rfc-editor.org/errata/rfc4034> and
<https://www.rfc-editor.org/errata/rfc5155>) and let us know if
you confirm our opinion that none of them are relevant to the
content of this document.
-->
<!-- ##markdown-source: <!-- [rfced] Please review the "Inclusive Language" portion of the online
H4sIAAAAAAAAA61YbW/bOBL+zl8xl35JANtN+rK7NQ6H9SZpE7RNelbaolcU Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
B0oaSzxTpMqh7BqB//thSMpWmnT39u4+haFocl6eeeYhx+Ox8MprnMLBGbYO and let us know if any changes are needed. Updates of this nature typically
C+mVqcDXCB0h2AVkF7PxCSgDZ1dZdn4KpCojfecQpK6sU75u6EDIPHe4msLb result in more precise language, which is helpful for readers.
99kNXF3f9KvXytdxC1HawsgGp1A6ufBjhX4xLg3Zdtx05MfG+jHV8mR8ciwK
6bGybjMF8qVQrZuCdx35J8fHL46fCPIOZTOFy/Obl6JrS+mRpvDs+OmzETw/
ef5cCPLSlP+U2hqcwgZJtGoKn70tRkDWeYcLGgFtmjgobdHItlWm+iKE7Hxt
3VQAjAUAgDI0hY8TuJCulEt0YTI68hHp7rR11RTeZ6ePL7PLMIGNVHoK7Ouv
dVpJE4P+3vavu0Y6NdxcOodmOB92f2VtpXG4+Tos/HUZFoa9hbGukV6tkN2Y
vzx9cnLyIg2fnpwc74Y/P0tDjl0acgDT8Jf9ghfPXvQ7vHj6U5g9u8pen38a
X86uZtNgzz5yey/4a5jw0lXop3BQe9/S9PHj9Xo9UdLIiXXVY0kMqwaNp8el
oTFhMZa6GpuuydE9ODf5VvtGH8TNI4TPbCOVgSvZIGQb8thAhkXnlN/AYQTk
Ecx61MJV3Ihdyf4rN37XCxo7N/abFumujaixkl5ZA5mqDDo4PMuOYI5kO1cg
zLGwroTD+fwIbjYtwpmqkPzebBJCmcU+wUKMx2OQOXknCy/ETa2IEd2xHVCm
okYa1jQP59ksu5idgDRlPx5fZeenT8c8FPvihoV14ReFw2i4XXDy4V2Xa1XA
a4zRfX3+6SjulnwRyZdsxxiH83l2+eoIXPhAEyEuPaQC7mEYt4g4BEmgfscJ
GpLQJEaiUWWpUYhHcGm8s2VXsM0cFwTq0ZBi0DrrMXzn4UqVWEK+CZ8i7e12
h9vbVDHbLdSSIEc0QNqu9QZK1SijqFamEnaFDrxqkG1fSadsFyLYEB8qvZfF
kqCWK4Q1yiUaLEF5gsJtWm8rJ9taFaIzJbpWGaNMNYGeTIMNXH7bLVinKmWk
1pvetJPj7RYaWSLgN4+G1CqESvQcPgqJxG+yaXWwToo7h7Jb9cBjZSCkKyTk
YdiKPpEAmTIFcuTMCJpOe8WHWF+jG6QotAOmb2sqdHd9BmZ1U/k6BifHwjYI
a1Wi3oBcSaVlrjH4cJb1CALBxvHc9wU0AN0Qm9/j9i4gYygZhdvtBMR1i056
6wikQ0BT2M7JCkvwFgprSJXogNbKF3Vomhas2dUXb9k0aBhTgwgIrchzzk1Y
dXs7oNHtNth4e5v4aLsFz07TCBxSy0hdod5MxMvOcWRHQF3bWudDBFZSqzK2
7wjeXBKW+35NO9wKh41dYQkLZxsgjjMFuqQJzAgkn9ZpP+qLgKCVzgf8PtT+
QSgCY0HHrC46BqUyHp3lAOYaRfK2sMbjN58IJDs/jeeV+LWTnnf06EzgNQL8
psiPHlAiJPZnyXKliE+YfE98vua6i3H6AYEMGFDcZ8CItKts30JmQ6p59Ajm
+LVTDgPfg7FeRqIBAOaaJW5gHUB1wKLoYBT/sjji8fz87+8v5+dnPM4uZm/e
7AZxBW9zkF1cv3+TlvBo/+PT67dvz6/O4u9Zb3039Xb2Ke7BgDq4fndzeX01
e3MQYTeMEyPbW8gxZqx1yOiUBCVS4VSOpQgqBX47fQcnz2KFsJ7YbuP4l8iJ
61D5fJo1epP+9TVuQLYtSpd2kVpDIVvlpaYRH0O1XRuo0XEKH8FQhMZ8B4wm
Asz2WP6OlOZzihTfJ/VzKuQvP2hwYQH3mC/D6uwzJPKAkjL4kRqfqQbEMwHY
s4NdDIvPIVm9Qpd2Y63q/whrA0bjlmdCo8IJwOWCKyvy6GCRXQhZFNhyru6y
6MAZTu2OOGMlMZ77PXLUds2zotzHsbXK+Gh4jtH2CIedTf/PMEOO4qEwB0qM
O4YOtA/6h/txBsUNjcEcXCBx+DkJ1i/c8INbJ8dH8VBmIGW6gPmePPvcWQMd
pdsP4VABSUpQdjhs9gxo5pK880BeaQ0yUXT/hTmE+VWUQZqGnUJ/UARtaEPh
3MmfApMY3MR4zcDQ3xd1IEl0JrmNJXcV1hnpnNYawn2iQS2i04U0xnqGQ7IL
S5FvEiZ3mz1gzURwRe/o8zR1zJSl/0io/oE/C+v6YAy4IPX5YYioVyd3FGPI
p7EiNZO+pccGnye5GHkp5kdZI/U9R/4Ruv7acJaKji9jXm+gkUs++U7vih15
YADVttOlUE2DpZKekeOs1nz+d6oJfqCa9stGgrqiTlj9kfxIjfjzQHXE0v2c
NMeXJDkmYiB/opng5RKh4KCFei2x1XYTwmsXfs3zrSyWsor0LGyMGX+P6gJ8
LT00chMlntQOZbmBXo0MxcxOgu/LkNnQpByS8l0M//5s3tfgLnmNNF2Qx3mn
tA86MRocNb40YJN/Sc5FXkhG9I8gLvb4EjSuUJNQpuSa3d8TDt6nMk+I+7Aj
k4PYey97dhqsEsNVhdVdY2gE61oV9XftOSgrD0UtTcV3gXCvmV3N7oHw85X1
gdX46yjFoI9ssnX+8hTOS+Utv6cE5ypF3m1goVCX1EtTmVu+nTCf5enWF/e4
93DjFsUvPz15Ns4VTb4IEQxTFIKGYStmWfQPBmpfsAfx/CScxcG9G+/B3tKh
Nr69/cvl+GzysD3bLQg+LRbe4ckR29L3ncmftDWLNNLnqrf0YXXYvyvcMXoo
8sUfGT6wVPTF0DPh4fOjH7Hh4c9Hd9l3pnWi6YSxvpAdhocSOeQrvl+ohcIy
3aNzWSwZbbNiaexaY1kFoRvbf3wjIdZ2DgtmrqTvm6iG2ULqKs5jKNIg4njF
wmpt13xR5se7cK9QhWol/0ixDtT8DMe38bILjD0ohim8lW4JM1M6XNNIZB5X
CKfOFku+C71DzyJJFUuyZgQ3tW0kwSsnFyN4JzsNF3axaKQZwbwjggvbkcbN
CLK6a6wRF93XDkfwm3RuA29Q5XIEGby11iDJZjOCT1au4Eq5EbzU1ilp4Dqn
3cEinkcsezOPC2ngfZ4rs0yHf7SdR0cjuFENfFSFMrRUUTBzXBppNqLBCJx0
gzy7yq7f8R0iNJLK2a6NDFoqKjriVhLjw2UZm+1pTOfgbtaRrLBnr5C7vjVy
X0+x/hcWngv8g1oyH551y9qujArW3XnkrFVVa1XVPjaZhJ5ErIGwgnyJrx6D
tmMDcYv+7Y+89DQpDfGbnrdWU3g/gzXmpDx33L8OuarVKAmBZapPmOiFXdey
aN0rqb9xFF4pX3c5fEBH6bnqDo6E+FgrjfeZNry6QMmxsi1Pjvj1qZAmiB+F
a9ZM/My2xHIkFkyQfHGZip1jVTh5Utjmcf/c+ziyZv/vQ0/e/4u7/waxDAzO
whcAAA==
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</back>
</rfc> </rfc>
 End of changes. 47 change blocks. 
394 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.48.