rfc9155.original   rfc9155.txt 
Internet Engineering Task Force L.V. Velvindron Internet Engineering Task Force (IETF) L. Velvindron
Internet-Draft cyberstorm.mu Request for Comments: 9155 cyberstorm.mu
Updates: 5246 (if approved) K.M. Moriarty Updates: 5246 K. Moriarty
Intended status: Standards Track CIS Category: Standards Track CIS
Expires: 24 March 2022 A.G. Ghedini ISSN: 2070-1721 A. Ghedini
Cloudflare Inc. Cloudflare Inc.
20 September 2021 December 2021
Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2 Deprecating MD5 and SHA-1 Signature Hashes in (D)TLS 1.2
draft-ietf-tls-md5-sha1-deprecate-09
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 (D)TLS 1.2 digital
signatures. However, this document does not deprecate SHA-1 in HMAC signatures. However, this document does not deprecate SHA-1 with
for record protection. This document updates RFC 5246. Hashed Message Authentication Code (HMAC), as used in 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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 March 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9155.
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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 3 2. Signature Algorithms
3. Certificate Request . . . . . . . . . . . . . . . . . . . . . 3 3. Certificate Request
4. Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 3 4. Server Key Exchange
5. Certificate Verify . . . . . . . . . . . . . . . . . . . . . 3 5. Certificate Verify
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses
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 (D)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 attack described in [Wang] and the
potential for brute-force attack. In 2016, researchers from INRIA potential for brute-force attack. In 2016, researchers from the
identified a new class of transcript collision attacks on TLS (and National Institute for Research in Digital Science and Technology
other protocols) that rely on efficient collision-finding algorithms (INRIA) identified a new class of transcript collision attacks on TLS
on the underlying hash constructions [Transcript-Collision]. (and other protocols) that relies on efficient collision-finding
Further, in 2017, researchers from Google and CWI Amsterdam algorithms on the underlying hash constructions
[SHA-1-Collision] proved SHA-1 collision attacks were practical. [Transcript-Collision]. Further, in 2017, researchers from Google
This document updates [RFC5246] in such a way that MD5 and SHA-1 MUST and Centrum Wiskunde & Informatica (CWI) Amsterdam [SHA-1-Collision]
NOT be used for digital signatures. However, this document does not proved SHA-1 collision attacks were practical. This document updates
deprecate SHA-1 in HMAC for record protection. Note that the CABF [RFC5246] in such a way that MD5 and SHA-1 MUST NOT be used for
has also deprecated use of SHA-1 for use in certificate signatures digital signatures. However, this document does not deprecate SHA-1
[CABF]. with HMAC, as used in record protection. Note that the CA/Browser
Forum (CABF) has also deprecated use of SHA-1 for use in certificate
signatures [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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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 include the signature_algorithms extension. Clients Clients MUST include the signature_algorithms extension. Clients
MUST NOT include MD5 and SHA-1 in this extension. MUST NOT include MD5 and SHA-1 in this extension.
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
skipping to change at page 3, line 33 skipping to change at line 116
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 the client receives a ServerKeyExchange message indicating MD5 or If the client receives a ServerKeyExchange message indicating MD5 or
SHA-1, then it MUST abort the connection with an illegal_parameter SHA-1, then it MUST abort the connection with an illegal_parameter
alert. alert.
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,
MUST abort the connection with an illegal_parameter alert. it MUST abort the connection with an illegal_parameter alert.
6. IANA Considerations 6. IANA Considerations
The document updates the "TLS SignatureScheme" registry to change the IANA has updated the "TLS SignatureScheme" registry by changing 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 have
be updated: been updated; other entries in the registry remain the same.
+========+================+=============+====================+
| Value | Description | Recommended | Reference |
+========+================+=============+====================+
| 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446] [RFCTBD] |
+--------+----------------+-------------+--------------------+
| 0x0203 | ecdsa_sha1 | N | [RFC8446] [RFCTBD] |
+--------+----------------+-------------+--------------------+
Table 1
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: +========+================+=============+=====================+
| Value | Description | Recommended | Reference |
+========+================+=============+=====================+
| 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446] [RFC9155] |
+--------+----------------+-------------+---------------------+
| 0x0203 | ecdsa_sha1 | N | [RFC8446] [RFC9155] |
+--------+----------------+-------------+---------------------+
Reference Table 1
[RFC5246][RFC8447][RFC-to-be] IANA has also updated the reference for the "TLS SignatureAlgorithm"
and "TLS HashAlgorithm" registries to refer to this document in
addition to RFCs 5246 and 8447.
7. Security Considerations 7. Security Considerations
Concerns with TLS 1.2 implementations falling back to SHA-1 is an Concerns with (D)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 [RFC5246] to
support for MD5 and SHA-1 for digital signatures. However, this deprecate support for MD5 and SHA-1 for digital signatures. However,
document does not deprecate SHA-1 in HMAC for record protection. this document does not deprecate SHA-1 with HMAC, as used in record
protection.
8. Acknowledgement
The authors would like to thank Hubert Kario for his help in writing
the initial draft. We are also grateful to Daniel Migault, Martin
Thomson, Sean Turner, Christopher Wood and David Cooper for their
feedback.
9. References 8. References
9.1. Normative References 8.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>.
skipping to change at page 5, line 17 skipping to change at line 174
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>.
9.2. Informative References 8.2. Informative References
[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- October 2014, <https://cabforum.org/2014/10/16/ballot-118-
1-sunset/>. sha-1-sunset/>.
[NISTSP800-131A-R2] [NISTSP800-131A-R2]
Barker, E.B. and A.R. 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", NIST Special
Publication 800-131A, Revision 2,
DOI 10.6028/NIST.SP.800-131Ar2, 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.S., Bursztein, E.B., Karpman, P.K., Albertini, Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,
A.A., and Y.M. Markov, "The first collision for full SHA- and Y. Markov, "The First Collision for Full SHA-1", 2017,
1", March 2019, <https://eprint.iacr.org/2017/190>. <https://eprint.iacr.org/2017/190>.
[Transcript-Collision] [Transcript-Collision]
Bhargavan, K.B. and G.L. Leurent, "Transcript Collision Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH", Attacks: Breaking Authentication in TLS, IKE, and SSH",
February 2016, DOI 10.14722/ndss.2016.23418, February 2016,
<https://hal.inria.fr/hal-01244855/document>. <https://hal.inria.fr/hal-01244855/document>.
[Wang] Wang, X.W., Yin, Y.Y., and H.Y. Yu, "Finding Collisions in [Wang] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
the Full SHA-1", 2005, <https://www.iacr.org/archive/ Full SHA-1", DOI 10.1007/11535218_2, 2005,
<https://www.iacr.org/archive/
crypto2005/36210017/36210017.pdf>. crypto2005/36210017/36210017.pdf>.
Acknowledgements
The authors would like to thank Hubert Kario for his help in writing
the initial draft version of this document. We are also grateful to
Daniel Migault, Martin Thomson, Sean Turner, Christopher Wood, and
David Cooper for their feedback.
Authors' Addresses Authors' Addresses
Loganaden Velvindron Loganaden Velvindron
cyberstorm.mu cyberstorm.mu
Rose Hill Rose Hill
Mauritius Mauritius
Phone: +230 59762817 Phone: +230 59762817
Email: logan@cyberstorm.mu Email: logan@cyberstorm.mu
Kathleen Moriarty Kathleen Moriarty
Center for Internet Security Center for Internet Security
 End of changes. 29 change blocks. 
114 lines changed or deleted 105 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/