Ballot for draft-ietf-tls-md5-sha1-deprecate
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Misspelling in author’s address: “Center for Interent Security” should be “ Center for Internet Security”.
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.
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