https://bugzilla.mindrot.org/show_bug.cgi?id=3861
Darren Tucker <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Darren Tucker <[email protected]> --- (In reply to Barry Nelson from comment #0) > ## Rationale for Maintaining DSS Key Support in OpenSSH Clients > > **Document Version:** 1.0 > **Date:** 2025-09-08 > **Audience:** OpenSSH Developers, Security Engineers, System > Administrators > > **1. Executive Summary** > > The proposal to remove support for Digital Signature Standard (DSS) > keys in OpenSSH clients has raised concerns regarding accessibility > and compatibility. While DSS is considered cryptographically weak by > modern standards, outright removal poses significant risks to users > and systems that still rely on it. This document outlines the > rationale for retaining DSS support, balances the security concerns > with practical considerations, and proposes a phased deprecation > strategy instead of immediate removal. The deprecation *was* phased. It's been disabled by default at run time since version 7.0 (2015), the removal has been warned in the release notes a year prior to removal (version 9.7, 2024-03-11) then again in version 9.8 (2024-07-01), then it required explicit enabling at compile time six months prior to removal (9.9, 2024-09-19) then finally removed in 10.0 (2025-04-09). You can see these all here: https://www.openssh.com/releasenotes.html. Quoting the 9.7 release notes (2024-03-11): Future deprecation notice ========================= OpenSSH plans to remove support for the DSA signature algorithm in early 2025 and compile-time disable it later this year. DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest. Its estimated security level is only 80 bits symmetric equivalent. OpenSSH has disabled DSA keys by default since 2015 but has retained run-time optional support for them. DSA was the only mandatory-to- implement algorithm in the SSHv2 RFCs[3], mostly because alternative algorithms were encumbered by patents when the SSHv2 protocol was specified. This has not been the case for decades at this point and better algorithms are well supported by all actively-maintained SSH implementations. We do not consider the costs of maintaining DSA in OpenSSH to be justified and hope that removing it from OpenSSH can accelerate its wider deprecation in supporting cryptography libraries. This release makes DSA support in OpenSSH compile-time optional, defaulting to on. We intend the next release to change the default to disable DSA at compile time. The first OpenSSH release of 2025 will remove DSA support entirely. > * **Compatibility with Legacy Systems:** A substantial number of > legacy systems The previous versions of the client don't magically cease to exist. These legacy versions of OpenSSH can be used to connect to those legacy systems. Debian, for example, has openssh-client-ssh1 which supports both ssh-dss and SSH1. > * **User Migration Time:** Forcing a migration away from DSS > requires a substantial investment of time and resources for > individual users and organizations. A sudden removal of client > support would disrupt workflows and potentially create accessibility > barriers. Gradual deprecation allows for a more controlled > transition. The gradual deprecation started in 2015. Users had a literal decade. [...] > [...] Restrict the supported hashing > algorithms used with DSS keys to SHA-256 or better, to mitigate the > vulnerability associated with SHA-1. ssh-dss is only specified with SHA-1 (RFC4253 section 6.6). What you are proposing is an entirely new public-key authentication method. We already have public-key authentication methods that are both better than ssh-dss and already widely deployed. > * **Documentation:** Provide comprehensive documentation detailing > the risks associated with DSS and outlining best practices for > migration to stronger key types. People don't seem to read the documentation we already provide so I don't see how that would make any difference. > * **Monitoring & Reporting:** Implement monitoring and reporting > to track the usage of DSS keys, which can inform the timeline for > further deprecation steps. Stock OpenSSH code has no kind of telemetry that would allow this type of monitoring. > **5. Conclusion** [...] > Client-side DSS support [...] should be actively discouraged It's extremely actively discouraged. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
