On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rs...@akamai.com> wrote: > > This is the working group last call for the "Deprecating MD5 and > SHA-1 signature hashes in TLS 1.2" draft available > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > Please review the document and send your comments to the list by 2359 UTC > on 13 December 2019. > > I just re-read this. Looks good. Perhaps a sentence of rationale in > section 2 and 3 explaining why its SHOULD NOT and not MUST NOT would help > explain things to some? >
To that end, the combination of client advice in sections 2 and 4 is a bit odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would the client include it in that case? It seems the two should either both be MUST NOT or both be SHOULD NOT. I think client-sent alerts in section 4 are also wrong. handshake_failure means the sender was unable to negotiate parameters, and insufficient_security is a variant of handshake_failure. This is the client reacting to the server sending something inconsistent with the ClientHello, so it should be illegal_parameter. In the context of ServerKeyExchange signatures, handshake_failure or insufficient_security would be sent by the *server* if the *client* only advertised MD5 and SHA-1. (In principle the client rules in section 4 are redundant with the text in section 2. It's just a restatement of negotiation requirements: your advertisement to the peer should match how you react to the peer's selection. But it's nice to write it explicitly and the document is not very long.) Some additional nitpicks: This document mostly writes "SHA-1", but the introduction has an instance of "SHA1". Section 2 should probably have a "the" before the first occurrence of "signature_algorithms extension". Section 4 includes both server behavior and the client restatement of negotiation requirements above, but section 5 does not include the corresponding server restatement of negotiation requirements. Otherwise, the document looks good to me.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
