| < draft-ietf-tls-md5-sha1-deprecate-00.txt | draft-ietf-tls-md5-sha1-deprecate-01.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: March 5, 2020 A. Ghedini | Expires: July 19, 2020 A. Ghedini | |||
| Cloudflare Inc. | Cloudflare Inc. | |||
| September 2, 2019 | January 16, 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-00 | draft-ietf-tls-md5-sha1-deprecate-01 | |||
| 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 March 5, 2020. | This Internet-Draft will expire on July 19, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 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 | |||
| skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
| 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 2 | 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 2 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . 3 | 7. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 | 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 4 | 10.2. Informative References . . . . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 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 | |||
| skipping to change at page 2, line 51 ¶ | skipping to change at page 3, line 4 ¶ | |||
| 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 signature_algorithms | Clients SHOULD NOT include MD5 and SHA-1 in 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. | 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 | |||
| message. | message. | |||
| 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 message. | |||
| If client does receive a MD5 or SHA-1 signature in the | If client does receive a MD5 or SHA-1 signature in the | |||
| skipping to change at page 5, line 39 ¶ | skipping to change at page 5, line 46 ¶ | |||
| 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 | |||
| Email: Kathleen.Moriarty.ietf@gmail.com | ||||
| Alessandro Ghedini | Alessandro Ghedini | |||
| Cloudflare Inc. | Cloudflare Inc. | |||
| Email: alessandro@cloudflare.com | ||||
| End of changes. 9 change blocks. | ||||
| 7 lines changed or deleted | 9 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/ | ||||