<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"><!ENTITYRFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">nbsp " "> <!ENTITYRFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">zwsp "​"> <!ENTITYRFC6151 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6151.xml">nbhy "‑"> <!ENTITYRFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml"> <!ENTITY RFC8447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8447.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC ] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-tls-md5-sha1-deprecate-09" number="9155" ipr="trust200902"updates="5246"> <!-- category values: std, bcp, info, exp, and historic ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, or pre5378Trust200902 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->updates="5246" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--***** FRONT MATTER *****xml2rfc v2v3 conversion 3.10.0 --> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><titleabbrev="draft-ietf-tls-md5-sha1-deprecate">Deprecatingabbrev="Signature Hashes in (D)TLS 1.2">Deprecating MD5 and SHA-1signature hashesSignature Hashes in (D)TLS 1.2</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9155"/> <author fullname="Loganaden Velvindron"initials="L.V."initials="L." surname="Velvindron"> <organization>cyberstorm.mu</organization> <address> <postal><street></street> <!-- Reorder these if your country does things differently --><street/> <city>Rose Hill</city><region></region> <code></code><region/> <code/> <country>MU</country> </postal> <phone>+230 59762817</phone> <email>logan@cyberstorm.mu</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Kathleen Moriarty"initials="K.M." surname="Moriarty" >initials="K." surname="Moriarty"> <organization abbrev="CIS">Center for Internet Security</organization> <address> <postal> <street/> <city>East Greenbush</city> <region>NY</region> <country>United States of America</country> </postal> <email>Kathleen.Moriarty.ietf@gmail.com</email> </address> </author> <author fullname="Alessandro Ghedini"initials="A.G." surname="Ghedini" >initials="A." surname="Ghedini"> <organization>Cloudflare Inc.</organization> <address> <email>alessandro@cloudflare.com</email> </address> </author> <date year="2021"/> <!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. --> <!-- Meta-data Declarations -->month="December"/> <area>General</area> <workgroup>Internet Engineering Task Force</workgroup><!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. --><keyword>tls</keyword><!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --><abstract> <t> The MD5 and SHA-1 hashing algorithms are increasingly vulnerable toattackattack, and this document deprecates their use inTLS(D)TLS 1.2 digital signatures. However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used inHMAC forrecord protection. This document updates RFC 5246. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The usage of MD5 and SHA-1 for signature hashing inTLS(D)TLS 1.2 is specified in <xreftarget="RFC5246"/>.target="RFC5246" format="default"/>. MD5 and SHA-1 have been proven to be insecure, subject to collision attacks <xref target="Wang"/>.format="default"/>. In 2011, <xref target="RFC6151"/>format="default"/> detailed the security considerations, including collision attacks for MD5. NIST formally deprecated use of SHA-1 in 2011 <xref target="NISTSP800-131A-R2"/>format="default"/> and disallowed its use for digital signatures at the end of 2013, based on both theWang et al.attack described in <xref target="Wang" format="default"/> and the potential for brute-force attack. In 2016, researchers fromINRIAthe National Institute for Research in Digital Science and Technology (INRIA) identified a new class of transcript collision attacks on TLS (and other protocols) thatrelyrelies on efficient collision-finding algorithms on the underlying hash constructions <xref target="Transcript-Collision"/>.format="default"/>. Further, in 2017, researchers from Google andCWICentrum Wiskunde & Informatica (CWI) Amsterdam <xref target="SHA-1-Collision"/>format="default"/> proved SHA-1 collision attacks were practical. This document updates <xref target="RFC5246"/>format="default"/> in such a way that MD5 and SHA-1MUST NOT<bcp14>MUST NOT</bcp14> be used for digital signatures. However, this document does not deprecate SHA-1 with HMAC, as used inHMAC forrecord protection. Note that theCABFCA/Browser Forum (CABF) has also deprecated use of SHA-1 for use in certificate signatures <xreftarget="CABF"/>.target="CABF" format="default"/>. </t> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" />target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="Signature_algorithms"title="Signature Algorithms">numbered="true" toc="default"> <name>Signature Algorithms</name> <t> ClientsMUST<bcp14>MUST</bcp14> include the signature_algorithms extension. ClientsMUST NOT<bcp14>MUST NOT</bcp14> include MD5 and SHA-1 in this extension. </t> </section> <section anchor="cert_requests"title="Certificate Request">numbered="true" toc="default"> <name>Certificate Request</name> <t> ServersSHOULD NOT<bcp14>SHOULD NOT</bcp14> include MD5 and SHA-1 in CertificateRequest messages. </t> </section> <section anchor="serverkeyexchange"title="Servernumbered="true" toc="default"> <name>Server KeyExchange">Exchange</name> <t> ServersMUST NOT<bcp14>MUST NOT</bcp14> include MD5 and SHA-1 in ServerKeyExchange messages. If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then itMUST<bcp14>MUST</bcp14> abort the connection with an illegal_parameter alert. </t> </section> <section anchor="CertificateVerify"title="Certificate Verify">numbered="true" toc="default"> <name>Certificate Verify</name> <t> ClientsMUST NOT<bcp14>MUST NOT</bcp14> include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 orSHA-1SHA-1, itMUST<bcp14>MUST</bcp14> abort the connection with an illegal_parameter alert. </t> </section> <section anchor="IANA"title="IANA Considerations"> <t> The document updatesnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has updated the "TLS SignatureScheme" registryto changeby changing the recommended status ofSHA-1 basedSHA-1-based signature schemes toN"N" (notrecommended)recommended), as defined by <xreftarget="RFC8447"></xref>.target="RFC8447" format="default"/>. The following entriesare to be updated: </t> <texttable> <ttcol align='center'>Value</ttcol> <ttcol align='center'>Description</ttcol> <ttcol align='center'>Recommended</ttcol> <ttcol align='center'>Reference</ttcol> <c>0x0201</c> <c>rsa_pkcs1_sha1</c> <c>N</c> <c><xref target="RFC8446"></xref> [RFCTBD]</c> <c>0x0203</c> <c>ecdsa_sha1</c> <c>N</c><c><xref target="RFC8446"></xref> [RFCTBD]</c> </texttable> <t>Otherhave been updated; other entriesofin the registry remain the same. </t> <table align="center"> <thead> <tr> <th align="center">Value</th> <th align="center">Description</th> <th align="center">Recommended</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">0x0201</td> <td align="center">rsa_pkcs1_sha1</td> <td align="center">N</td> <td align="center"> <xref target="RFC8446" format="default"/> [RFC9155]</td> </tr> <tr> <td align="center">0x0203</td> <td align="center">ecdsa_sha1</td> <td align="center">N</td> <td align="center"> <xref target="RFC8446" format="default"/> [RFC9155]</td> </tr> </tbody> </table> <t> IANAishas alsorequested to updateupdated theReferencereference for theTLS SignatureAlgorithm"TLS SignatureAlgorithm" andTLS HashAlgorithm"TLS HashAlgorithm" registries to refer to thisRFC: </t> <t> OLD: </t> <t> Reference </t> <t> [RFC5246][RFC8447] </t> <t> NEW: </t> <t> Reference </t> <t> [RFC5246][RFC8447][RFC-to-be]document in addition to RFCs 5246 and 8447. </t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> Concerns withTLS(D)TLS 1.2 implementations falling back to SHA-1 is an issue. This document updates the TLS 1.2 specification <xref target="RFC5246" format="default"/> to deprecate support for MD5 and SHA-1 for digital signatures. However, this document does not deprecate SHA-1 with HMAC, as used inHMAC forrecord protection. </t> </section><section anchor="Acknowledgement" title="Acknowledgement"> <t> 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. </t> </section></middle><!-- *****BACK MATTER ***** --><back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> &RFC2119; &RFC5246; &RFC8174; &RFC8446; &RFC8447;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/> </references><references title="Informative References"> <!-- Here we use entities that we defined at the beginning. --> &RFC6151;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/> <reference anchor="NISTSP800-131A-R2" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf"> <front><title> Transitioning<title>Transitioning the Use of Cryptographic Algorithms and KeyLengths </title>Lengths</title> <authorinitials="E.B"initials="E." surname="Barker" fullname="Elaine Barker"><organization /><organization/> </author> <authorinitials="A.R"initials="A." surname="Roginsky" fullname="Allen Roginsky"><organization /><organization/> </author> <date month="March"year="2019" />year="2019"/> </front> <seriesInfo name="NIST Special Publication" value="800-131A, Revision 2"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/> </reference> <reference anchor="CABF" target="https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/"> <front><title> Ballot<title>Ballot 118 -- SHA-1 Sunset(passed) </title>(passed)</title> <author> <organization>CA/Browser Forum</organization> </author> <date year="2014"/>month="October"/> </front> </reference> <reference anchor="Transcript-Collision" target="https://hal.inria.fr/hal-01244855/document"> <front> <title> Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH </title> <authorinitials="K.B"initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan"><organization /><organization/> </author> <authorinitials="G.L"initials="G." surname="Leurent" fullname="Gaetan Leurent"><organization /><organization/> </author> <date month="February"year="2016" />year="2016"/> </front> <seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/> </reference> <reference anchor="SHA-1-Collision" target="https://eprint.iacr.org/2017/190"> <front><title> The first collision<title>The First Collision forfull SHA-1 </title>Full SHA-1</title> <authorinitials="M.S"initials="M." surname="Stevens" fullname="Marc Stevens"><organization /><organization/> </author> <authorinitials="E.B"initials="E." surname="Bursztein" fullname="Elie Bursztein"><organization /><organization/> </author> <authorinitials="P.K"initials="P." surname="Karpman" fullname="Pierre Karpman"><organization /><organization/> </author> <authorinitials="A.A"initials="A." surname="Albertini" fullname="Ange Albertini"><organization /><organization/> </author> <authorinitials="Y.M"initials="Y." surname="Markov" fullname="Yarik Markov"><organization /><organization/> </author> <datemonth="March" year="2019" />year="2017"/> </front> </reference> <reference anchor="Wang" target="https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf"> <front><title> Finding<title>Finding Collisions in the FullSHA-1 </title>SHA-1</title> <authorinitials="X.W"initials="X." surname="Wang" fullname="Xiaoyun Wang"><organization /><organization/> </author> <authorinitials="Y.Y"initials="Y." surname="Yin" fullname="Yiqun Lisa Yin"><organization /><organization/> </author> <authorinitials="H.Y"initials="H." surname="Yu" fullname="Hongbo Yu"><organization /><organization/> </author> <dateyear="2005" />year="2005"/> </front> <seriesInfo name="DOI" value="10.1007/11535218_2"/> </reference> </references><!-- Change Log --></references> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t> The authors would like to thank <contact fullname="Hubert Kario"/> for his help in writing the initial draft version of this document. We are also grateful to <contact fullname="Daniel Migault"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Sean Turner"/>, <contact fullname="Christopher Wood"/>, and <contact fullname="David Cooper"/> for their feedback. </t> </section> </back> </rfc>