Change:
I didn't add a -08 version of the doc (datatracker keeps that history), and this keeps the diff smaller. cc NAME NAME
Should we remove the 7525 text now that 7525bis is underway.
Could you also: remove the reference to 7525 on line 14 drop 7525 from line 45, i.e., change the header. This I-D will no longer update the 7525. drop "and RFC 7525" line 137. drop "and " from line 158 Like

Discussion:
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC <del> for record protection.  This document updates RFC 5246 and RFC 7525. </del> <ins> for record protection.  This document updates RFC 5246. </ins> 1.

on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision <del> attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  Note that the CABF has also deprecated use of SHA-1 CABF. </del> <ins> attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. Note that the CABF has also deprecated use of SHA-1 CABF. </ins> 1.1.

7. <del> 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. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be

[RFC5246][RFC8447][RFC-to-be] <del> 9. </del> <ins> 8. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 10. </del> <ins> 9. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin