idnits 2.17.1 draft-lvelvindron-tls-md5-sha1-deprecate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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, SHA-1 or MD5 MUST not be used (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. (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 9, 2019) is 1785 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Velvindron 3 Internet-Draft cyberstorm.mu 4 Updates: 5246 7525 (if approved) K. Moriarty 5 Intended status: Standards Track Dell EMC 6 Expires: November 10, 2019 May 9, 2019 8 Deprecating MD5 and SHA1 in TLS 1.2 9 draft-lvelvindron-tls-md5-sha1-deprecate-03 11 Abstract 13 The MD5 and SHA1 hashing algorithms are steadily weakening in 14 strength and their deprecation process should begin for their use in 15 TLS 1.2 digital signatures. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 10, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 2 54 3. Certificate Requests . . . . . . . . . . . . . . . . . . . . 3 55 4. Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 3 56 5. Certificate Verify . . . . . . . . . . . . . . . . . . . . . 3 57 6. Updates to RFC5246 . . . . . . . . . . . . . . . . . . . . . 3 58 7. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 3 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 10.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The usage of MD5 and SHA1 for TLS 1.2 is specified RFC 5246 69 [RFC5246]. MD5 and SHA-1 have been proven to be insecure, subject to 70 collision attacks. RFC 6151 [RFC6151] details the security 71 considerations, including collision attacks for MD5, published in 72 2011. MD5 has been deprecated by NIST and is no longer mentioned in 73 publications such as [NISTSP800-131A-R2]. NIST formally deprecated 74 use of SHA-1 in 2011 [NISTSP800-131A-R2] and disallowed its use for 75 digital signatures at the end of 2013, based on both the Wang, et. 76 al, attack and the potential for brute-force attack. Further, in 77 2017, researchers from Google and CWI Amsterdam [SHA-1-Collision] 78 proved SHA-1 collision attacks were practical. This document updates 79 RFC 5246 [RFC5246] and RFC7525 [RFC7525] in such as way that MD5 and 80 SHA1 MUST NOT be used for digital signatures. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Signature Algorithms 90 Clients SHOULD NOT include md5 and SHA-1 in signature_algorithms 91 extension. If a client does not send a signature_algorithms 92 extension, then the server MUST abort the handshake and send a 93 handshake_failure alert. 95 3. Certificate Requests 97 Servers SHOULD NOT include md5 and SHA-1 in CertificateRequest 98 message. 100 4. Server Key Exchange 102 Servers MUST NOT include md5 and SHA-1 in ServerKeyExchange message. 103 If client does receive a MD5 or SHA-1 signature in the 104 ServerKeyExchange message it MUST abort the connection with 105 handshake_failure or insufficient_security alert. 107 5. Certificate Verify 109 Clients MUST NOT include md5 and SHA-1 in CertificateVerify message. 111 6. Updates to RFC5246 113 OLD: 115 In Section 7.4.1.4.1: the text should be revised from " enum { 116 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), 117 (255) } HashAlgorithm;" 119 NEW: 121 enum { none(0), sha224(3), sha256(4), sha384(5), sha512(6), (255) } 122 HashAlgorithm; 124 OLD: 126 In Section 7.4.1.4.1: the text should be revised from " Note: this is 127 a change from TLS 1.1 where there are no explicit rules, but as a 128 practical matter one can assume that the peer supports MD5 and SHA- 129 1." 131 NEW: 133 "Note: This is a change from TLS 1.1 where there are no explicit 134 rules, but as a practical matter one can assume that the peer 135 supports SHA-256." 137 7. Updates to RFC7525 139 RFC7525 [RFC7525], Recommendations for Secure Use of Transport Layer 140 Security (TLS) and Datagram Transport Layer Security (DTLS) 141 recommends use of SHA-256 as a minimum requirement. This update 142 moves the minimum recommendation to use stronger language deprecating 143 use of both SHA-1 and MD5. The prior text did not explicitly include 144 MD5 and this text adds it to ensure it is understood as having been 145 deprecated. 147 Section 4.3: 149 OLD: 151 When using RSA, servers SHOULD authenticate using certificates with 152 at least a 2048-bit modulus for the public key. In addition, the use 153 of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for 154 more details). Clients SHOULD indicate to servers that they request 155 SHA-256, by using the "Signature Algorithms" extension defined in TLS 156 1.2. 158 NEW: 160 When using RSA, servers SHOULD authenticate using certificates with 161 at least a 2048-bit modulus for the public key. In addition, the use 162 of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST not 163 be used (see [CAB-Baseline] for more details). Clients SHOULD 164 indicate to servers that they request SHA-256, by using the 165 "Signature Algorithms" extension defined in TLS 1.2. 167 8. Security Considerations 169 Concerns with TLS 1.2 implementations falling back to SHA-1 is an 170 issue. This draft updates the TLS 1.2 specification to deprecate 171 support for MD5 and SHA-1 for digital signatures. 173 9. Acknowledgement 175 The authors would like to thank Hubert Kario for his help in writing 176 the initial draft. 178 10. References 180 10.1. Normative References 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, 184 DOI 10.17487/RFC2119, March 1997, 185 . 187 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 188 "Recommendations for Secure Use of Transport Layer 189 Security (TLS) and Datagram Transport Layer Security 190 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 191 2015, . 193 10.2. Informative References 195 [CAB-Baseline] 196 CA/Browser Forum, "Baseline Requirements for the Issuance 197 and Management of Publicly-Trusted Certificates Version 198 1.1.6", 2013, . 200 [NISTSP800-131A-R2] 201 Barker, E. and A. Roginsky, "Transitioning the Use of 202 Cryptographic Algorithms and Key Lengths", March 2019, 203 . 206 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 207 (TLS) Protocol Version 1.2", RFC 5246, 208 DOI 10.17487/RFC5246, August 2008, 209 . 211 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 212 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 213 RFC 6151, DOI 10.17487/RFC6151, March 2011, 214 . 216 [SHA-1-Collision] 217 Stevens, M., Bursztein, E., Karpman, P., Albertini, A., 218 and Y. Markov, "The first collision for full SHA-1", March 219 2019, . 221 Authors' Addresses 223 Loganaden Velvindron 224 cyberstorm.mu 225 Rose Hill 226 MU 228 Phone: +230 59762817 229 Email: logan@cyberstorm.mu 231 Kathleen Moriarty 232 Dell EMC