Server-Led Algorithm Preference in the Secure Shell (SSH) Protocol
draft-bider-ssh-server-algs-00

Internet Engineering Task Force                                 D. Bider
Internet-Draft                                           Bitvise Limited
Intended status: Informational                           24 October 2026
Expires: 27 April 2027

   Server-Led Algorithm Preference in the Secure Shell (SSH) Protocol
                     draft-bider-ssh-server-algs-00

Abstract

   This document specifies an optional extension to Secure Shell (SSH)
   algorithm negotiation.  A client and server can agree, through
   indicators in their SSH_MSG_KEXINIT messages, to use the server's
   algorithm preference order in place of the client's preference order.
   Agreement for one key exchange round does not carry forward to
   another round.  Agreement governs bilateral algorithm negotiations in
   SSH_MSG_KEXINIT, as well as connection-wide extension mechanisms,
   including SSH_MSG_EXT_INFO delayed compression.

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.

Bider                     Expires 27 April 2027                 [Page 1]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Extension Negotiation . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Indicators  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Enabling Conditions . . . . . . . . . . . . . . . . . . .   4
   4.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . .   4
   5.  Scope and Lifetime  . . . . . . . . . . . . . . . . . . . . .   6
   6.  Server Host Key Algorithms  . . . . . . . . . . . . . . . . .   6
   7.  Algorithm Negotiation Outside SSH_MSG_KEXINIT . . . . . . . .   7
   8.  Guessed Key Exchange Packets  . . . . . . . . . . . . . . . .   8
   9.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   12. Existing Implementations  . . . . . . . . . . . . . . . . . .  10
   13. AI Disclosure . . . . . . . . . . . . . . . . . . . . . . . .  10
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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.

Bider                     Expires 27 April 2027                 [Page 2]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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

3.1.  Indicators

   A client willing to use this extension for a key exchange round MAY
   include the name "server-algs-c" in the kex_algorithms field of its
   SSH_MSG_KEXINIT message.

   A server willing to use this extension for a key exchange round MAY
   include the name "server-algs-s" in the kex_algorithms field of its
   SSH_MSG_KEXINIT message.

   Sending an indicator expresses agreement to use server preference for
   the algorithm lists in the current exchange if the peer sends its
   corresponding indicator.  In the initial exchange, this agreement
   also covers Section 7.  It is not merely an announcement that the
   implementation understands the extension.

Bider                     Expires 27 April 2027                 [Page 3]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   A client MUST NOT send "server-algs-s", and a server MUST NOT send
   "server-algs-c".  An implementation MAY disconnect upon receiving an
   indicator that is incorrect for the peer's role.  An incorrect
   indicator does not satisfy either enabling condition in Section 3.2.

   The indicators are name-list entries, without quotation marks.  Their
   position does not affect whether this extension is enabled.
   Implementations MUST recognize the appropriate indicator at ANY
   POSITION in the peer's kex_algorithms list.  Implementations MUST
   accept any ordering relative to other indicators which are not key
   exchange method names, such as "ext-info-c" and "ext-info-s"
   ([RFC8308]).  This draft recommends that senders place their
   indicator after all actual key exchange method names; and before
   "ext-info-c" or "ext-info-s", if one is present.

   Neither indicator identifies a key exchange method.  Implementations
   MUST NOT select either indicator as a key exchange method or use
   either indicator as the method of a guessed key exchange packet.

3.2.  Enabling Conditions

   This extension is enabled for a key exchange round if and only if
   both of the following conditions hold:

   1.  The client's SSH_MSG_KEXINIT for that round contains "server-
       algs-c" in kex_algorithms.

   2.  The server's SSH_MSG_KEXINIT for that round contains "server-
       algs-s" in kex_algorithms.

   When both conditions hold, both peers MUST use the selection rule in
   Section 4.  Otherwise, this extension is not enabled and MUST NOT
   change the negotiation rules for that round.

   Only the two SSH_MSG_KEXINIT messages belonging to the current round
   are considered.  An indicator sent in another round, knowledge of the
   peer's implementation, or cached knowledge of the peer's capabilities
   MUST NOT substitute for either enabling condition.

   Neither peer needs to wait for the other's SSH_MSG_KEXINIT before
   deciding whether to include its indicator.

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:

Bider                     Expires 27 April 2027                 [Page 4]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

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

Bider                     Expires 27 April 2027                 [Page 5]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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

Bider                     Expires 27 April 2027                 [Page 6]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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.

Bider                     Expires 27 April 2027                 [Page 7]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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

Bider                     Expires 27 April 2027                 [Page 8]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

   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.

Bider                     Expires 27 April 2027                 [Page 9]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

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

      +===============+===========+=====================+===========+
      | Method Name   | Reference | Note                | OK to     |
      |               |           |                     | Implement |
      +===============+===========+=====================+===========+
      | server-algs-c | This      | Client negotiation  | MAY       |
      |               | document  | indicator; not a    |           |
      |               |           | key exchange method |           |
      +---------------+-----------+---------------------+-----------+
      | server-algs-s | This      | Server negotiation  | MAY       |
      |               | document  | indicator; not a    |           |
      |               |           | key exchange method |           |
      +---------------+-----------+---------------------+-----------+

              Table 1: Server Algorithm Preference Indicators

   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.

14.  References

Bider                     Expires 27 April 2027                [Page 10]
Internet-Draft     SSH Server-Led Algorithm Preference      October 2026

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8308]  Bider, D., "Extension Negotiation in the Secure Shell
              (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
              2018, <https://www.rfc-editor.org/info/rfc8308>.

14.2.  Informative References

   [RFC9519]  Yee, P., "Update to the IANA SSH Protocol Parameters
              Registry Requirements", RFC 9519, DOI 10.17487/RFC9519,
              January 2024, <https://www.rfc-editor.org/info/rfc9519>.

   [RFC9644]  Watsen, K., "YANG Groupings for SSH Clients and SSH
              Servers", RFC 9644, DOI 10.17487/RFC9644, October 2024,
              <https://www.rfc-editor.org/info/rfc9644>.

Author's Address

   Denis Bider
   Bitvise Limited
   4105 Lombardy Court
   Colleyville, TX 76034
   United States of America
   Email: d-serveralgs00@bider.us
   URI:   https://bitvise.com/

Bider                     Expires 27 April 2027                [Page 11]