Diff: rfc9905v1.txt - rfc9905.txt

	rfc9905v1.txt	rfc9905.txt

	skipping to change at line 72 ¶	skipping to change at line 72 ¶
	The security of the protection provided by the SHA-1 algorithm	The security of the protection provided by the SHA-1 algorithm
	[RFC3174] has been slowly diminishing over time as various forms of	[RFC3174] has been slowly diminishing over time as various forms of
	attacks have weakened its cryptographic underpinning. DNSSEC	attacks have weakened its cryptographic underpinning. DNSSEC
	[RFC9364] (originally defined in [RFC3110]) made extensive use of	[RFC9364] (originally defined in [RFC3110]) made extensive use of
	SHA-1, for example, as a cryptographic hash algorithm in Resource	SHA-1, for example, as a cryptographic hash algorithm in Resource
	Record Signature (RRSIG) and Delegation Signer (DS) records. Since	Record Signature (RRSIG) and Delegation Signer (DS) records. Since
	then, multiple other algorithms with stronger cryptographic strength	then, multiple other algorithms with stronger cryptographic strength
	have become widely available for DS records and for RRSIG and DNS	have become widely available for DS records and for RRSIG and DNS
	Public Key (DNSKEY) records [RFC4034]. Operators are encouraged to	Public Key (DNSKEY) records [RFC4034]. Operators are encouraged to
	consider switching to one of the recommended algorithms listed in the	consider switching to one of the recommended algorithms listed in the

	[DNSKEY-IANA] and [DS-IANA] tables, respectively. Further, support	"DNS Security Algorithm Numbers" [DNSKEY-IANA] and "DNS Security
	for validating SHA-1-based signatures has been removed from some	Algorithm Numbers" [DS-IANA] registries, respectively. Further,
	systems. As a result, SHA-1 as part of a signature algorithm is no	support for validating SHA-1-based signatures has been removed from
	longer fully interoperable in the context of DNSSEC. As adequate	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.	alternatives exist, the use of SHA-1 is no longer advisable.

	This document thus deprecates the use of RSASHA1 and	This document thus deprecates the use of RSASHA1 and
	RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.	RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.

	1.1. Requirements Notation	1.1. Requirements Notation

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in

	skipping to change at line 111 ¶	skipping to change at line 112 ¶
	support validation using these algorithms as they are diminishing in	support validation using these algorithms as they are diminishing in
	use but still actively in use for some domains as of this	use but still actively in use for some domains as of this
	publication. Operators of validating resolvers MUST treat DNSSEC	publication. Operators of validating resolvers MUST treat DNSSEC
	signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported,	signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported,
	rendering responses insecure if they cannot be validated by other	rendering responses insecure if they cannot be validated by other
	supported signing algorithms.	supported signing algorithms.

	3. Security Considerations	3. Security Considerations

	This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1	This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1

	for DNSSEC Delegation and DNSSEC signing since these algorithms are	for DNSSEC delegation and DNSSEC signing since these algorithms are
	no longer considered to be secure.	no longer considered to be secure.

	4. Operational Considerations	4. Operational Considerations

	Zone owners currently making use of SHA-1-based algorithms should	Zone owners currently making use of SHA-1-based algorithms should

	immediately roll to algorithms with stronger cryptographic	immediately switch to algorithms with stronger cryptographic
	algorithms, such as the recommended algorithms in the [DNSKEY-IANA]	algorithms, such as the recommended algorithms in the IANA registries
	and [DS-IANA] tables.	[DNSKEY-IANA] [DS-IANA].

	Operators should take care when deploying software packages and	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	algorithm. In these situations, software may need to be manually
	built and deployed by an operator to continue supporting the required	built and deployed by an operator to continue supporting the required
	levels indicated by the "Use for DNSSEC Validation" and "Implement	levels indicated by the "Use for DNSSEC Validation" and "Implement
	for DNSSEC Validation" columns, which this document is not changing.	for DNSSEC Validation" columns, which this document is not changing.

	5. IANA Considerations	5. IANA Considerations


	IANA has set the "Use for DNSSEC Delegation" column of the "Digest	IANA has updated the SHA-1 (1) entry in the "Digest Algorithms"
	Algorithms" registry [DS-IANA] [RFC9904] to MUST NOT for SHA-1 (1)	registry [DS-IANA] [RFC9904] as follows and has added this document
	and has added this document as a reference for the entry.	as a reference for the entry:


	IANA has set the "Use for DNSSEC Signing" column of the "DNS Security	Value: 1
	Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] to MUST NOT for	Description: SHA-1
	the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms and has added	Use for DNSSEC Delegation: MUST NOT
	this document as a reference for these entries.	Use for DNSSEC Validation: RECOMMENDED
		Implement for DNSSEC Delegation: MUST NOT
		Implement for DNSSEC Validation: MUST


	All other columns should remain as currently specified.	IANA has updated the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithm
		entries in the "DNS Security Algorithm Numbers" registry
		[DNSKEY-IANA] [RFC9904] as follows and has added this document as a
		reference for the entries:

		Number: 5
		Description: RSA/SHA-1
		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

		Number: 7
		Description: RSASHA1-NSEC3-SHA1
		Mnemonic: RSASHA1-NSEC3-SHA1
		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

	6. Normative References	6. Normative References

	[DNSKEY-IANA]	[DNSKEY-IANA]
	IANA, "Domain Name System Security (DNSSEC) Algorithm	IANA, "Domain Name System Security (DNSSEC) Algorithm
	Numbers",	Numbers",
	<https://www.iana.org/assignments/dns-sec-alg-numbers>.	<https://www.iana.org/assignments/dns-sec-alg-numbers>.

	[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)	[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
	Type Digest Algorithms",	Type Digest Algorithms",

	skipping to change at line 189 ¶	skipping to change at line 215 ¶
	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
	RFC 9364, DOI 10.17487/RFC9364, February 2023,	RFC 9364, DOI 10.17487/RFC9364, February 2023,
	<https://www.rfc-editor.org/info/rfc9364>.	<https://www.rfc-editor.org/info/rfc9364>.

	[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,	[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
	RFC 9499, DOI 10.17487/RFC9499, March 2024,	RFC 9499, DOI 10.17487/RFC9499, March 2024,
	<https://www.rfc-editor.org/info/rfc9499>.	<https://www.rfc-editor.org/info/rfc9499>.

	[RFC9904] Hardaker, W. and W. Kumari, "DNSSEC Cryptographic	[RFC9904] Hardaker, W. and W. Kumari, "DNSSEC Cryptographic
	Algorithm Recommendation Update Process", RFC 9904,	Algorithm Recommendation Update Process", RFC 9904,

	DOI 10.17487/RFC9904, October 2025,	DOI 10.17487/RFC9904, November 2025,
	<https://www.rfc-editor.org/info/rfc9904>.	<https://www.rfc-editor.org/info/rfc9904>.

	Acknowledgments	Acknowledgments

	The authors appreciate the comments and suggestions from the	The authors appreciate the comments and suggestions from the
	following IETF participants in helping produce this document: Mark	following IETF participants in helping produce this document: Mark
	Andrews, Steve Crocker, Peter Dickson, Thomas Graf, Paul Hoffman,	Andrews, Steve Crocker, Peter Dickson, Thomas Graf, Paul Hoffman,
	Russ Housley, Shumon Huque, Barry Leiba, S. Moonesamy, Yoav Nir,	Russ Housley, Shumon Huque, Barry Leiba, S. Moonesamy, Yoav Nir,
	Florian Obser, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim	Florian Obser, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim
	Wicinski, and the many members of the DNSOP Working Group that	Wicinski, and the many members of the DNSOP Working Group that

End of changes. 7 change blocks.
	17 lines changed or deleted	43 lines changed or added
This html diff was produced by rfcdiff 1.48.