< draft-ietf-tls-md5-sha1-deprecate-02.txt		draft-ietf-tls-md5-sha1-deprecate-03.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 EMC		Intended status: Standards Track Dell EMC
	Expires: July 25, 2020 A. Ghedini		Expires: November 15, 2020 A. Ghedini
	Cloudflare Inc.		Cloudflare Inc.
	January 22, 2020		May 14, 2020
	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-02		draft-ietf-tls-md5-sha1-deprecate-03
	Abstract		Abstract
	The MD5 and SHA-1 hashing algorithms are steadily weakening in		The MD5 and SHA-1 hashing algorithms are steadily weakening in
	strength and their deprecation process should begin for their use in		strength and their deprecation process should begin for their use in
	TLS 1.2 digital signatures. However, this document does not		TLS 1.2 digital signatures. However, this document does not
	deprecate SHA-1 in HMAC for record protection.		deprecate SHA-1 in HMAC for record protection.
	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 July 25, 2020.		This Internet-Draft will expire on November 15, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
	2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 2		2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 3
	3. Certificate Request . . . . . . . . . . . . . . . . . . . . . 3		3. Certificate Request . . . . . . . . . . . . . . . . . . . . . 3
	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. Security Considerations . . . . . . . . . . . . . . . . . . . 4		8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4		9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	10.1. Normative References . . . . . . . . . . . . . . . . . . 5		10.1. Normative References . . . . . . . . . . . . . . . . . . 5
	10.2. Informative References . . . . . . . . . . . . . . . . . 5		10.2. Informative References . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	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 RFC 5246 [RFC5246]. MD5 and SHA-1 have been proven to		specified in RFC 5246 [RFC5246]. MD5 and SHA-1 have been proven to
	be insecure, subject to collision attacks. RFC 6151 [RFC6151]		be insecure, subject to collision attacks. RFC 6151 [RFC6151]
	details the security considerations, including collision attacks for		details the security considerations, including collision attacks for
	MD5, published in 2011. NIST formally deprecated use of SHA-1 in		MD5, published in 2011. NIST formally deprecated use of SHA-1 in
	2011 [NISTSP800-131A-R2] and disallowed its use for digital		2011 [NISTSP800-131A-R2] and disallowed its use for digital
	signatures at the end of 2013, based on both the Wang, et. al, attack		signatures at the end of 2013, based on both the Wang, et. al, attack
	and the potential for brute-force attack. Further, in 2017,		and the potential for brute-force attack. In 2016, researchers from
	researchers from Google and CWI Amsterdam [SHA-1-Collision] proved		INRIA identified a new class of transcript collision attacks on TLS
	SHA-1 collision attacks were practical. This document updates		(and other protocols) that rely on efficient collision-finding
	RFC 5246 [RFC5246] and RFC7525 [RFC7525] in such as way that MD5 and		algorithms on the underlying hash constructions
	SHA-1 MUST NOT be used for digital signatures. However, this		[Transcript-Collision]. Further, in 2017, researchers from Google
	document does not deprecate SHA-1 in HMAC for record protection.		and CWI Amsterdam [SHA-1-Collision] proved SHA-1 collision attacks
			were practical. This document updates RFC 5246 [RFC5246] and RFC7525
			[RFC7525] in such a way that MD5 and SHA-1 MUST NOT be used for
			digital signatures. However, this document does not deprecate SHA-1
			in HMAC for record protection.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Signature Algorithms		2. Signature Algorithms
	Clients SHOULD NOT include MD5 and SHA-1 in the signature_algorithms		Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
	extension. If a client does not send a signature_algorithms		extension. If a client does not send a signature_algorithms
	extension, then the server MUST abort the handshake and send a		extension, then the server MUST abort the handshake and send a
	handshake_failure alert, except when digital signatures are not used		handshake_failure alert, except when digital signatures are not used
	(for example, when using PSK ciphers).		(for example, when using PSK ciphers).
	3. Certificate Request		3. Certificate Request
	Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest		Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
	message.		messages.
	4. Server Key Exchange		4. Server Key Exchange
	Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message.		Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
	If client does receive a MD5 or SHA-1 signature in the		If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
	ServerKeyExchange message and it sent one in signature_algorithms		message it MUST abort the connection with the illegal_parameter
	extensions it MUST abort the connection with handshake_failure or		alert.
	insufficient_security alert. If client did not send MD5 nor SHA-1
	hash algorithm in signature_algorithms extension and it receives a
	MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the
	connection with the illegal_parameter alert.
	5. Certificate Verify		5. Certificate Verify
	Clients MUST NOT include MD5 and SHA-1 in CertificateVerify message.		Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
	If the server receives a CertificateVerify message with MD5 or SHA-1		If a server receives a CertificateVerify message with MD5 or SHA-1 it
	it MUST abort the connection with handshake_failure or		MUST abort the connection with handshake_failure or
	insufficient_security alert.		insufficient_security alert.
	6. Updates to RFC5246		6. Updates to RFC5246
	RFC5246 [RFC5246], The Transport Layer Security (TLS) Protocol		RFC5246 [RFC5246], The Transport Layer Security (TLS) Protocol
	Version 1.2, suggests that implementations can assume support for MD5		Version 1.2, suggests that implementations can assume support for MD5
	and SHA-1 by their peer. This update changes the suggestion to		and SHA-1 by their peer. This update changes the suggestion to
	assume support for SHA-256 instead, due to MD5 and SHA-1 being		assume support for SHA-256 instead, due to MD5 and SHA-1 being
	deprecated.		deprecated.
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	[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>.
	[SHA-1-Collision]		[SHA-1-Collision]
	Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,		Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,
	and Y. Markov, "The first collision for full SHA-1", March		and Y. Markov, "The first collision for full SHA-1", March
	2019, <http://shattered.io/static/shattered.pdf>.		2019, <http://shattered.io/static/shattered.pdf>.
			[Transcript-Collision]
			Bhargavan, K. and G. Leurent, "Transcript Collision
			Attacks: Breaking Authentication in TLS, IKE, and SSH",
			February 2016, <https://www.mitls.org/downloads/
			transcript-collisions.pdf>.
	Authors' Addresses		Authors' Addresses
	Loganaden Velvindron		Loganaden Velvindron
	cyberstorm.mu		cyberstorm.mu
	Rose Hill		Rose Hill
	MU		MU
	Phone: +230 59762817		Phone: +230 59762817
	Email: logan@cyberstorm.mu		Email: logan@cyberstorm.mu
	Kathleen Moriarty		Kathleen Moriarty
	Dell EMC		Dell EMC
End of changes. 13 change blocks.
	25 lines changed or deleted		32 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/