crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh #40337
DSA is an obsolete, fragile, insecure, and mostly unused signature scheme. I'm proposing that we deprecate (but not remove) the
The problem with DSA
First, DSA suffers of what we now know is a design mistake: it requires each key to bring along its own parameters, instead of setting globally accepted ones. Parameters are slow to generate, large to encode, and most importantly very hard to validate. This caused a remote DoS in Go 1.13 (CVE-2019-17596, #34960) exploitable through both TLS and SSH.
Second, DSA was initially standardized with a max key size of 1024 bits, which is now universally acknowledged as insecure against real-world attackers. While larger key sizes were standardized years later, by then it made no sense to use DSA in new systems anymore, so the systems that kept using DSA did it for backwards compatibility and didn't adopt larger keys. It's also been almost 20 years.
DSA and X.509
The Mozilla Root Store policy rejects DSA keys in X.509 certificates, so they are completely absent from the WebPKI, which is what
Also note that
DSA and SSH
There is reason to think removing DSA support will actually help compatibility, by preferring other key types and avoiding connection failures for key sizes other than 1024-bit (#23751). OpenSSH 7.0 disabled DSA support in 2015. Dropping DSA support will also help align the host keys observed by x/crypto/ssh with the ones in an OpenSSH
Edited to add: NIST is deprecating DSA
DSA is specified in FIPS 186 by NIST. The draft of the next version of the specification, FIPS 186-5, removes all text about DSA except for a paragraph stating that DSA may only be used to verify existing legacy signatures. We risk being behind the FIPS standards!
The text was updated successfully, but these errors were encountered:
One idea which may or may not be of interest to you, is to deprecate key generation and signing on a different timeline than signature verification. This potentially allows supporting backwards compatibility use cases without making the situation any worse.
As another cryptographic library maintainer, I agree that deprecation is a good path. There exist a small set of people sshing with 512-bit DSA keys to managed switches, but there are various reasonable ways for those users to solve their problems without having modern cryptography libraries carry the maintenance burden and security risk.
Updates #40337 Change-Id: I5c1218df3ae7e13144a1d9f7d4a4b456e4475c0a Reviewed-on: https://go-review.googlesource.com/c/go/+/257939 Trust: Filippo Valsorda <firstname.lastname@example.org> Trust: Roland Shoemaker <email@example.com> Reviewed-by: Roland Shoemaker <firstname.lastname@example.org> Reviewed-by: Katie Hockman <email@example.com>
@jech there is no way other than checking the public key type of all X.509 certificates in verified chains you are using (as the only behavioral change is in crypto/x509). As with most changes, the way to check for breakage would be to run the Go 1.16 beta or release candidate.