proposal: crypto/tls: allow configurability of supported Signature Hash Algorithms

[e3b0c442]

Go up to and including the current version (at this writing, 1.11.2) hardcodes the list of supported algorithms for the TLS 1.2 Signature Algorithms extension. Concurrently, crypto/tls also allows the use of custom signers which may have their own limitations not addressed by the hardcoded list of supported algorithms.

One real-world example of this is a custom signer for a TLS client that uses a hardware backend such as a Trusted Platform Module. TPM 1.2 modules can only support SHA1, and while TPM 2.0 modules can support SHA512, they are only required under the current spec to support SHA1 and SHA256. Depending on the list of algorithms provided by the remote party, the Go implementation may choose a 384-bit or 512-bit algorithm that is not supported by the backing hardware module, causing the handshake to fail.

In order to address this, I propose adding a configuration option to tls.Config to allow a custom list of supported signature algorithms to be provided, which will allow custom signer implementations to express the algorithms they support.

[FiloSottile]

This sounds like it would be more cleanly addressed by an interface upgrade on crypto.Signer allowing it to communicate which ones it supports, than by yet another tls.Config switch. Moreover, this is a property of the selected certificate, not of the system as a whole (forcing the use of GetConfigForClient.

Happy to consider this for Go 1.13. Go 1.12 is now in feature freeze.

[e3b0c442]

While I understand the line of thinking, I'm not sure tying this directly to crypto.Signer is the best option.

In order to query the crypto.Signer, there would need to exist some set of values to define the algorithms the crypto.Signer supports. While such a list exists in crypto/tls, I see two problems co-opting that for the crypto.Signer:

1. crypto.Signer is more generalized and can be used in contexts not related to TLS, so one would not want crypto.Signer to refer to crypto/tls for a list of allowable values.

2. Given that crypto.Signer can be an arbitrary implementation, I'm not sure it is possible or advisable to try to enumerate the parameters needed for the TLS implementation to determine a list of supported algorithms.

Given these points, I believe it makes the most sense to define this selection in the crypto/tls package somehow. That said, there is another option that satisfies keeping the selection in crypto/tls while not further complicating tls.Config: adding the field to tls.Certificate. This ties the algorithm selection to the crypto.Signer while not encumbering crypto.Signer with TLS knowledge, while at the same not adding additional fields to tls.Config and recognizing that the limitations are with the private key signer and not with the client itself.

[efb2]

Curious, has this been looked at since the proposal? It is a practical limitation since many TPM2 implementations do not implement SHA384/512.
It doesn't seem like it, but are there any workarounds aside from modifying crypto/tls.

[FiloSottile]

I like the idea of adding SupportedSignatureAlgorithms to tls.Certificate. The constants are already exposed, so it should be fairly unobtrusive, and it also lets TLS 1.2 clients opt out of RSA-PSS.

Approving for Go 1.14.