Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[[e-mail] (Martin Rex)]

Eric Rescorla wrote:
> I'm not necessarily opposed to relaxing this requirement on the server,
> but given that:
> 
> 1. SHA-1 is on its way out.
> 2. Future versions of TLS seem very likely to explicitly indicate which
> hash algorithms the clients support.
> 
> I'm kind of confused about the principle being espoused here. In general,
> when the client has told the server what's acceptable and the server
> doesn't have it, we abort the handshake. What makes this case different
> from (say) the client only supporting P256 and the server only supporting
> Curve25519 but deciding to send Curve25519 anyway?

The choice of Curve25519 for an ECDHE_RSA or ECDHE_DSA key exchange is a
transform at the _TLS_ protocol level that a client's _TLS_ implementation
must support in order to perform the TLS handshake.

Algorithms for the signature on the server certifcate or signatures
higher up the certificate path conveyed by the server are

  -   *NOT* part of the TLS handshake, they're instead performed
      by what is usally a totally different software module (PKIX)
      from the TLS protocol implementation

  -   *NOT* predictable to be used to get used (and verified) by the
      client's certificate path validation function after whatever
      fancy "certificate path discovery" the client might be performing
      before validating the server's certificate.  The client might
      also be directly trusting the server's key (cert pinning,
      DANE usage 3 and other possibilities), where it is not clear
      whether the the signature on the certificate presented by the
      server needs to be verified at all.


So the difference here is HUGE.

Btw., TLSv1.2 implementations that do not support multiple server
certificates that differ only by algorithms, are probably skipping the
entire TLSv1.2 cert signature algorithms fandango and exhibit a highly
interoperable behaviour quite naturally.


-Martin