Hello! Our crypto folks are truly confused in wording of paragraph 2 of
this document.
I admit I am not sure myself, what the instruction is in this paragraph:
The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms
MUST NOT be used when creating DNSKEY and RRSIG records. Validating
resolver implementations ([RFC9499], Section 10) 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. Operators of validating resolvers MUST treat DNSSEC
signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported,
rendering responses insecure if they cannot be validated by other
supported signing algorithms.
Now what is the instruction about validation in this case? If the crypto
library does not allow validation of any RSA1 signature, it will just
fail. That is case of DEFAULT crypto-policy on RHEL 9 and 10. Similar
behaviour can be configured on Fedora DEFAULT:NO-SHA1 crypto policy.
In this case, resolver is not able to validate RSASHA1 even with the
best intent. The only way around is to bundle own crypto library, which
does not block validation of SHA1 signatures. Is that what is
recommended here?
More specific:
Validating
resolver implementations ([RFC9499], Section 10) 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.
We have no way to implement this on RHEL. We would like MUST changed to
SHOULD in this sentence. Is it possible as part of errata?
I think it goes directly against section 5:
Alg 1:
Use for DNSSEC Validation: RECOMMENDED
Alg 5:
Use for DNSSEC Validation: RECOMMENDED
Alg 7:
Use for DNSSEC Validation: RECOMMENDED
Now, how is it possible to be RECOMMENDED, when it is also a MUST in
section 2?
Can you clarify how is it meant?
I am sorry this was noticed only after final publication. But except it
clearly say to not create new alg 5 or 7 signatures, I am not sure what
is instruction for receiving them.
On 01/12/2025 01:35, [email protected] wrote:
A new Request for Comments is now available in online RFC libraries.
RFC 9905
Title: Deprecating the Use of SHA-1
in DNSSEC Signature Algorithms
Author: W. Hardaker,
W. Kumari
Status: Standards Track
Stream: IETF
Date: November 2025
Mailbox: [email protected],
[email protected]
Pages: 5
Updates: RFC 4034, RFC 5155
I-D Tag: draft-ietf-dnsop-must-not-sha1-10.txt
URL: https://www.rfc-editor.org/info/rfc9905
DOI: 10.17487/RFC9905
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.
It updates RFCs 4034 and 5155 as it deprecates the use of these
algorithms.
This document is a product of the Domain Name System Operations Working Group
of the IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email protected]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
