Repository navigation
crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh #40337
Description
Activity
👋 from a fellow cryptography library maintainer who'd like to kill DSA.
Big ❤️ for go killing this! One less bad crypto system for users to accidentally use!
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.
Reacted by Nick SweetingAdding to minutes for first time this week, but seems like a likely accept next week.
The reactions above and discussion are clear.
This seems like a likely accept.No change in consensus, so accepted.
Reacted by Tom Thorogood, Komu Wairagu, Dave Cheney and Davis- changed the title
[-]proposal: crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh[/-][+]crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh[/+]on Aug 14, 2020 Change https://golang.org/cl/257939 mentions this issue:
crypto/dsa,crypto/x509: deprecate DSA and remove crypto/x509 support- added a commit that references this issue
on Oct 2, 2020 The crypto/dsa and crypto/x509 parts are landed, only x/crypto/ssh left.
Change https://golang.org/cl/274575 mentions this issue:
ssh: remove DSA supportIs it possible to disable DSA in 1.15.5, so we can check in advance if anything breaks?
@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.
cc @drakkan for the ssh part
DSA is an obsolete, fragile, insecure, and mostly unused signature scheme. I'm proposing that we deprecate (but not remove) the
crypto/dsapackage, recommending a modern alternative such ascrypto/ed25519, and drop support for DSA keys in thecrypto/x509andgolang.org/x/crypto/sshpackages.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.
I wrote more about this in a newsletter issue.
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
crypto/x509targets. Anecdotally, they are also not in use in any private PKI I am aware of. (This is obviously a hard assertion to substantiate.)crypto/x509is exposed to the world for most Go applications throughcrypto/tls, and supporting DSA is a liability in terms of attack surface, as proved by CVE-2019-17596.Also note that
crypto/tlsdoesn't itself support DSA certificates, so they already can't be used as website certificates, only as intermediate or root CAs.DSA and SSH
OpenSSH's
ssh-keygenonly ever supported insecure 1024-bit keys. 94% of the DSA keys on GitHub are 1024-bit. The golang.org/x/crypto/ssh package only supports 1024-bit keys. DSA as used in SSH is insecure.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
known_hostsfile.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!