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

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3861
           Summary: The build option --enable-dsa-keys no longer works.
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: ix86
                OS: All
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Build system
          Assignee: unassigned-bugs at mindrot.org
          Reporter: barry.nelson at amobiledevice.com

## 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.

**2. Background: DSS and its Current Status**

DSS was a widely adopted standard for digital signatures, particularly
in government and enterprise environments, during the 1990s.  Its
primary weaknesses are its use of SHA-1 hashing algorithm and the
relatively short key lengths available (typically 1024 bits).  Modern
cryptographic standards like ECDSA and Ed25519 offer substantially
improved security and performance. However, a complete and immediate
transition away from DSS remains impractical.

**3. Arguments for Retaining DSS Support (Client-Side)**

*   **Compatibility with Legacy Systems:**  A substantial number of
legacy systems, particularly within government and enterprise
infrastructure, still utilize DSS for authentication. These systems may
be difficult or costly to upgrade or replace in the short term. 
Removing DSS support from the client would effectively prevent access
to these systems.  This would create significant operational
disruptions.
*   **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.
*   **Server-Side Considerations:**  While server-side DSS support
*should* be phased out aggressively, the timeline for this transition
is typically longer than that for the client due to the interconnected
nature of server infrastructure. Client removal should *follow* server
deprecation, not precede it.
*   **Minimal Client-Side Risk:** The client-side risk associated with
DSS support is comparatively low.  The primary vulnerabilities lie in
the server-side implementation of DSS and the algorithms used to
generate and verify DSS signatures. The client's role is primarily to
*verify* the signature, not to *generate* it. While a compromised
client could be used maliciously, this is a general risk applicable to
any supported key type.
*   **Continued Use in Embedded Systems**: DSS may still be used in
some
specialized embedded systems and devices for authentication.

**4. Proposed Mitigation Strategies & Phased Deprecation**

Rather than immediate removal, we propose a phased deprecation
approach:

*   **Warning Messages:** Introduce prominent warning messages in the
client when DSS keys are used, clearly indicating the known
cryptographic weaknesses.  These warnings should be visible to all
users, regardless of their technical expertise.
*   **Limited Algorithm Support:**  Restrict the supported hashing
algorithms used with DSS keys to SHA-256 or better, to mitigate the
vulnerability associated with SHA-1.
*   **Documentation:** Provide comprehensive documentation detailing
the risks associated with DSS and outlining best practices for
migration to stronger key types.
*    **Monitoring & Reporting:** Implement monitoring and reporting to
track the usage of DSS keys, which can inform the timeline for further
deprecation steps.

**5. Conclusion**

While DSS is a legacy standard, abruptly removing support for it in the
OpenSSH client would introduce significant operational and
accessibility
challenges.  A phased deprecation approach, combined with clear
warnings, continued monitoring, and support for stronger algorithms,
strikes a balance between security best practices and the practical
realities of a complex IT landscape.  Client-side DSS support should
remain, but its usage should be actively discouraged and closely
monitored.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.