Disallow DSA/SHA1/etc. for pure TLS 1.3 ClientHellos
authorBenjamin Kaduk <bkaduk@akamai.com>
Mon, 24 Apr 2017 23:20:33 +0000 (18:20 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Sun, 25 Jun 2017 00:25:43 +0000 (19:25 -0500)
commit6ffeb269a325febb6f48130ad2178d6dfb893bd4
tree67b35ca597ef37095135994bf1f6ae1630a1763c
parenta163e60d950f5cbfa56778a10cc34c95681861f1
Disallow DSA/SHA1/etc. for pure TLS 1.3 ClientHellos

In draft-ietf-tls-tls13-20 Appendix B we find that:

   This section describes protocol types and constants.  Values listed
   as _RESERVED were used in previous versions of TLS and are listed
   here for completeness.  TLS 1.3 implementations MUST NOT send them
   but might receive them from older TLS implementations.

Similarly, in section 4.2.3 we see:

   Legacy algorithms  Indicates algorithms which are being deprecated
      because they use algorithms with known weaknesses, specifically
      SHA-1 which is used in this context with either with RSA using
      RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to
      signatures which appear in certificates (see Section 4.4.2.2) and
      are not defined for use in signed TLS handshake messages.
      Endpoints SHOULD NOT negotiate these algorithms but are permitted
      to do so solely for backward compatibility.  Clients offering
      these values MUST list them as the lowest priority (listed after
      all other algorithms in SignatureSchemeList).  TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

However, we are currently sending the SHA2-based DSA signature schemes
and many SHA1-based schemes, which is in contradiction with the specification.

Because TLS 1.3 support will appear in OpenSSL 1.1, we are bound by
stability requirements to continue to offer the DSA signature schemes
and the deprecated hash algorithms.  at least until OpenSSL 1.2.
However, for pure TLS 1.3 clients that do not offer lower TLS versions,
we can be compliant.  Do so, and leave a note to revisit the issue when
we are permitted to break with sacred historical tradition.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3326)
ssl/t1_lib.c