Deprecating the use of SHA-1 in DNSSEC signature algorithms
draft-ietf-dnsop-must-not-sha1-09

RFC Editor Note was changed to

RFC Editor Note

RFC Editor Note

When allocating RFC numbers for this I-D and for the related DNS drafts, please use three consecutive RFC numbers starting with draft-ietf-dnsop-rfc8624-bis, then draft-ietf-dnsop-must-not-sha1, then draft-ietf-dnsop-must-not-ecc-gost.

Thanks

-éric

[Ballot comment]
Thanks for addressing my DISCUSS points and some of my comments. I have updated my ballot to Yes.

I'll leave the one comment here below that didn't get incorporated in some way :)


In the Operational Considerations, one could add a sentence about the difference of not supporting SHA-1 versus
having a system that does not support SHA-1. The first results in an insecure validation, which is okay. The second
can result in ServFail, which is not okay. Something along the lines of:

      When not supporting or disabling SHA-1, care should be given by implementers that the DNS software itself is made
      aware not to consume SHA-1. For example, disabling SHA-1 at the Operating System level could result in SHA-1 cryptographic
      failures within the DNS system, which would result in those zones failing, instead of the zones being treated as unsigned/insecure

[Ballot comment]
Thanks for addressing my DISCUSS points and some of my comments. I'll leave the only comment here below that didn't get incorporated in some way :)


In the Operational Considerations, one could add a sentence about the difference of not supporting SHA-1 versus
having a system that does not support SHA-1. The first results in an insecure validation, which is okay. The second
can result in ServFail, which is not okay. Something along the lines of:

      When not supporting or disabling SHA-1, care should be given by implementers that the DNS software itself is made
      aware not to consume SHA-1. For example, disabling SHA-1 at the Operating System level could result in SHA-1 cryptographic
      failures within the DNS system, which would result in those zones failing, instead of the zones being treated as unsigned/insecure

[Ballot comment]
Hi Wes/Warren,

Thank you for the discussion and for taking care of the comments raised in my initial ballot [1].

-08 has still a stale normative reference to draft-ietf-dnsop-algorithm-update. Wes already merged the PR to fix that [2]. I trust that to be in -09.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/eUM1DT_ttH6dy4VAvS7sf17OYKg/

[2] https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-must-not-sha1/commit/984686b876eca148ee0dcd43911f2813392cbc79

[Ballot comment]
Hi Wes/Warren,

Thank you for the discussion and for taking care of the comments raised in my initial ballot [1].

-08 has still a stale normative reference to draft-ietf-dnsop-algorithm-update. Wes already merged the PR to fix that [2]. I trust to be in -09.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/eUM1DT_ttH6dy4VAvS7sf17OYKg/

[2] https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-must-not-sha1/commit/984686b876eca148ee0dcd43911f2813392cbc79

[Ballot discuss]
I very much plan to say Yes, after one error is fixed in the document:

      This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for DNSSEC Delegation and DNSSEC signing

I think "DNSSEC Delegation" here is wrong. That is hashing, not signing and it does not use RSASHA1 or RSASHA1-NSEC3-SHA1
which are DNSKEY Signing algorithm numbers and not DNSSEC Delegation Signer algorithm numbers.

[Ballot comment]
        Zone owners currently making use of SHA-1 based algorithms should immediately switch to algorithms

I would use "should immediately rollover to algorithms" to avoid the illusion some inexperienced DNS admins might
have that they can just "switch" the algorithm without proper prep work of doing a real roll over.
And the Operational Considerations that I thought should be removed from draft-ietf-dnsop-rfc8624-bis would
actually make sense here :)

      As a result, SHA-1 is no longer fully interoperable in the context of DNSSEC. As adequate alternatives
      exist, the use of SHA-1 is no longer advisable.

That should be, "SHA-1 as part of a signature algorithm". Because the document isn't obsoleting SHA-1 from DS hashing
algorithms right?


      2. Deprecating RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms in DNSSEC

Can the title include "signing" in the name to clarify validating is still okay?


Should it state that SHA1 as part of the NSEC3 algorithm itself is also not obsoleted? Perhaps this can be avoided if the
rest of the document can strongly bind the obsoleting of SHA-1 to "signing algorithm".

In the Operational Considerations, one could add a sentence about the difference of not supporting SHA-1 versus
having a system that does not support SHA-1. The first results in an insecure validation, which is okay. The second
can result in ServFail, which is not okay. Something along the lines of:

      When not supporting or disabling SHA-1, care should be given by implementers that the DNS software itself is made
      aware not to consume SHA-1. For example, disabling SHA-1 at the Operating System level could result in SHA-1 cryptographic
      failures within the DNS system, which would result in those zones failing, instead of the zones being treated as unsigned/insecure

[Ballot discuss]
Hi Wes, Warren,

Thank you for the effort put into this work. This is a maintenance effort that is definitely needed.

Thanks for Thomas Graf for his OPSDIR review. This is his first review for opsdir, btw. Welcome Thomas!

Even if not listed as DISCUSS point, some points in the COMMENT part need to be fixed (last one, obviously). I have some nits that I will send you in a PR.

# Process Check (CLOSED)

De we need to do anything given that some of the work we are updating falls under pre-5378?

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

Note that we may not this based on the outcome of the other DISCUSS points

# Authoritative source for recommended DNSSEC Algos

I was naively expecting that we have a document where we say that the authoritative reference for recommended values is the IANA registry, not individual RFCs?

Do we have such document? If so, the explicit updates in the draft may not be required.

# BCP237 Umbrella  (CLOSED)

As a big fun of BCP237, I wonder whether we should make this more visible in our DNSSEC “roadmap” documentation and list this document under the BCP237 umbrella?

Of course, this may have implications on the intended status (as currently set). The status should not be problematic in this case as we have “RFC Required” (not Standard) policy for both registries. Thanks Paul for RFC6014.

Note that the reco still suggest that validating resolvers to continue validating, which is reasonable.

Not sure if this was discussed in the past, but I wanted to make sure we have a record for such discussion.

[Ballot comment]
Thanks for this write up. It reads and explains the reasoning well.

The idnits tool spawns some messages.

I have a single idnit observation on this draft.

74   RRSIG and Delegation Signer (DS) records, for example.  Since then,
75   multiple other algorithms with stronger cryptographic strength are
76   now widely available for DS records and for DNSKEY and RRSIG records.
77   Readers are encouraged to consider switching to one of the
78   recommended algorithms listed in the [DNSKEY-IANA] and [DS-IANA]
79   tables, respectively.

GV> I am not that familiar with DNSSEC and had to lookup DNSKEY and RRSIG records reference.
Could a reference (rfc4034) be explicitly added for these? Potentially when more familiar with these technologies it is obvious and are well known records through.


Be well,
G/

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-dnsop-must-not-sha1-06
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-must-not-sha1-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Barry Leiba for the ARTART review.

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.

** Section 1 and 2.

-- Section 1. “Further, support for validating SHA-1 based signatures has been removed from some systems.”

-- Section 2. “Validating resolver implementations MUST 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.”

Are these text snippets saying that implementation have already chosen to drop SHA-1 support, despite this draft saying it should not be?

** Section 1.
  As adequate
  alternatives exist, the use of SHA-1 is no longer advisable.

Doesn’t Section 2 say something much stronger than “no longer advisable”.  It uses “MUST NOT”.

** Section 3.
  This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1
  signatures since they are no longer considered to be secure.

Isn’t this imprecise? The prior seems to leave wide latitude to validating resolvers to continue to validate SHA1-based signatures.  Maybe

NEW (roughly)
This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 signatures in new DNSSEC records since these algorithms are no longer considered to be secure.

[Ballot comment]
Section 1:

The current phrasing of the second sentence in the Introduction suggests that the use of SHA-1 by DNSSEC is an example of its diminishing security; I suspect that's not the intended reading.

CURRENT: DNSSEC [RFC9364] originally [RFC3110] made extensive use of SHA-1 as a cryptographic hash algorithm in RRSIG and Delegation Signer (DS) records, for example.
CONSIDER: DNSSEC [RFC9364] originally [RFC3110] made extensive use of SHA-1, for example as a cryptographic hash algorithm in RRSIG and Delegation Signer (DS) records.

"are now" => "have become"

Section 2:

"MAY wish to" requires an RFC6919 reference (see https://datatracker.ietf.org/doc/html/rfc6919#section-6) and associated boilerplate. Instead, "MAY" is sufficient here. However, that seems in direct contradiction to the MUST in the first sentence. Is the intended sense here that implementations MUST retain the ability to validate, but SHOULD/MAY disable it by default?

[Ballot comment]
Thanks to the authors and the WG for this document.

Even though there is no "historic" element in the context of this document as it was for ECC-GOST document, please check/consider if any of those approaches (that I provided in my comments on the ECC-GOST document) are applicable for this document as well.

[Ballot comment]
Thanks to the authors and the WG for this document.

Even though there is no "historic" element in the context of this document as it was for ECC-GOST document, please check/consider if any of those approaches are applicable for this document as well.

[Ballot discuss]
Hi Wes, Warren,

Thank you for the effort put into this work. This is a maintenance effort that is definitely needed.

Thanks for Thomas Graf for his OPSDIR review. This is his first review for opsdir, btw. Welcome Thomas!

I will be definitely balloting “Yes”, but I have few DISCSS points to be resolved first. Even if not listed as DISCUSS point, some points in the COMMENT part need to be fixed (last one, obviously). I have some nits that I will send you in a PR.

# Process Check

De we need to do anything given that some of the work we are updating falls under pre-5378?

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

Note that we may not this based on the outcome of the other DISCUSS points

# Authoritative source for recommended DNSSEC Algos

I was naively expecting that we have a document where we say that the authoritative reference for recommended values is the IANA registry, not individual RFCs?

Do we have such document? If so, the explicit updates in the draft may not be required.

# BCP237 Umbrella

As a big fun of BCP237, I wonder whether we should make this more visible in our DNSSEC “roadmap” documentation and list this document under the BCP237 umbrella?

Of course, this may have implications on the intended status (as currently set). The status should not be problematic in this case as we have “RFC Required” (not Standard) policy for both registries. Thanks Paul for RFC6014.

Note that the reco still suggest that validating resolvers to continue validating, which is reasonable.

Not sure if this was discussed in the past, but I wanted to make sure we have a record for such discussion.

[Ballot comment]
# Expand DNS Public Key (DNSKEY) and resource record digital signature (RRSIG) in the abstract and introduction.

# Introduction

(1) Reword for better clarity

s/The security of the SHA-1/The security protection provided by the SHA-1

(2) Inappropriate citation

CURRENT: “DNSSEC [RFC9364] originally [RFC3110]..”

I would not cite this specific RFC as this may imply that it is RFC that «made extensive».

(3)

CURRENT: “Readers are encouraged to consider ..”

Not sure to parse the intent here? Do you mean implementers? Operators? Both? Please reword accordingly.

(4)

CURRENT: “has been removed from some systems”

May cite an example

# Section 2:

(1)

CURRENT: “Validating resolver implementations MUST ..”

Please add a reference to https://datatracker.ietf.org/doc/html/rfc9499#section-10.

(2)

CURRENT: “more security strict environments..”

Can we characterize this? Or provide an example? Thanks.

# IANA Considerations

CURRENT: “IANA is requested to set the "Use for DNSSEC Signing" column …”

There is no such column. I guess you meant “Zone Signing”?

# References

You have many references that are listed but not sued (RFC4033, RFC4509, RFC5702, etc.). Please check these.

Also, there is a problem in how the references are classified. For example, you list “RFC8174” as informative, while this should be normative. Likewise, “RFC3110” is listed as normative, while it should be informative.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-must-not-sha1-03. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Digest Algorithms registry in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry group located at:

https://www.iana.org/assignments/ds-rr-types/

the existing registration for:

Value: 1
Description: SHA-1
Status: MANDATORY
Reference: [RFC3658]

will be changed to:

Value: 1
Description: SHA-1
Status: MUST NOT
Reference: [RFC3658][ RFC-to-be ]

Second, in the DNS Security Algorithm Numbers registry in the Domain Name System Security (DNSSEC) Algorithm Numbers registry group located at:

https://www.iana.org/assignments/dns-sec-alg-numbers/

two existing registrations will be changed as follows:

Number: 5
Description: RSA/SHA-1
Mnemonic: RSASHA1
Zone Signing: Y
Trans. Sec.: Y
Reference: [RFC3110][proposed standard][RFC4034][proposed standard]

will be changed to:

Number: 5
Description: RSA/SHA-1
Mnemonic: RSASHA1
Zone Signing: MUST NOT
Trans. Sec.: Y
Reference: [RFC3110][proposed standard][RFC4034][proposed standard][ RFC-to-be ]

and

Number: 7
Description: RSASHA1-NSEC3-SHA1
Mnemonic: RSASHA1-NSEC3-SHA1
Zone Signing: Y
Trans. Sec.: Y
Reference: [RFC5155][proposed standard]

will be changed to:

Number: 7
Description: RSASHA1-NSEC3-SHA1
Mnemonic: RSASHA1-NSEC3-SHA1
Zone Signing: MUST NOT
Trans. Sec.: Y
Reference: [RFC5155][proposed standard][ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-03-06):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-must-not-sha1@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deprecating the use of SHA-1 in DNSSEC signature algorithms) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Deprecating the use of SHA-1
in DNSSEC signature algorithms'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-03-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

This document is part of a cluster of 3 DNSOP WG documents and it is
recommended to start with draft-ietf-dnsop-rfc8624-bis before any of
the others (draft-ietf-dnsop-must-not-sha1 and
draft-ietf-dnsop-must-not-ecc-gost).

Abstract


  This document deprecates the use of the RSASHA1 and
  RSASHA1-NSEC3-SHA1 algorithms for the creation of DNSKEY and RRSIG
  records.

  It updates RFC4034 and RFC5155 as it deprecates the use of these
  algorithms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/



No IPR declarations have been submitted directly on this I-D.

(1)  RFC is Standards Track, and this is the correct RFC type.They are updating Proposed Standards hence it is Proposed Standards.

(2)

Technical Summary:

This document retires the use of SHA-1 within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference RFC 3174, but this is correct as most RFCs which reference
it do so normatively. https://datatracker.ietf.org/doc/rfc3174/referencedby/

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1)  RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document retires the use of SHA-1 within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference RFC 3174, but this is correct as most RFCs which reference
it do so normatively. https://datatracker.ietf.org/doc/rfc3174/referencedby/

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1)  RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document retires the use of SHA-1 within DNSSEC.

Working Group Summary:

WG consensus was solid.
Document Quality:

This document is a "cleanup" document which retires a DNSSEC algorithm from use.
It is clear and understandable.

Document Shepherd: Tim Wicinski

Responsible Area Director: Eric Vyncke

(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar). The shepherd feels the
document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) Nits flagged two IANA registries as possible downref, but this is fine.
Also Normative reference RFC 3174, but this is correct as most RFCs which reference
it do so normatively. https://datatracker.ietf.org/doc/rfc3174/referencedby/

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang