< draft-ietf-tls-md5-sha1-deprecate-07.txt		draft-ietf-tls-md5-sha1-deprecate-08.txt >
	Internet Engineering Task Force L. Velvindron		Internet Engineering Task Force L.V. Velvindron
	Internet-Draft cyberstorm.mu		Internet-Draft cyberstorm.mu
	Updates: 5246 7525 (if approved) K. Moriarty		Updates: 5246 (if approved) K.M. Moriarty
	Intended status: Standards Track Dell Technologies		Intended status: Standards Track CIS
	Expires: November 18, 2021 A. Ghedini		Expires: 7 March 2022 A.G. Ghedini
	Cloudflare Inc.		Cloudflare Inc.
	May 17, 2021		3 September 2021
	Deprecating MD5 and SHA-1 signature hashes in TLS 1.2		Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2
	draft-ietf-tls-md5-sha1-deprecate-07		draft-ietf-tls-md5-sha1-deprecate-08
	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.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 18, 2021.		This Internet-Draft will expire on 7 March 2022.
	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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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 . . . . . . . . . . . . . . . . . . 3
	2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 3		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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	7. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 4		7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 5		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5		9.1. Normative References . . . . . . . . . . . . . . . . . . 4
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		9.2. Informative References . . . . . . . . . . . . . . . . . 5
	11.1. Normative References . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	11.2. Informative References . . . . . . . . . . . . . . . . . 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] in such a way that MD5 and SHA-1 MUST
	and SHA-1 MUST NOT be used for digital signatures. However, this		NOT be used for digital signatures. However, this document does not
	document does not deprecate SHA-1 in HMAC for record protection.		deprecate SHA-1 in HMAC for record protection. Note that the CABF
	Note that the CABF has also deprecated use of SHA-1 [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
	Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms		Clients MUST include the signature_algorithms extension. Clients
	extension. If a client does not send a signature_algorithms		MUST NOT include MD5 and SHA-1 in this extension.
	extension, then the server MUST abort the handshake and send a
	handshake_failure alert, except when digital signatures are not used
	(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
	messages.		messages.
	4. Server Key Exchange		4. Server Key Exchange
	Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.		Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
	If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange		If no other signature algorithms are available (for example, if the
	message it MUST abort the connection with the illegal_parameter		client does not send a signature_algorithms extension), the server
	alert.		MUST abort the handshake with a handshake_failure alert or select a
			different cipher suite.
	5. Certificate Verify		5. Certificate Verify
	Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.		Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
	If a server receives a CertificateVerify message with MD5 or SHA-1 it		If a server receives a CertificateVerify message with MD5 or SHA-1 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. IANA Considerations
	[RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
	suggests that implementations can assume support for MD5 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 deprecated.
	In Section 7.4.1.4.1: the text should be revised from:
	OLD:
	"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
	supports MD5 and SHA- 1."
	NEW:
	"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
	supports SHA-256."
	7. Updates to RFC7525
	[RFC7525], Recommendations for Secure Use of Transport Layer Security
	(TLS) and Datagram Transport Layer Security (DTLS), recommends use of
	SHA-256 as a minimum requirement. This update moves the minimum
	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
	this text adds guidance to ensure that these algorithms have been
	deprecated.
	Section 4.3:
	OLD:
	When using RSA, servers SHOULD authenticate using certificates with
	at least a 2048-bit modulus for the public key. In addition, the use
	of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
	more details). Clients SHOULD indicate to servers that they request
	SHA-256, by using the "Signature Algorithms" extension defined in TLS
	1.2.
	NEW:
	Servers SHOULD authenticate using certificates with at least a
	2048-bit modulus for the public key.
	In addition, the use of the SHA-256 hash algorithm is RECOMMENDED;
	and SHA-1 or MD5 MUST NOT be used (see [CAB-Baseline] for more
	details). Clients MUST indicate to servers that they request SHA-
	256, by using the "Signature Algorithms" extension defined in TLS
	1.2.
	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] |
	+--------+----------------+-------------+--------------------+		+--------+----------------+-------------+--------------------+
			Table 1
	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		IANA is also requested to update the Reference for the TLS
	SignatureAlgorithm and TLS HashAlgorithm registries to refer to this		SignatureAlgorithm and TLS HashAlgorithm registries to refer to this
	RFC:		RFC:
	OLD:		OLD:
	Reference		Reference
	[RFC5246][RFC8447]		[RFC5246][RFC8447]
	NEW:		NEW:
	Reference		Reference
	[RFC5246][RFC8447][RFC-to-be]		[RFC5246][RFC8447][RFC-to-be]
	9. Security Considerations		7. 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		8. 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, Sean Turner, Christopher Wood and David Cooper for their		Thomson, Sean Turner, Christopher Wood and David Cooper for their
	feedback.		feedback.
	11. References		9. References
	11.1. Normative References		9.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>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS		[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	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		9.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)",		[CABF] CA/Browser Forum, "Ballot 118 -- SHA-1 Sunset (passed)",
	2014, <https://cabforum.org/2014/10/16/ballot-118-sha-		2014, <https://cabforum.org/2014/10/16/ballot-118-sha-
	1-sunset/>.		1-sunset/>.
	[NISTSP800-131A-R2]		[NISTSP800-131A-R2]
	Barker, E. and A. Roginsky, "Transitioning the Use of		Barker, E.B. and A.R. 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>.
	[SHA-1-Collision]		[SHA-1-Collision]
	Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,		Stevens, M.S., Bursztein, E.B., Karpman, P.K., Albertini,
	and Y. Markov, "The first collision for full SHA-1", March		A.A., and Y.M. Markov, "The first collision for full SHA-
	2019, <http://shattered.io/static/shattered.pdf>.		1", March 2019, <https://eprint.iacr.org/2017/190>.
	[Transcript-Collision]		[Transcript-Collision]
	Bhargavan, K. and G. Leurent, "Transcript Collision		Bhargavan, K.B. and G.L. Leurent, "Transcript Collision
	Attacks: Breaking Authentication in TLS, IKE, and SSH",		Attacks: Breaking Authentication in TLS, IKE, and SSH",
	February 2016, <https://www.mitls.org/downloads/		February 2016,
	transcript-collisions.pdf>.		<https://hal.inria.fr/hal-01244855/document>.
	[Wang] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the		[Wang] Wang, X.W., Yin, Y.Y., and H.Y. Yu, "Finding Collisions in
	Full SHA-1", 2005.		the Full SHA-1", 2005, <https://www.iacr.org/archive/
			crypto2005/36210017/36210017.pdf>.
	Authors' Addresses		Authors' Addresses
	Loganaden Velvindron		Loganaden Velvindron
	cyberstorm.mu		cyberstorm.mu
	Rose Hill		Rose Hill
	MU		Mauritius
	Phone: +230 59762817		Phone: +230 59762817
	Email: logan@cyberstorm.mu		Email: logan@cyberstorm.mu
	Kathleen Moriarty		Kathleen Moriarty
	Dell Technologies		Center for Interent Security
			East Greenbush, NY
			United States of America
	Email: Kathleen.Moriarty.ietf@gmail.com		Email: Kathleen.Moriarty.ietf@gmail.com
	Alessandro Ghedini		Alessandro Ghedini
	Cloudflare Inc.		Cloudflare Inc.
	Email: alessandro@cloudflare.com		Email: alessandro@cloudflare.com
End of changes. 30 change blocks.
	117 lines changed or deleted		59 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/