< draft-ietf-tls-md5-sha1-deprecate-06.txt		draft-ietf-tls-md5-sha1-deprecate-07.txt >
	Internet Engineering Task Force L. Velvindron		Internet Engineering Task Force L. Velvindron
	Internet-Draft cyberstorm.mu		Internet-Draft cyberstorm.mu
	Updates: 5246 7525 (if approved) K. Moriarty		Updates: 5246 7525 (if approved) K. Moriarty
	Intended status: Standards Track Dell Technologies		Intended status: Standards Track Dell Technologies
	Expires: September 30, 2021 A. Ghedini		Expires: November 18, 2021 A. Ghedini
	Cloudflare Inc.		Cloudflare Inc.
	March 29, 2021		May 17, 2021
	Deprecating MD5 and SHA-1 signature hashes in TLS 1.2		Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
	draft-ietf-tls-md5-sha1-deprecate-06		draft-ietf-tls-md5-sha1-deprecate-07
	Abstract		Abstract
	The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to		The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to
	attack and this document deprecates their use in TLS 1.2 digital		attack and this document deprecates their use in TLS 1.2 digital
	signatures. However, this document does not deprecate SHA-1 in HMAC		signatures. However, this document does not deprecate SHA-1 in HMAC
	for record protection. This document updates RFC 5246 and RFC 7525.		for record protection. This document updates RFC 5246 and RFC 7525.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 30, 2021.		This Internet-Draft will expire on November 18, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	4. Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 3		4. Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 3
	5. Certificate Verify . . . . . . . . . . . . . . . . . . . . . 3		5. Certificate Verify . . . . . . . . . . . . . . . . . . . . . 3
	6. Updates to RFC5246 . . . . . . . . . . . . . . . . . . . . . 3		6. Updates to RFC5246 . . . . . . . . . . . . . . . . . . . . . 3
	7. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 4		7. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 4
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 5		9. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	11.1. Normative References . . . . . . . . . . . . . . . . . . 5		11.1. Normative References . . . . . . . . . . . . . . . . . . 5
	11.2. Informative References . . . . . . . . . . . . . . . . . 6		11.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is		The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
	specified in [RFC5246]. MD5 and SHA-1 have been proven to be		specified in [RFC5246]. MD5 and SHA-1 have been proven to be
	insecure, subject to collision attacks [Wang]. In 2011, [RFC6151]		insecure, subject to collision attacks [Wang]. In 2011, [RFC6151]
	detailed the security considerations, including collision attacks for		detailed the security considerations, including collision attacks for
	MD5. NIST formally deprecated use of SHA-1 in 2011		MD5. NIST formally deprecated use of SHA-1 in 2011
	[NISTSP800-131A-R2] and disallowed its use for digital signatures at		[NISTSP800-131A-R2] and disallowed its use for digital signatures at
	the end of 2013, based on both the Wang, et. al, attack and the		the end of 2013, based on both the Wang, et. al, attack and the
	potential for brute-force attack. In 2016, researchers from INRIA		potential for brute-force attack. In 2016, researchers from INRIA
	identified a new class of transcript collision attacks on TLS (and		identified a new class of transcript collision attacks on TLS (and
	other protocols) that rely on efficient collision-finding algorithms		other protocols) that rely on efficient collision-finding algorithms
	on the underlying hash constructions [Transcript-Collision].		on the underlying hash constructions [Transcript-Collision].
	Further, in 2017, researchers from Google and CWI Amsterdam		Further, in 2017, researchers from Google and CWI Amsterdam
	[SHA-1-Collision] proved SHA-1 collision attacks were practical.		[SHA-1-Collision] proved SHA-1 collision attacks were practical.
	This document updates [RFC5246] and [RFC7525] in such a way that MD5		This document updates [RFC5246] and [RFC7525] in such a way that MD5
	and SHA-1 MUST NOT be used for digital signatures. However, this		and SHA-1 MUST NOT be used for digital signatures. However, this
	document does not deprecate SHA-1 in HMAC for record protection.		document does not deprecate SHA-1 in HMAC for record protection.
			Note that the CABF has also deprecated use of SHA-1 [CABF].
	1.1. Requirements Language		1.1. Requirements Language
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Signature Algorithms		2. Signature Algorithms
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	NEW:		NEW:
	"Note: This is a change from TLS 1.1 where there are no explicit		"Note: This is a change from TLS 1.1 where there are no explicit
	rules, but as a practical matter one can assume that the peer		rules, but as a practical matter one can assume that the peer
	supports SHA-256."		supports SHA-256."
	7. Updates to RFC7525		7. Updates to RFC7525
	[RFC7525], Recommendations for Secure Use of Transport Layer Security		[RFC7525], Recommendations for Secure Use of Transport Layer Security
	(TLS) and Datagram Transport Layer Security (DTLS) recommends use of		(TLS) and Datagram Transport Layer Security (DTLS), recommends use of
	SHA-256 as a minimum requirement. This update moves the minimum		SHA-256 as a minimum requirement. This update moves the minimum
	recommendation to use stronger language deprecating use of both SHA-1		recommendation to use stronger language deprecating use of both SHA-1
	and MD5. The prior text did not explicitly include MD5 or SHA-1; and		and MD5. The prior text did not explicitly include MD5 or SHA-1; and
	this text adds guidance to ensure that these algorithms have been		this text adds guidance to ensure that these algorithms have been
	deprecated.		deprecated.
	Section 4.3:		Section 4.3:
	OLD:		OLD:
	When using RSA, servers SHOULD authenticate using certificates with		When using RSA, servers SHOULD authenticate using certificates with
	at least a 2048-bit modulus for the public key. In addition, SHA-256		at least a 2048-bit modulus for the public key. In addition, the use
	hash algorithm MUST be used (see [CAB-Baseline] for more details).		of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
	Clients SHOULD indicate to servers that they request SHA-256, by		more details). Clients SHOULD indicate to servers that they request
	using the "Signature Algorithms" extension defined in TLS 1.2.		SHA-256, by using the "Signature Algorithms" extension defined in TLS
			1.2.
	NEW:		NEW:
	Servers SHOULD authenticate using certificates with at least a		Servers SHOULD authenticate using certificates with at least a
	2048-bit modulus for the public key.		2048-bit modulus for the public key.
	In addition, the SHA-256 hash algorithm MUST be used; and SHA-1 or		In addition, the use of the SHA-256 hash algorithm is RECOMMENDED;
	MD5 MUST NOT be used (see [CAB-Baseline] for more details). Clients		and SHA-1 or MD5 MUST NOT be used (see [CAB-Baseline] for more
	MUST indicate to servers that they request SHA-256, by using the		details). Clients MUST indicate to servers that they request SHA-
	"Signature Algorithms" extension defined in TLS 1.2.		256, by using the "Signature Algorithms" extension defined in TLS
			1.2.
	8. IANA Considerations		8. IANA Considerations
	The document updates the "TLS SignatureScheme" registry to change the		The document updates the "TLS SignatureScheme" registry to change the
	recommended status of SHA-1 based signature schemes to N (not		recommended status of SHA-1 based signature schemes to N (not
	recommended) as defined by [RFC8447]. The following entries are to		recommended) as defined by [RFC8447]. The following entries are to
	be updated:		be updated:
	+--------+----------------+-------------+--------------------+		+--------+----------------+-------------+--------------------+
	| Value | Description | Recommended | Reference |		| Value | Description | Recommended | Reference |
	+--------+----------------+-------------+--------------------+		+--------+----------------+-------------+--------------------+
	| 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446] [RFCTBD] |		| 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446] [RFCTBD] |
	| 0x0203 | ecdsa_sha1 | N | [RFC8446] [RFCTBD] |		| 0x0203 | ecdsa_sha1 | N | [RFC8446] [RFCTBD] |
	+--------+----------------+-------------+--------------------+		+--------+----------------+-------------+--------------------+
	Other entries of the registry remain the same.		Other entries of the registry remain the same.
			IANA is also requested to update the Reference for the TLS
			SignatureAlgorithm and TLS HashAlgorithm registries to refer to this
			RFC:
			OLD:
			Reference
			[RFC5246][RFC8447]
			NEW:
			Reference
			[RFC5246][RFC8447][RFC-to-be]
	9. Security Considerations		9. Security Considerations
	Concerns with TLS 1.2 implementations falling back to SHA-1 is an		Concerns with TLS 1.2 implementations falling back to SHA-1 is an
	issue. This document updates the TLS 1.2 specification to deprecate		issue. This document updates the TLS 1.2 specification to deprecate
	support for MD5 and SHA-1 for digital signatures. However, this		support for MD5 and SHA-1 for digital signatures. However, this
	document does not deprecate SHA-1 in HMAC for record protection.		document does not deprecate SHA-1 in HMAC for record protection.
	10. Acknowledgement		10. Acknowledgement
	The authors would like to thank Hubert Kario for his help in writing		The authors would like to thank Hubert Kario for his help in writing
	the initial draft. We are also grateful to Daniel Migault, Martin		the initial draft. We are also grateful to Daniel Migault, Martin
	Thomson and David Cooper for their feedback.		Thomson, Sean Turner, Christopher Wood and David Cooper for their
			feedback.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 30 ¶
	and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,		and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
	<https://www.rfc-editor.org/info/rfc8447>.		<https://www.rfc-editor.org/info/rfc8447>.
	11.2. Informative References		11.2. Informative References
	[CAB-Baseline]		[CAB-Baseline]
	CA/Browser Forum, "Baseline Requirements for the Issuance		CA/Browser Forum, "Baseline Requirements for the Issuance
	and Management of Publicly-Trusted Certificates Version		and Management of Publicly-Trusted Certificates Version
	1.1.6", 2013, <https://www.cabforum.org/documents.html>.		1.1.6", 2013, <https://www.cabforum.org/documents.html>.
			[CABF] CA/Browser Forum, "Ballot 118 -- SHA-1 Sunset (passed)",
			2014, <https://cabforum.org/2014/10/16/ballot-118-sha-
			1-sunset/>.
	[NISTSP800-131A-R2]		[NISTSP800-131A-R2]
	Barker, E. and A. Roginsky, "Transitioning the Use of		Barker, E. and A. Roginsky, "Transitioning the Use of
	Cryptographic Algorithms and Key Lengths", March 2019,		Cryptographic Algorithms and Key Lengths", March 2019,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-131Ar2.pdf>.		NIST.SP.800-131Ar2.pdf>.
	[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations		[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
	for the MD5 Message-Digest and the HMAC-MD5 Algorithms",		for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
	RFC 6151, DOI 10.17487/RFC6151, March 2011,		RFC 6151, DOI 10.17487/RFC6151, March 2011,
	<https://www.rfc-editor.org/info/rfc6151>.		<https://www.rfc-editor.org/info/rfc6151>.
End of changes. 12 change blocks.
	15 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/