<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<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" submissionType="IETF" updates="4034, 5155" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>

    <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">
      <organization>USC/ISI</organization>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization>Google</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2025" month="November"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<abstract>
<t>This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1
algorithms for the creation of DNS Public Key (DNSKEY) and Resource
Record Signature (RRSIG) records.</t>
      <t>It updates RFCs 4034 and 5155 as it deprecates the use of these algorithms.</t>
    </abstract>
  </front>
  <middle>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The security of the protection provided by the SHA-1 algorithm <xref target="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 target="RFC3110"/>) made extensive use
of SHA-1, for example, as a
cryptographic hash algorithm in Resource Record Signature (RRSIG) and Delegation Signer (DS)
records. Since then, multiple other algorithms with
stronger cryptographic strength have become widely available for DS records 
and for RRSIG and DNS Public Key (DNSKEY) records <xref target="RFC4034"/>.
Operators are encouraged to consider switching to one of the recommended algorithms 
listed in the "DNS Security Algorithm
   Numbers" <xref target="DNSKEY-IANA"/> and "DNS Security Algorithm
   Numbers" <xref target="DS-IANA"/> registries, respectively.
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 
is no longer fully interoperable
in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is
no longer advisable.</t>
      <t>This document thus deprecates the use of RSASHA1 and
RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.</t>
      <section anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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&nbsp;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-sha-1-from-dnssec-signatures-and-delegation-rrs">
      <name>Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs</name>
      <t>The RSASHA1 <xref target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"/> algorithms <bcp14>MUST NOT</bcp14>
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
delegation point <bcp14>MUST</bcp14> be treated as insecure.</t>
      <t>The RSASHA1 <xref target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"/> algorithms <bcp14>MUST NOT</bcp14> be
used when creating DNSKEY and RRSIG records.  Validating resolver implementations
(<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
domains as of this publication. Operators of validating resolvers <bcp14>MUST</bcp14> treat DNSSEC signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, rendering responses insecure if they cannot be validated by other supported signing algorithms.</t></section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>      
      <t>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>
    </section>
    <section anchor="operational-considerations">
      <name>Operational Considerations</name>
      
      <t>Zone owners currently making use of SHA-1-based algorithms should
immediately switch to algorithms with stronger cryptographic algorithms,
such as the recommended algorithms in the IANA registries <xref target="DNSKEY-IANA"/> <xref target="DS-IANA"/>.</t>
      <t>Operators should take care when deploying software packages and
operating systems that may have already removed support for the SHA-1
algorithm.  In these situations, software may need to be manually built
and deployed by an operator to continue supporting the required levels
indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC
Validation" columns, which this document is not changing.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>IANA has updated the SHA-1 (1) entry in the "Digest Algorithms" registry <xref target="DS-IANA"/> <xref target="RFC9904"/> as follows and has added this document as a reference for the entry:</t>

<dl spacing="compact">
 <dt>Value:</dt><dd> 1</dd>
 <dt> Description:</dt><dd> SHA-1</dd>
 <dt> Use for DNSSEC Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
 <dt> Use for DNSSEC Validation:</dt><dd><bcp14>RECOMMENDED</bcp14></dd>
 <dt> Implement for DNSSEC Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
 <dt> Implement for DNSSEC Validation:</dt><dd><bcp14>MUST</bcp14></dd>
</dl>

<t>  IANA has updated the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7)
  algorithm entries in the "DNS Security Algorithm Numbers" registry
  <xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> as follows and has added this document as a
  reference for the entries:
</t>

<dl spacing="compact">
  <dt> Number:</dt><dd> 5</dd>
   <dt>Description:</dt><dd> RSA/SHA-1</dd>
   <dt>Mnemonic:</dt><dd> RSASHA1</dd>
   <dt>Zone Signing:</dt><dd> Y</dd>
   <dt>Trans. Sec.:</dt><dd> Y</dd>
   <dt>Use for DNSSEC Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
   <dt>Use for DNSSEC Validation:</dt><dd><bcp14>RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Signing:</dt><dd><bcp14>NOT RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Validation:</dt><dd><bcp14>MUST</bcp14></dd>
</dl>

<dl spacing="compact">
   <dt>Number:</dt><dd> 7</dd>
  <dt> Description:</dt><dd> RSASHA1-NSEC3-SHA1</dd>
   <dt>Mnemonic:</dt><dd> RSASHA1-NSEC3-SHA1</dd>
   <dt>Zone Signing: </dt><dd>Y</dd>
   <dt>Trans. Sec.:</dt><dd> Y</dd>
   <dt>Use for DNSSEC Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
   <dt>Use for DNSSEC Validation:</dt><dd><bcp14>RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Signing:</dt><dd><bcp14>NOT RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Validation:</dt><dd><bcp14>MUST</bcp14></dd>
</dl> 

    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3110.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
      <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers">
        <front>
          <title>DNS Security 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>Digest Algorithms</title>
          <author initials="" surname="IANA" fullname="IANA">
            <organization/>
          </author>
        </front>
      </reference>

      <reference anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9904">
        <front>
          <title>DNSSEC Cryptographic Algorithm Recommendation Update Process</title>
          <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='November' year='2025'/>
        </front>
        <seriesInfo name="RFC" value="9904"/>
        <seriesInfo name="DOI" value="10.17487/RFC9904"/>
      </reference>
    </references>

    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <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="Peter Dickson"/>, <contact fullname="Thomas Graf"/>, <contact
      fullname="Paul Hoffman"/>, <contact fullname="Russ Housley"/>, <contact
      fullname="Shumon Huque"/>, <contact fullname="Barry Leiba"/>, <contact
      fullname="S. Moonesamy"/>, <contact fullname="Yoav Nir"/>, <contact
      fullname="Florian Obser"/>, <contact fullname="Peter Thomassen"/>,
      <contact fullname="Stefan Ubbink"/>, <contact fullname="Paul Wouters"/>,
      <contact fullname="Tim Wicinski"/>, and the many members of the DNSOP
      Working Group that discussed this specification.</t>
    </section>    
  </back>
</rfc>
