On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rs...@akamai.com> wrote:
...
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 ...
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.
because it also influences certificate selection, and getting a certificate
signed with SHA-1 isn't an automatically disqualifying property?
(it may be an intermediate CA that's not used, it may be an explicitly
trusted
certificate, etc.)
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.
well, it depends if the SHA-1 was advertised by client or not
if it was advertised (because of certificates, see above), then
handshake_failure is correct; if it wasn't advertised but the
signature_algorithms were included, then yes, client should abort with
illegal_parameter
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
