Server-Led Algorithm Preference in the Secure Shell (SSH) Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SSH transport algorithm negotiation normally gives priority to the client's ordering of mutually supported algorithms [RFC4253]. A server can limit the algorithms it offers, but ordering its offer does not normally determine which mutually supported algorithm is selected.¶

This document defines an optional mechanism by which the client and server agree to use the server's preference order for a particular key exchange round. This permits a server to express preferences among its allowed algorithms without removing the alternatives from its offer. Where many clients connect to a server, this allows a server administrator to control algorithm preference at the server, instead of configuring many clients.¶

The mechanism uses role-specific indicators in the kex_algorithms field of SSH_MSG_KEXINIT. This signaling approach follows the precedent established by [RFC8308]. The mechanism defined here requires an indicator from both peers. It does not require SSH_MSG_EXT_INFO or either of the ext-info-c and ext-info-s indicators.¶

This extension changes algorithm preference and specifies related host key synchronization requirements. It does not define new cryptographic algorithms or add messages. Agreement in the initial exchange also governs the negotiations described in Section 7.¶

2. Conventions and Terminology

This document uses MUST, MUST NOT, SHOULD, and MAY as requirement terms with the meanings defined by BCP 14 ([RFC2119] and [RFC8174]). These meanings apply only to uppercase occurrences.¶

The name-list data type is defined in [RFC4251]. Field names in this document refer to the SSH_MSG_KEXINIT message defined in Section 7.1 of [RFC4253].¶

A key exchange round consists of the client's and server's corresponding SSH_MSG_KEXINIT messages and the key exchange performed using those messages. This includes both the initial key exchange and each subsequent key re-exchange.¶

The terms client and server retain their SSH connection roles. These roles do not depend on which peer initiates a key re-exchange or sends SSH_MSG_KEXINIT first.¶

3. Extension Negotiation

4. Algorithm Selection

When this extension is enabled, both peers MUST apply the algorithm negotiation procedure in Section 7.1 of [RFC4253] with the server's preference order replacing the client's preference order. This replacement applies to each of the following fields:¶

• kex_algorithms¶
• server_host_key_algorithms¶
• encryption_algorithms_client_to_server¶
• encryption_algorithms_server_to_client¶
• mac_algorithms_client_to_server¶
• mac_algorithms_server_to_client¶
• compression_algorithms_client_to_server¶
• compression_algorithms_server_to_client¶

Important considerations apply to server_host_key_algorithms: see Section 6.¶

Wherever the applicable negotiation procedure selects among mutually supported algorithms in client preference order, it MUST instead select in server preference order. For an independently negotiated list, this selects the first qualifying algorithm in the server's list that also occurs in the client's corresponding list.¶

All selection conditions other than preference order remain applicable. In particular, the requirements relating the key exchange method to available and acceptable server host-key algorithms remain applicable.¶

Algorithm-specific negotiation rules also remain applicable. These can constrain the combination of encryption and MAC algorithms or provide authentication without selecting a separate MAC algorithm. Server preference applies wherever the applicable procedure consults an algorithm list. It does not introduce a selection step that the procedure otherwise omits.¶

In particular, when an encryption algorithm's specification makes the MAC lists irrelevant, this extension MUST NOT cause a separate MAC selection or a negotiation failure merely because those lists have no common entry.¶

Changing preference order does not exchange client and server roles. The server still offers server host-key algorithms, and the client still states which server host-key algorithms it accepts. Directional fields retain their meanings: a client-to-server field is compared with the peer's client-to-server field, and likewise for server-to-client fields.¶

Existing negotiation failure rules remain applicable. A failure to select the required algorithms MUST NOT cause an implementation to retry the same negotiation using client preference while this extension is enabled.¶

The client continues to list its algorithms in its own preference order. That ordering is needed when this extension is not enabled and remains relevant to guessed-packet processing as described in Section 8.¶

5. Scope and Lifetime

For SSH_MSG_KEXINIT, the preference rule applies to the two messages for the current round. It does not affect the languages_client_to_server or languages_server_to_client fields.¶

Implementations MUST evaluate the enabling conditions anew for every key exchange round. Support or agreement in an earlier round does not carry forward. Either peer can omit its indicator in a later round, in which case this extension is not enabled for that later round.¶

Conversely, the extension MAY be enabled during a key re-exchange even if it was not enabled during the initial key exchange or the immediately preceding round.¶

The lifetime of the selection rule is distinct from the lifetime of the selected algorithms and keys. Algorithms and keys selected in a round are installed and remain in use according to the normal SSH rules. Completion of the round does not undo those selections.¶

The initial exchange determines the preference used by qualifying negotiations outside SSH_MSG_KEXINIT, as specified in Section 7. The host key synchronization requirements in Section 6 also have a connection-wide lifetime.¶

Except for the changes explicitly specified in this document, other SSH extensions retain their enabling conditions, interpretation, and lifetime.¶

6. Server Host Key Algorithms

A client that advertises "server-algs-c" and already has a basis for authenticating the server SHOULD exclude algorithms from its server_host_key_algorithms for which it has no such basis. This basis may be a trusted host key usable with the algorithm or, for a certificate algorithm, a trusted certification authority authorized to certify host keys for the server. This allows the server's preference to govern the selected host key and signature algorithm while limiting negotiation to algorithms for which the client already has a basis for authenticating the server.¶

This filtering does not replace verification of the host key or certificate actually presented by the server. An algorithm name does not identify an individual host key.¶

If the client's initial SSH_MSG_KEXINIT includes "server-algs-c", a server that recognizes this extension MUST NOT treat the client's server_host_key_algorithms lists as complete lists of supported host key algorithms, or use them to restrict the host keys published through a host key synchronization mechanism. This requirement applies for the rest of the connection, regardless of whether the server advertises "server-algs-s" or later client exchanges omit "server-algs-c".¶

If the client first advertises "server-algs-c" during a later key exchange, the server MAY adopt this behavior for the rest of the connection. The client MUST NOT assume that the server does so. The server is not required to repeat earlier host key synchronization advertisements.¶

Once a client advertises "server-algs-c" in any key exchange, it MUST NOT reject an otherwise valid host key synchronization advertisement solely because it includes keys using algorithms the client does not support or did not offer in server_host_key_algorithms. The client MAY ignore keys using unsupported algorithms or algorithms disallowed by local policy. Accepted keys remain subject to the synchronization mechanism's authentication and verification requirements. These client requirements apply for the rest of the connection, regardless of whether server preference was negotiated or either peer later omits its indicator.¶

7. Algorithm Negotiation Outside SSH_MSG_KEXINIT

This section applies to bilateral algorithm negotiations with a connection-wide effect in which each peer supplies an ordered name-list and the ordinary selection procedure chooses one qualifying common algorithm in client preference order, as in SSH_MSG_KEXINIT.¶

If both indicators were present in the initial key exchange, both peers MUST instead use server preference for such a negotiation. Otherwise, its ordinary preference rule applies. All other selection conditions remain unchanged. A specification defining such a negotiation MAY explicitly specify a different interaction with this extension.¶

This rule applies to both directional algorithm lists in "delay-compression" ([RFC8308]). The initial exchange governs this selection even if a later server SSH_MSG_EXT_INFO replaces its earlier advertisement. Subsequent key exchanges do not change this preference. The rules for activating delayed compression and replacing it with compression negotiated by a subsequent key exchange remain unchanged.¶

The rule does not apply to "server-sig-algs" ([RFC8308]), which advertises server capabilities for client public-key authentication rather than negotiating one algorithm from bilateral offers. Other lists that do not meet the conditions above also remain unaffected. Unrecognized extensions MUST continue to be ignored as required by their containing protocol.¶

8. Guessed Key Exchange Packets

This extension does not change the meaning of first_kex_packet_follows or the rules for accepting or discarding a guessed key exchange packet.¶

Under the rules in Section 7 of [RFC4253], differing first choices of key exchange method or server host-key algorithm still make a guess wrong. A guessed packet does not become acceptable merely because its method happens to equal the method selected using server preference.¶

Any separately negotiated extension that changes guessed-packet processing retains its own rules. Where those rules refer to the negotiated algorithms, they refer to the algorithms selected for the current round, including the effect of this extension when enabled.¶

A sender that sets first_kex_packet_follows to TRUE MUST place an actual key exchange method first in kex_algorithms. Placing the server preference indicator after the actual method names avoids interfering with this requirement.¶

9. Example

For one traffic direction, suppose the client and server advertise the following encryption algorithm lists. The names "cipher-a" and "cipher-b" are illustrative placeholders, and both algorithms are assumed to satisfy all other selection conditions.¶

Client: cipher-a,cipher-b
Server: cipher-b,cipher-a

If the client advertises "server-algs-c" and the server advertises "server-algs-s" in their respective kex_algorithms lists for this round, the selected encryption algorithm is "cipher-b".¶

If either indicator is absent, the selection remains "cipher-a" under the ordinary client preference rule.¶

If a subsequent round has the same encryption lists but only the server repeats its indicator, that subsequent round selects "cipher-a". The earlier agreement does not affect the subsequent selection.¶

10. Security Considerations

Server preference can select a different algorithm from the one that client preference would select. It does not establish that the selected algorithm is stronger, faster, or otherwise preferable for the client's purposes.¶

Each peer remains responsible for the algorithms it permits. A client that advertises "server-algs-c" agrees to let the server's ordering determine selection among the qualifying mutually supported algorithms. Algorithms that are unacceptable under the client's security policy must be excluded from its offer; placing them later in the list does not exclude their selection.¶

A client may order server host-key algorithms to favor a key it already trusts. Server preference can result in selection of a different host-key algorithm. This extension does not authorize acceptance of an untrusted server host key or relax server authentication requirements.¶

Implementations MUST preserve the complete, original SSH_MSG_KEXINIT payloads when those payloads are included in the key exchange's authenticated data. In particular, implementations MUST NOT remove these indicators or reorder name-lists in the authenticated representation when applying the selection rule.¶

Authentication of the key exchange transcript protects the indicators and advertised order in the same way as the other SSH_MSG_KEXINIT contents. This extension adds no separate authentication mechanism and does not replace the security requirements of the selected key exchange and transport algorithms.¶

11. IANA Considerations

The author acknowledges that current procedures for IANA SSH registry additions may require a threshold which this draft does not meet. This draft describes registry additions which would be requested if the required threshold was met.¶

IANA is requested to add the following entries to the "Key Exchange Method Names" registry within the "Secure Shell (SSH) Protocol Parameters" registry group. The existing Expert Review registration policy is specified in [RFC9519].¶

IANA is also requested to update the "iana-ssh-key-exchange-algs" YANG module to reflect these registrations, following Section 6.6 of [RFC9644].¶

This document does not request entries in the "Extension Names" registry and does not allocate an SSH message number.¶

12. Existing Implementations

This extension is being implemented in Bitvise SSH Server versions 9.67 and higher. The extension is initially intended for server-to-server connections, where it is desirable for a central server to govern algorithm preferences for other servers connecting as clients.¶

13. AI Disclosure

A recent, advanced Large Language Model was used at maximum effort settings to generate the initial version of this draft, and to revise it following review by the author.¶

Author's Address