Skip to main content

Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2
RFC 9155

Yes

Erik Kline
Francesca Palombini
Martin Duke
Murray Kucherawy
Robert Wilton
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

No Objection

Alvaro Retana
(Martin Vigoureux)

Note: This ballot was opened for revision 08 and is now closed.

Erik Kline Yes

Francesca Palombini Yes

Lars Eggert Yes

Comment (2021-09-20 for -08)
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 2, nit:
-    the end of 2013, based on both the Wang, et. al, attack and the
-                                               -
+    the end of 2013, based on both the Wang, et al., attack and the
+                                                  +

Uncited references: [CAB-Baseline]

Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose).

These URLs in the document did not return content:
 * https://www.cabforum.org/documents.html

Martin Duke Yes

Murray Kucherawy Yes

Robert Wilton Yes

Roman Danyliw Yes

Warren Kumari Yes

Zaheduzzaman Sarker Yes

Éric Vyncke Yes

Alvaro Retana No Objection

John Scudder No Objection

Comment (2021-09-17 for -08)
Misspelling in author’s address: “Center for Interent Security” should be “ Center for Internet Security”.

(Benjamin Kaduk; former steering group member) Yes

Yes (2021-09-16 for -08)
Section 1

   deprecate SHA-1 in HMAC for record protection.  Note that the CABF
   has also deprecated use of SHA-1 [CABF].

We might say that the CABF action was deprecation for use in certificate
signatures (not that CABF is likely to be concerned about other uses of
SHA1, of course).

Section 5

   Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
   If a server receives a CertificateVerify message with MD5 or SHA-1 it
   MUST abort the connection with handshake_failure or
   insufficient_security alert.

I don't see much harm in adding "illegal_parameter" to the list of
allowed alerts here, as Hubert proposed.  It's otherwise the natural
thing to do if an algorithm is received in CertificateVerify that was
not advertised in the signature algorithms extension.

Sean's proposal at
https://mailarchive.ietf.org/arch/msg/tls/rSbXvNPhmr27z0HOBzwv6x0j1mI/
(which makes "illegal_parameter" the only alert) seems like it ought to
work.

(Martin Vigoureux; former steering group member) No Objection

No Objection ()