[Bug 3861] The build option --enable-dsa-keys no longer works.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(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.