<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     docName="draft-ietf-curdle-ssh-kex-sha2-20"
     updates="4250 4253 4432 4462"
     number="9142"
     ipr="trust200902"
     updates="4250, 4253, 4432, 4462"
     obsoletes=""
     submissionType="IETF"
     category="std"
     consensus="true"
     xml:lang="en"
     tocInclude="true"
     tocDepth="4"
     symRefs="true"
     sortRefs="true"
     consensus="true"
     version="3">

  <!-- xml2rfc v2v3 conversion 2.47.0 -->

  <front>

    <title abbrev="KEX Method Updates for SSH">
      Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
      (SSH)
    </title>
    <seriesInfo name="Internet-Draft"
                value="draft-ietf-curdle-ssh-kex-sha2-20"/> name="RFC" value="9142"/>

    <author initials="M. D." initials="M." surname="Baushke" fullname="Mark D. Baushke">
      <address>
        <email>mbaushke.ietf@gmail.com</email>
      </address>
    </author>

    <date month="August" day="6" year="2021"/> month="January" year="2022"/>

    <workgroup>Internet Engineering Task Force</workgroup>

<keyword>3DES</keyword>
 <keyword>AES</keyword>
 <keyword>Advanced Encryption Standard</keyword>
 <keyword>Curve25519</keyword>
 <keyword>Curve448</keyword>
 <keyword>DH</keyword>
 <keyword>Diffie-Hellman</keyword>
 <keyword>Digital Encryption Standard</keyword>
 <keyword>ECC</keyword>
 <keyword>ECDH</keyword>
 <keyword>Elliptic Curve Cryptography</keyword>
 <keyword>Elliptic Curve Diffie-Hellman</keyword>
 <keyword>FFC</keyword>
 <keyword>Finite Field Cryptography</keyword>
 <keyword>IFC</keyword>
 <keyword>Integer Factorization Cryptography</keyword>
 <keyword>MODP</keyword>
 <keyword>MTI</keyword>
 <keyword>Mandatory to Implement</keyword>
 <keyword>Modular Exponential</keyword>
 <keyword>Modular Exponentiation</keyword>
 <keyword>Public Key Exchange</keyword>
 <keyword>RSA</keyword>
 <keyword>SHA-2</keyword>
 <keyword>Secure Shell Key Exchange</keyword>
 <keyword>Secure Shell</keyword>
 <keyword>Security Strength</keyword>
 <keyword>Triple-DES</keyword>
 <keyword>sha1</keyword>
 <keyword>sha256</keyword>
 <keyword>sha384</keyword>
 <keyword>sha512</keyword>
 <keyword>SHA-1</keyword>
 <abstract>

      <t>
        This document is intended to update updates the recommended set of key exchange methods for
        use in the Secure Shell (SSH) protocol to meet evolving needs for
        stronger security.

        This document  It updates RFC RFCs 4250, RFC 4253, RFC 4432, and RFC 4462.
      </t>

    </abstract>

  </front>

  <middle>

    <!-- Section 1. -->

    <section numbered="true" toc="default">
      <name>Overview and Rationale</name>

      <t>
        Secure Shell (SSH) is a common protocol for secure
        communication on the Internet.

        In <xref target="RFC4253" format="default"/>,
        SSH originally defined two Key Exchange (KEX) Method Names that MUST
        <bcp14>MUST</bcp14> be implemented.

        Over time time, what was once considered secure is no longer considered
        secure.

        The purpose of this RFC is to recommend that some published key
        exchanges be deprecated or disallowed as well as
        recommending to recommend some
        that SHOULD <bcp14>SHOULD</bcp14> and one that MUST <bcp14>MUST</bcp14> be
        adopted.
      </t>

      <t>
        This document updates

        <xref target="RFC4250" format="default"/> format="default"/>, <xref target="RFC4253" format="default"/>
        format="default"/>, <xref target="RFC4432" format="default"/> format="default"/>, and
        <xref target="RFC4462" format="default"/>

        by changing the requirement level ("MUST" ("<bcp14>MUST</bcp14>" moving to "SHOULD"
        "<bcp14>SHOULD</bcp14>", "<bcp14>MAY</bcp14>", or "MAY" or "SHOULD NOT", "<bcp14>SHOULD
        NOT</bcp14>", and "MAY" "<bcp14>MAY</bcp14>" moving to "MUST" or
        "SHOULD"
        "<bcp14>MUST</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD
        NOT</bcp14>", or "SHOULD NOT" or "MUST NOT") "<bcp14>MUST NOT</bcp14>") of various key exchange
        mechanisms.

        Some recommendations will be unchanged, unchanged but are included for
        completeness.
      </t>

      <t>
<xref target="RFC4253" format="default"/>

        section 7.2 sectionFormat="of" section="7.2"/> says the following:
      </t>

      <t>
        "The

      <blockquote>
        The key exchange produces two values: a shared secret K, and
        an exchange hash H.

        Encryption and authentication keys are derived from these.

        The exchange hash H from the first key exchange is
        additionally used as the session identifier, which is a unique
        identifier for this connection.

        It is used by authentication methods as a part of the data
        that is signed as a proof of possession of a private key.

        Once computed, the session identifier is not changed, even if
        keys are later re-exchanged."
      </t> re-exchanged.
      </blockquote>

      <t>
        The security strength of the public key exchange algorithm and
        the hash used in the Key Derivation Function (KDF) both impact
        the security of the shared secret K being used.
      </t>

      <t>
        The hashing algorithms used by key exchange methods described
        in this document are: sha1, sha256, sha384, and sha512.

        In many cases, the hash name is explicitly appended to the
        public key exchange algorithm name.

        However, some of them are implicit and defined in the RFC that
        defines the key exchange algorithm name.
      </t>

      <t>
        Various RFCs use different spellings and capitalizations for
        the hashing function and encryption function names.

        For the purpose of this document, the following are equivalent names:
        sha1, SHA1, and SHA-1; sha256, SHA256, SHA-256, and SHA2-256; sha384,
        SHA384, SHA-384, and SHA2-384; and sha512, SHA512, SHA-512, and
        SHA2-512.
      </t>

      <t>
        For the purpose of this document, the following are equivalent:
        aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256,
        AES256, and AES-256.
      </t>

      <t>
        It is good to try to match the security strength of the public
        key exchange algorithm with the security strength of the symmetric
        cipher.
      </t>

      <t>
        There are many possible symmetric ciphers available, available with multiple
        modes.

        The list in Table 1 <xref target="sym_ci_sec"/> is intended as a representative sample
        of those which that appear to be present in most SSH implementations.

        The security strength estimates are generally available in <xref
        target="RFC4086" format="default"/> for triple-DES and AES AES, as well as
        Section 5.6.1.1 of <xref target="NIST.SP.800-57pt1r5" format="default"/>

	Section 5.6.1.1.
        format="default"/>.
      </t>

      <!-- Table 1 -->

      <table align="center"> align="center" anchor="sym_ci_sec">
        <name>Symmetric Cipher Security Strengths</name>
        <thead>
          <tr>
            <th align="left">Cipher Name (modes)</th>
            <th align="left">Estimated Security Strength</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">3des (cbc)</td>
            <td align="left">112 bits</td>
          </tr>
          <tr>
            <td align="left">aes128 (cbc, ctr, gcm)</td>
            <td align="left">128 bits</td>
          </tr>
          <tr>
            <td align="left">aes192 (cbc, ctr, gcm)</td>
            <td align="left">192 bits</td>
          </tr>
          <tr>
            <td align="left">aes256 (cbc, ctr, gcm)</td>
            <td align="left">256 bits</td>
          </tr>
        </tbody>
      </table>

      <t>
        The following subsections describe how to select each
        component of the key exchange.
      </t>

      <!-- Section 1.1. -->

      <section numbered="true" toc="default">
        <name>Selecting an appropriate hashing algorithm</name> Appropriate Hashing Algorithm</name>

        <t>
          The SHA-1 hash is in the process of being deprecated for
          many reasons.
        </t>

        <t>
          There have been attacks against SHA-1 SHA-1, and it is no longer
          strong enough for SSH security requirements.

          Therefore, it is desirable to move away from using it before
          attacks become more serious.
        </t>

        <t>
          The SHA-1 hash provides for approximately 80 bits of
          security strength.

          This means that the shared key being used has at most 80
          bits of security strength strength, which may not be sufficient for
          most users.
        </t>

        <t>
          For purposes of key exchange methods, attacks against SHA-1 are
          collision attacks that usually rely on human help, help rather than a
          pre-image attack.

          The SHA-1 hash resistance against a second pre-image is still at 160
          bits, but SSH does not depend on second pre-image
          resistance,
          resistance but rather on chosen-prefix collision
          resistance.
        </t>

        <t>
          Transcript Collision attacks are documented in

          <xref target="TRANS-COLL" target="TRANSCRIPTION" format="default"/>.

          This paper shows that an on-path attacker does not tamper
          with the Diffie-Hellman values and does not know the
          connection keys.

          The attack could be used to tamper with both I_C and I_S (as defined
          in section 7.3 of <xref target="RFC4253" format="default"/>), sectionFormat="of" section="7.3"
          format="default"/>) and might potentially be able to downgrade the
          negotiated ciphersuite to a weak cryptographic algorithm that the
          attacker knows how to break.
        </t>

        <t>
          These attacks are still computationally very difficult to
          perform, but it is desirable that any key exchange using
          SHA-1 be phased out as soon as possible.
        </t>

        <t>
          If there is a need for using SHA-1 in a key exchange for
          compatibility, it would be desirable to list it last in
          the preference list of key exchanges.
        </t>

        <t>
          Use of the SHA-2 family of hashes found in

          <xref target="RFC6234" format="default"/>

          rather than the SHA-1 hash is strongly advised.
        </t>

        <t>
          When it comes to the SHA-2 family of Secure Hashing secure hashing
          functions, SHA2-256 has 128 bits of security strength;
          SHA2-384 has 192 bits of security strength; and SHA2-512 has
          256 bits of security strength.

          It is suggested that the minimum secure hashing function
          that should be
          used for key exchange methods is should be SHA2-256
          with 128 bits of security strength.

          Other hashing functions may also have the same number of
          bits of security strength, but none are as yet defined in
          any RFC for use in a KEX for SSH.
        </t>

        <t>
          To avoid combinatorial explosion of key exchange names,
          newer key exchanges are generally restricted to *-sha256 and
          *-sha512.

          The exceptions are ecdh-sha2-nistp384 and
          gss-nistp384-sha384-* gss-nistp384-sha384-*,
          which are defined to use SHA2-384 (also known as SHA-384) defined in
          <xref target="RFC6234"/> for the hash algorithm.
        </t>

        <t>
          Table 2
          <xref target="sec_strength"/> provides a summary of security
          strength for hashing functions for collision resistance. You may
          consult

          <xref target="NIST.SP.800-107r1" format="default"/>

          for more information on hash algorithm security strength.
        </t>
          <!-- Table 2 -->

          <table anchor="sec_strength" align="center">
            <name>Hashing Function Security Strengths</name>
            <thead>
              <tr>
                <th align="left">Hash Name</th>
                <th align="left">Estimated Security Strength</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">sha1</td>
                <td align="left">80 bits (before attacks)</td>
              </tr>
              <tr>
                <td align="left">sha256</td>
                <td align="left">128 bits</td>
              </tr>
              <tr>
                <td align="left">sha384</td>
                <td align="left">192 bits</td>
              </tr>
              <tr>
                <td align="left">sha512</td>
                <td align="left">256 bits</td>
              </tr>
            </tbody>
          </table>

      </section>

      <!-- Section 1.2. -->

      <section numbered="true" toc="default">
        <name>Selecting an appropriate Appropriate Public key Key Algorithm</name>

        <t>
          SSH uses mathematically hard problems for doing key
          exchanges:
        </t>

        <ul>
          <li>
            Elliptic Curve Cryptography (ECC) has families of curves
            for key exchange methods for SSH.

            NIST prime curves with names and other curves are
            available using an object identifier (OID) with Elliptic
            Curve Diffie-Hellman (ECDH) via

            <xref target="RFC5656" format="default"/>.

            Curve25519 and Curve448 curve448 key exchanges are used with ECDH
            via

            <xref target="RFC8731" format="default"/>.
          </li>

          <li>
            Finite Field Cryptography (FFC) is used for Diffie-Hellman
            (DH) key exchange with "safe primes" either from a
            specified list found in

            <xref target="RFC3526" format="default"/>

            or generated dynamically via

            <xref target="RFC4419" format="default"/>

            as updated by

            <xref target="RFC8270" format="default"/>.
          </li>

          <li>
            Integer Factorization Cryptography (IFC) using the RSA
            algorithm is provided for in

            <xref target="RFC4432" format="default"/>.
          </li>
        </ul>

        <t>
          It is desirable that the security strength of the key
          exchange be chosen to be comparable with the security
          strength of the other elements of the SSH handshake.

          Attackers can target the weakest element of the SSH
          handshake.
        </t>

        <t>
          It is desirable to select that a minimum of 112 bits of security
          strength be selected to match the weakest of the symmetric cipher
          (3des-cbc) available.

          Based on implementer security needs, a stronger minimum may
          be desired.
        </t>

        <t>
          The larger the MODP Modular Exponentiation (MODP) group, the ECC curve size, or the RSA
          key length, the more computation power will be required to
          perform the key exchange.
        </t>

        <!-- Section 1.2.1. -->

        <section numbered="true" toc="default">
          <name>Elliptic Curve Cryptography (ECC)</name>

          <t>
            For ECC, across all of the named curves curves, the minimum security
            strength is approximately 128 bits.

            The
            <xref target="RFC5656" format="default"/>
            key exchanges for the named curves use a hashing function with a
            matching security strength.

            Likewise, the

            <xref target="RFC8731" format="default"/>

            key exchanges use a hashing function which that has more security
            strength than the curves.

            The minimum strength will be the security strength of the
            curve.

            Table 3

            <xref target="ecc_sec_strengths"/> contains a breakdown of just
            the ECC security strength by curve name and not including name; it does include the
            hashing algorithm used.

            The curve* security level curve25519 and curve488 security-level numbers are in
            <xref target="RFC7748" format="default"/>.

            The nist* numbers nistp256, nistp384, and nistp521 (NIST prime curves) are
            provided in <xref target="RFC5656" format="default"/>.

            The hashing algorithm designated for use with the
            individual curves have approximately the same number of
            bits of security as the named curve.
          </t>

          <!-- Table 3 -->

          <table align="center"> align="center" anchor="ecc_sec_strengths">
            <name>ECC Security Strengths</name>
            <thead>
              <tr>
                <th align="left">Curve Name</th>
                <th align="left">Estimated Security Strength</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">nistp256</td>
                <td align="left">128 bits</td>
              </tr>
              <tr>
                <td align="left">nistp384</td>
                <td align="left">192 bits</td>
              </tr>
              <tr>
                <td align="left">nistp521</td>
                <td align="left">512 bits</td>
              </tr>
              <tr>
                <td align="left">Curve25519</td> align="left">curve25519</td>
                <td align="left">128 bits</td>
              </tr>
              <tr>
                <td align="left">Curve448</td> align="left">curve448</td>
                <td align="left">224 bits</td>
              </tr>
            </tbody>
          </table>

        </section>

        <!-- Section 1.2.2. -->

        <section numbered="true" toc="default">
          <name>Finite Field Cryptography (FFC)</name>

          <t>
            For FFC, it is recommended to use a modulus with a minimum
            of 2048 bits (approximately 112 bits of security strength)
            with a hash that has at least as many bits of security as
            the FFC.

            The security strength of the FFC and the hash together
            will be the minimum of those two values.

            This is sufficient to provide a consistent security
            strength for the 3des-cbc cipher.

            <xref target="RFC3526" sectionFormat="of" section="1"
            format="default"/>

            section 1 notes that the Advanced Encryption Standard
            (AES) cipher, which has more strength, needs stronger groups.

            For the 128-bit AES AES, we need about a 3200-bit group.

            The 192 192- and 256-bit keys would need groups that are about
            8000 and 15400 bits bits, respectively.

            Table 4

            <xref target="fcc_modp_sec"/> provides the security strength of the MODP group.

            When paired with a hashing algorithm, the security
            strength will be the minimum of the two algorithms.
          </t>

          <!-- Table 4 -->

          <table align="center"> align="center" anchor="fcc_modp_sec">
            <name>FFC MODP Security Strengths</name>
            <thead>
              <tr>
                <th align="left">Prime Field Size</th>
                <th align="left">Estimated Security Strength</th>
                <th align="left">Example MODP Group</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">2048-bit</td>
                <td align="left">112 bits</td>
                <td align="left">group14</td>
              </tr>
              <tr>
                <td align="left">3072-bit</td>
                <td align="left">128 bits</td>
                <td align="left">group15</td>
              </tr>
              <tr>
                <td align="left">4096-bit</td>
                <td align="left">152 bits</td>
                <td align="left">group16</td>
              </tr>
              <tr>
                <td align="left">6144-bit</td>
                <td align="left">176 bits</td>
                <td align="left">group17</td>
              </tr>
              <tr>
                <td align="left">8192-bit</td>
                <td align="left">200 bits</td>
                <td align="left">group18</td>
              </tr>
            </tbody>
          </table>

          <t>
            The minimum MODP group is the 2048-bit MODP group14.

            When used with sha1, a SHA-1 hash, this group provides approximately 80
            bits of security.

            When used with sha256, a SHA2-256 hash, this group provides approximately
            112 bits of security.

            The 3des-cbc cipher itself provides at most 112 bits of
            security, so the group14-sha256 key exchanges is
            sufficient to keep all of the 3des-cbc key, for 112 bits of
            security.
          </t>

          <t>
            A 3072-bit MODP group when used with sha256 a SHA2-256 hash will provide
            approximately 128 bits of security.

            This is desirable when using a cipher such as aes128 or
            chacha20-poly1305 that provides approximately 128 bits of
            security.
          </t>

          <t>
            The 8192-bit group18 MODP group when used with sha512
            provides approximately 200 bits of security security, which is
            sufficient to protect aes192 with 192 bits of security.
          </t>

        </section>

        <!-- Section 1.2.3. -->

        <section numbered="true" toc="default">
          <name>Integer Factorization Cryptography (IFC)</name>

          <t>
            The only IFC algorithm for key exchange is the RSA
            algorithm specified in

            <xref target="RFC4432" format="default"/>.

            RSA 1024-bit keys have approximately 80 bits of security
            strength.

            RSA 2048-bit keys have approximately 112 bits of security
            strength.

            It is worth noting that the IFC types of key exchange do
            not provide Forward Secrecy Secrecy, which both FFC and ECC do
            provide.
          </t>

          <t>
            In order to match the 112 bits of security strength needed
            for 3des-cbc, an RSA 2048-bit key matches the security
            strength.

            The use of a SHA-2 Family family hash with RSA 2048-bit keys has
            sufficient security to match the 3des-cbc symmetric cipher.

            The rsa1024-sha1 key exchange has approximately 80 bits of
            security strength and is not desirable.
          </t>

          <t>
            Table 5
            <xref target="ifc_sec"/> summarizes the security strengths of
            these key exchanges without including the hashing algorithm
            strength. Guidance for these strengths are can be found in Section
            5.6.1.1 of <xref target="NIST.SP.800-57pt1r5" format="default"/>

            Section 5.6.1.1. format="default"/>.
          </t>

          <!-- Table 5 -->

          <table anchor="ifc_sec" align="center">
            <name>IFC Security Strengths</name>
            <thead>
              <tr>
                <th align="left">Key Exchange Method</th>
                <th align="left">Estimated Security Strength</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">rsa1024-sha1</td>
                <td align="left">80 bits</td>
              </tr>
              <tr>
                <td align="left">rsa2048-sha256</td>
                <td align="left">112 bits</td>
              </tr>
            </tbody>
          </table>

        </section>

      </section>

    </section>

    <!-- Section 2. -->

    <section numbered="true" toc="default">
      <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
        RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>

    <!-- Section 3. -->

    <section numbered="true" toc="default">
      <name>Key Exchange Methods</name>

      <t>
        This document adopts the style and conventions of

        <xref target="RFC4253" format="default"/>

        in specifying how the use of data key exchange is indicated in
        SSH.
      </t>

      <t>
        This RFC also collects key exchange method names in various
        existing RFCs

        <xref

        (<xref target="RFC4253" format="default"/>, <xref target="RFC4419"
        format="default"/>, <xref target="RFC4432" format="default"/>, <xref
        target="RFC4462" format="default"/>, <xref target="RFC5656"
        format="default"/>, <xref target="RFC8268" format="default"/>, <xref target="RFC8731"
        target="RFC8308" format="default"/>, <xref target="RFC8732" target="RFC8731"
        format="default"/>, and <xref target="RFC8308" format="default"/>, target="RFC8732" format="default"/>) and
        provides a suggested suitability for implementation of
        MUST, SHOULD, MAY, SHOULD NOT,
        <bcp14>MUST</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>MAY</bcp14>,
        <bcp14>SHOULD NOT</bcp14>, and MUST NOT. <bcp14>MUST NOT</bcp14>.

        Any method not explicitly listed MAY <bcp14>MAY</bcp14> be implemented.
      </t>

      <!-- Address confusion of martin.h.duke@gmail.com -->

      <t>
        <xref target="RFC4253" sectionFormat="of" section="7.2"
        format="default"/> section 7.2 "Output
        of Key Exchange" defines the generation of a shared secret K (really
        the output of the KDF) and an exchange key hash H.  Each key exchange
        method uses a specified HASH function function, which must be the same for both
        key exchange and Key Derivation.

        H is used for key exchange integrity across the SSH session as
        it is computed only once.

        It is noted at the end of the 7.2 section that "This <xref target="RFC4253" section="7.2"
        sectionFormat="of"/> that:
      </t>

	<blockquote>This process will lose entropy if the
        amount of entropy in K is larger than the internal state size of HASH." so
        HASH.</blockquote>
<t>
	So, care must be taken that the hashing algorithm used is well
        chosen ("reasonable") for the key exchange algorithms being used.
</t>

      <t>

        This document is intended to provide provides guidance as to what key
        exchange algorithms are to be considered for new or updated
        SSH implementations.
      </t>

      <t>
        In general, key exchange methods which that are considered 'weak' "weak"
        are being moved to either deprecated ("SHOULD NOT"), ("<bcp14>SHOULD NOT</bcp14>") or
        disallowed ("MUST NOT"). ("<bcp14>MUST NOT</bcp14>").

        Methods which that are newer or considered to be stronger usually
        require more device resources than many administrators and/or
        developers need are to be allowed ("MAY"). ("<bcp14>MAY</bcp14>").

        (Eventually, some of these methods could be moved by consensus
        to "SHOULD" "<bcp14>SHOULD</bcp14>" to increase interoperability and security.)

        Methods which that are not 'weak' "weak" and have implementation consensus
        are encouraged ("SHOULD"). ("<bcp14>SHOULD</bcp14>").

        There needs to be at least one consensus method promoted to a status
        of mandatory to implement (MTI).

        This should help to provide continued interoperability even
        with the loss of one of the now disallowed MTI methods.
      </t>

      <t>
        For this document, 112 bits of security strength is the
        minimum.

        Use of either or both of SHA-1 and RSA 1024-bits 1024 bits at an
        approximate 80 bits of security fall below this minimum and
        should be deprecated and moved to disallowed as quickly as
        possible in configured deployments of SSH.

        It seems plausible that this minimum may be increased over
        time, so authors and administrators may wish to prepare for a
        switch to algorithms that provide more security strength.
      </t>

      <!-- Section 3.1. -->

      <section numbered="true" toc="default">
        <name>Elliptic Curve Cryptography (ECC)</name>

        <t>
          The EC Elliptic Curve (EC) key exchange algorithms used with SSH include the
          ECDH and EC Menezes–Qu–Vanstone (ecmqv). Menezes-Qu-Vanstone (ECMQV).
        </t>

        <t>
          The ECC curves defined for the key exchange algorithms above
          include; include
          the following: curve25519, curve448, the NIST prime curves
          (nistp256, nistp384, nistp521) and nistp521), as well as other curves allowed
          for by <xref target="RFC5656" format="default"/>

          section 6. sectionFormat="of" section="6"
          format="default"/>.  There are GSSAPI-based key-exchange key exchange mechanisms based on the
          Generic Security Service Application Program Interface (GSS-API) that
          use these curves as well which that have a 'gss-' "gss-" prefix.
        </t>

        <!-- Section 3.1.1. -->

        <section numbered="true" toc="default">
          <name>curve25519-sha256 and gss-curve25519-sha256-*</name>

          <t>
            Curve25519 is efficient on a wide range of architectures with
            properties that allow higher performance higher-performance implementations compared
            to the patented elliptic curve parameters purchased by NIST for
            the general public to use
            and as described in
            <xref target="RFC5656" format="default"/>.

            The corresponding key exchange methods use SHA2-256 (also known as
            SHA-256) defined in

            <xref target="RFC6234" format="default"/>.

            SHA2-256 is a reasonable hash for use in both the KDF and
            session integrity. It is reasonable for both gss and
            non-gss uses of curve25519 key exchange methods.

            These key exchange methods are described in

            <xref target="RFC8731" format="default"/>

            and

            <xref target="RFC8732" format="default"/>

            and are similar to the IKEv2 key agreement described in

            <xref target="RFC8031" format="default"/>.

            The curve25519-sha256 key exchange method has multiple
            implementations and SHOULD <bcp14>SHOULD</bcp14> be implemented.

            The gss-curve25519-sha256-* key exchange method SHOULD <bcp14>SHOULD</bcp14>
            also be implemented because it shares the same performance
            and security characteristics as curve25519-sha256.
          </t>

          <t>
            Table 6
            <xref target="curve25519"/> contains a summary of the
            recommendations for
            curve25519 based curve25519-based key exchanges.
          </t>

          <!-- Table 6 -->

          <table align="center"> align="center" anchor="curve25519">
            <name>Curve25519 Implementation Guidance</name>
            <thead>
              <tr>
                <th align="left">Key Exchange Method Name</th>
                <th align="left">Guidance</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">curve25519-sha256</td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
              </tr>
              <tr>
                <td align="left">gss-curve25519-sha256-*</td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
              </tr>
            </tbody>
          </table>

        </section>

        <!-- Section 3.1.2. -->

        <section numbered="true" toc="default">
          <name>curve448-sha512 and gss-curve448-sha512-*</name>

          <t>
            Curve448 provides more security strength than Curve25519 curve25519
            at a higher computational and bandwidth cost.

            The corresponding key exchange methods use SHA2-512 (also known as
            SHA-512) defined in

            <xref target="RFC6234" format="default"/>.

            SHA2-512 is a reasonable hash for use in both the KDF and
            session integrity. It is reasonable for both gss and
            non-gss uses of curve448 key exchange methods.

            These key exchange methods are described in

            <xref target="RFC8731" format="default"/>

            and

            <xref target="RFC8732" format="default"/>

            and are similar to the IKEv2 key agreement described in

            <xref target="RFC8031" format="default"/>.

            The curve448-sha512 key exchange method MAY <bcp14>MAY</bcp14> be
            implemented.

            The gss-curve448-sha512-* key exchange method MAY <bcp14>MAY</bcp14> also be
            implemented because it shares the same performance and
            security characteristics as curve448-sha512.
          </t>

          <t>
            Table 7
            <xref target="curve448"/> contains a summary of the
            recommendations for
            curve448 based curve448-based key exchanges.
          </t>

          <!-- Table 7 -->

          <table align="center"> align="center" anchor="curve448">
            <name>Curve448 Implementation Guidance</name>
            <thead>
              <tr>
                <th align="left">Key Exchange Method Name</th>
                <th align="left">Guidance</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">curve448-sha512</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
                <td align="left">gss-curve448-sha512-*</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
            </tbody>
          </table>
        </section>

        <!-- Section 3.1.3. -->

        <section numbered="true" toc="default">
          <name>
            ecdh-*, ecmqv-sha2, and gss-nistp*
          </name>

          <t>
            The ecdh-sha2-* name-space namespace allows for both the named NIST prime
            curves (nistp256, nistp384, and nistp521) as well as other curves
            to be defined for the Elliptic-curve
            Diffie-Hellman ECDH key exchange.

            At the time of this writing, there are three named curves
            in this name-space which SHOULD namespace that <bcp14>SHOULD</bcp14> be supported.

            They appear in <xref target="RFC5656" format="default"/>

            in section 10.1 ("Required Curves"). sectionFormat="of"
            section="10.1" format="default"/>.

            If implemented, the named curves SHOULD <bcp14>SHOULD</bcp14> always be enabled
            unless specifically disabled by local security policy.

            In <xref target="RFC5656" sectionFormat="of" section="6.1"
            format="default"/>,

            section 6.1, the method to name other ECDH curves using
            OIDs is specified.

            These other curves MAY <bcp14>MAY</bcp14> be implemented.
          </t>

            <t>
              The GSS-API name-space namespace with gss-nistp*-sha* mirrors the
              algorithms used by ecdh-sha2-* names.

              They are described in

              <xref target="RFC8732" format="default"/>.
            </t>

            <t>
              ECDH reduces bandwidth of key exchanges compared to
              FFC DH at a similar security strength.
            </t>

            <t>
              Table 8
              <xref target="ecdh_guidance"/> lists algorithms as SHOULD
              "<bcp14>SHOULD</bcp14>" where implementations may be more
              efficient or widely deployed.

              The items listed as MAY "<bcp14>MAY</bcp14>" in Table 8 <xref
              target="ecdh_guidance"/> are potentially less efficient.
            </t>

            <!-- Table 8 -->

            <table anchor="ecdh_guidance" align="center">
              <name>ECDH Implementation Guidance</name>
            <thead>
                <tr>
                  <th align="left">Key Exchange Method Name</th>
                  <th align="left">Guidance</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                  <td align="left">ecdh-sha2-*</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">ecdh-sha2-nistp256</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-nistp256-sha256-*</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">ecdh-sha2-nistp384</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-nistp384-sha384-*</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">ecdh-sha2-nistp521</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-nistp521-sha512-*</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">ecmqv-sha2</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
            </tbody>
            </table>

          <t>
            It is advisable to match the ECDSA Elliptic Curve Digital Signature
            Algorithm (ECDSA) and ECDH algorithms algorithm to use the same curve for
            both to maintain the same security strength in the connection.
          </t>

        </section>

      </section>

      <!-- Section 3.2. -->

      <section numbered="true" toc="default">
        <name>Finite Field Cryptography (FFC)</name>

        <!-- Section 3.2.1. -->

        <section numbered="true" toc="default">
          <name>FFC diffie-hellman using generated Diffie-Hellman Using Generated MODP groups</name> Groups</name>

          <t>
            <xref target="RFC4419" format="default"/>

            defines two key exchange methods that use a random
            selection from a set of pre-generated moduli for key
            exchange:

            the diffie-hellman-group-exchange-sha1 method, method and the
            diffie-hellman-group-exchange-sha256 method.

            Per

            <xref target="RFC8270" format="default"/>,

            implementations SHOULD <bcp14>SHOULD</bcp14> use a MODP group whose modulus size
            is equal to or greater than 2048 bits.

            MODP groups with a modulus size less than 2048 bits are
            weak and MUST NOT <bcp14>MUST NOT</bcp14> be used.
          </t>

          <t>
            The diffie-hellman-group-exchange-sha1 key exchange method
            SHOULD NOT
            <bcp14>SHOULD NOT</bcp14> be used.

            This method uses SHA-1, which is being deprecated.
          </t>

          <t>
            The diffie-hellman-group-exchange-sha256 key exchange
            method MAY <bcp14>MAY</bcp14> be used.

            This method uses SHA-256, SHA2-256, which is reasonable for MODP
            groups less than 4000 4096 bits.
          </t>

          <t>
            Care should be taken in the pre-generation of the moduli P
            and generator G such that the generator provides a
            Q-ordered subgroup of P.

            Otherwise, the parameter set may leak one bit of the
            shared secret.
          </t>

          <t>
            Table 9
            <xref target="ffc_modp"/> provides a summary of the Guidance guidance for these
            exchanges.
          </t>

          <!-- Table 9 -->

            <table anchor="ffc_modp" align="center">
              <name>FFC Generated MODP Group Implementation Guidance</name>
            <thead>
                <tr>
                  <th align="left">Key Exchange Method Name</th>
                  <th align="left">Guidance</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                  <td align="left">diffie-hellman-group-exchange-sha1</td>
                  <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
                </tr>
                <tr>
                  <td align="left">diffie-hellman-group-exchange-sha256</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
            </tbody>
            </table>

        </section>

        <!-- Section 3.2.2. -->

        <section numbered="true" toc="default">
          <name>FFC diffie-hellman using named Diffie-Hellman Using Named MODP groups</name> Groups</name>
            <t>

              The diffie-hellman-group14-sha256 key exchange method is
              defined in

              <xref target="RFC8268" format="default"/>

              and represents a key exchange which that has approximately
              112 bits of security strength that matches 3des-cbc
              symmetric cipher security strength.

              It is a reasonably simple transition from SHA-1 to SHA-2 SHA-2, and
              given that diffie-hellman-group14-sha1 and
              diffie-hellman-group14-sha256 share a MODP group and only differ
              in the hash function used for the KDF and integrity, it is a
              correspondingly simple transition from implementing
              diffie-hellman-group14-sha1 to implementing
              diffie-hellman-group14-sha256.

              Given that diffie-hellman-group14-sha1 is being removed
              from mandatory to implement (MTI) status, the
              diffie-hellman-group14-sha256 method MUST <bcp14>MUST</bcp14> be
              implemented.

              The rest of the FFC MODP group from

              <xref target="RFC8268" format="default"/>

              have a larger number of security bits and are suitable
              for symmetric ciphers that also have a similar number of
              security bits.
            </t>

            <t>
              Table 10 below
              <xref target="ffc_named_group"/> provides explicit guidance by name.
            </t>

            <!-- Table 10 -->

            <table anchor="ffc_named_group" align="center">
              <name>FFC Named Group Implementation Guidance</name>
            <thead>
                <tr>
                  <th align="left">Key Exchange Method Name</th>
                  <th align="left">Guidance</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                  <td align="left">diffie-hellman-group14-sha256</td>
                  <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-group14-sha256-*</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">diffie-hellman-group15-sha512</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-group15-sha512-*</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">diffie-hellman-group16-sha512</td>
                  <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-group16-sha512-*</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">diffie-hellman-group17-sha512</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-group17-sha512-*</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">diffie-hellman-group18-sha512</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
                <tr>
                  <td align="left">gss-group18-sha512-*</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
            </tbody>
            </table>

        </section>

      </section>

      <!-- Section 3.3. -->

      <section numbered="true" toc="default">
        <name>Integer Factorization Cryptography (IFC)</name>

        <t>
          The rsa1024-sha1 key exchange method is defined in

          <xref target="RFC4432" format="default"/>

          and uses an RSA 1024-bit modulus with a SHA-1 hash.

          This key exchange does NOT meet security requirements.

          This method MUST NOT <bcp14>MUST NOT</bcp14> be implemented.
        </t>

        <t>
          The rsa2048-sha256 key exchange method is defined in
          <xref target="RFC4432" format="default"/>
          and uses an RSA 2048-bit modulus with a SHA2-256 hash.  This key
          exchange meets 112 bit 112-bit minimum security strength.  This method MAY
          <bcp14>MAY</bcp14> be implemented.
        </t>

        <t>
          Table 11 provide
          <xref target="ifc_guidance"></xref> provides a summary of the
          guidance for IFC key exchanges.
        </t>

          <!-- Table 11 -->

            <table anchor="ifc_guidance" align="center">
              <name>IFC Implementation Guidance</name>
            <thead>
                <tr>
                  <th align="left">Key Exchange Method Name</th>
                  <th align="left">Guidance</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                  <td align="left">rsa1024-sha1</td>
                  <td align="left">MUST NOT</td> align="left"><bcp14>MUST NOT</bcp14></td>
                </tr>
                <tr>
                  <td align="left">rsa2048-sha256</td>
                  <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                </tr>
            </tbody>
            </table>

      </section>

      <!-- Section 3.4. -->

      <section numbered="true" toc="default">
        <name>KDFs and Integrity Hashing</name>

        <t>
          The SHA-1 and SHA-2 family of hashing algorithms are
          combined with the FFC, ECC, and IFC algorithms to comprise a
          key exchange method name.
        </t>

        <t>
          The selected hash algorithm is used both in the KDF as well
          as for the integrity of the response.
        </t>

        <t>
          All of the key exchange methods using the SHA-1 hashing
          algorithm should be deprecated and phased out due to
          security concerns for SHA-1, as documented in

          <xref target="RFC6194" format="default"/>.
        </t>

        <t>
          Unconditionally deprecating and/or disallowing SHA-1
          everywhere will hasten the day when it may be simply removed
          from implementations completely.

          Leaving partially-broken partially broken algorithms lying around is not a
          good thing to do.
        </t>

        <t>
          The SHA-2 Family family of hashes

          <xref target="RFC6234" format="default"/>

          is more secure than SHA-1. They have been standardized for
          use in SSH with many of the currently defined key exchanges.
        </t>

        <t>
          Please note that at the present time, there is no key
          exchange method for Secure Shell which that uses the SHA-3 family
          of Secure Hashing secure hashing functions or the Extendable Output
          Functions. Extendable-Output
          Functions <xref target="NIST.FIPS.202" format="default"/>.
        </t>

        <t>
          Prior to the changes made by this document,
          diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1
          were MTI.

          diffie-hellman-group14-sha1 is the stronger of the two.

          Group14 (a 2048-bit MODP group) is defined in

          <xref target="RFC3526" format="default"/>. format="default" sectionFormat="of"
          section="3"/>.

          The SSH group1 is defined in <xref target="RFC4253" sectionFormat="of"
          section="8.1"/> as using the Oakley Group 2 provided in <xref target="RFC2409"
          sectionFormat="of" section="6.2"/> (a 1024-bit MODP group).  This
          group1 MODP group with approximately 80 bits of security is too weak
          to be retained.

          However, rather than jumping from the MTI status to making it
          disallowed, many implementers suggested that it should transition to
          deprecated first and be disallowed at a later time.

          The group14 MODP group using a sha1 SHA-1 hash for the KDF is not
          as weak as the group1 MODP group.

          There are some legacy situations where it will still provide
          administrators with value, such as small hardware IOT Internet of Things
          (IOT) devices which that have insufficient compute and memory resources to
          use larger MODP groups before a timeout of the session occurs.

          Transitioning

          There was consensus to transition from MTI to a requirement status
          that provides for continued use with the expectation of deprecating or
          disallowing that it would
          be deprecated or disallowed in the future was able to find consensus. future.

          Therefore, it is considered reasonable to retain the
          diffie-hellman-group14-sha1 exchange for interoperability
          with legacy implementations.

          The diffie-hellman-group14-sha1 key exchange MAY <bcp14>MAY</bcp14> be
          implemented, but should be put at the end of the list of
          negotiated key exchanges.
        </t>

        <t>
          The diffie-hellman-group1-sha1 and
          diffie-hellman-group-exchange-sha1 SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
          implemented.

          The gss-group1-sha1-*, gss-group14-sha1-*, and
          gss-gex-sha1-* key exchanges are already specified as SHOULD
          NOT <bcp14>SHOULD
          NOT</bcp14> be implemented by

          <xref target="RFC8732" format="default"/>.
        </t>

      </section>

      <!-- Section 3.5. -->

      <section numbered="true" toc="default">
        <name>Secure Shell Extension Negotiation</name>

        <t>
          There are two methods, ext-info-c and ext-info-s, defined in

          <xref target="RFC8308" format="default"/>.

          They provide a mechanism to support other Secure Shell
          negotiations.

          Being able to extend functionality is desirable.

          Both ext-info-c and ext-info-s SHOULD <bcp14>SHOULD</bcp14> be implemented.
        </t>

      </section>

    </section>

    <!-- Section 4. -->

    <section numbered="true" toc="default"> toc="default" anchor="key_ex_method">
      <name>
        Summary Guidance for Implementation of Key Exchange Method Names Implementations
      </name>

      <t>
        The Implement column is the current recommendations of this
        RFC.

        Table 12
        <xref target="iana_key_exchange"/> provides the existing key exchange method names
        listed alphabetically.
        The Implement column contains the current recommendations of this RFC.
      </t>

      <!-- Table 12 -->

      <table align="center"> align="center" anchor="iana_key_exchange">
        <name>IANA guidance Guidance for key exchange method name implementations</name> Implementation of Key Exchange Method Names</name>

        <thead>
          <tr>
            <th align="left">Key Exchange Method Name</th>
            <th align="left">Reference</th>
            <th align="left">Previous Recommendation</th>
            <!--
                 RFC EDITOR TODO

                 The RFCxxxxx should be replaced with the RFC of this
                 document.
            -->

            <th align="left">RFCxxxxx align="left">RFC 9142 Implement</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td align="left">curve25519-sha256</td>
            <td align="left">RFC8731</td> align="left"><xref target="RFC8731"/></td>
            <td align="left">none</td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">curve448-sha512</td>
            <td align="left">RFC8731</td> align="left"><xref target="RFC8731"/></td>
            <td align="left">none</td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group-exchange-sha1</td>
            <td align="left">RFC4419 RFC8270</td> align="left"><xref target="RFC4419"/>, <xref target="RFC8270"/></td>
            <td align="left">none</td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group-exchange-sha256</td>
            <td align="left">RFC4419 RFC8720</td> align="left"><xref target="RFC4419"/>, <xref target="RFC8270"/></td>
            <td align="left">none</td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group1-sha1</td>
            <td align="left">RFC4253</td> align="left"><xref target="RFC4253"/></td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group14-sha1</td>
            <td align="left">RFC4253</td> align="left"><xref target="RFC4253"/></td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group14-sha256</td>
            <td align="left">RFC8268</td> align="left"><xref target="RFC8268"/></td>
            <td align="left">none</td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group15-sha512</td>
            <td align="left">RFC8268</td> align="left"><xref target="RFC8268"/></td>
            <td align="left">none</td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group16-sha512</td>
            <td align="left">RFC8268</td> align="left"><xref target="RFC8268"/></td>
            <td align="left">none</td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group17-sha512</td>
            <td align="left">RFC8268</td> align="left"><xref target="RFC8268"/></td>
            <td align="left">none</td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">diffie-hellman-group18-sha512</td>
            <td align="left">RFC8268</td> align="left"><xref target="RFC8268"/></td>
            <td align="left">none</td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">ecdh-sha2-*</td>
            <td align="left">RFC5656</td> align="left"><xref target="RFC5656"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">ecdh-sha2-nistp256</td>
            <td align="left">RFC5656</td> align="left"><xref target="RFC5656"/></td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">ecdh-sha2-nistp384</td>
            <td align="left">RFC5656</td> align="left"><xref target="RFC5656"/></td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">ecdh-sha2-nistp521</td>
            <td align="left">RFC5656</td> align="left"><xref target="RFC5656"/></td>
            <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">ecmqv-sha2</td>
            <td align="left">RFC5656</td> align="left"><xref target="RFC5656"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">ext-info-c</td>
            <td align="left">RFC8308</td> align="left"><xref target="RFC8308"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">ext-info-s</td>
            <td align="left">RFC8308</td> align="left"><xref target="RFC8308"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-</td>
            <td align="left">RFC4462</td> align="left"><xref target="RFC4462"/></td>
            <td align="left">reserved</td>
            <td align="left">reserved</td>
          </tr>
          <tr>
            <td align="left">gss-curve25519-sha256-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-curve448-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-gex-sha1-*</td>
            <td align="left">RFC4462/RFC8732</td> align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group1-sha1-*</td>
            <td align="left">RFC4462/RFC8732</td> align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group14-sha1-*</td>
            <td align="left">RFC4462/RFC8732</td> align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
            <td align="left">SHOULD NOT</td> align="left"><bcp14>SHOULD NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group14-sha256-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group15-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group16-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group17-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-group18-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-nistp256-sha256-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-nistp384-sha384-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">gss-nistp521-sha512-*</td>
            <td align="left">RFC8732</td> align="left"><xref target="RFC8732"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
          </tr>
          <tr>
            <td align="left">rsa1024-sha1</td>
            <td align="left">RFC4432</td> align="left"><xref target="RFC4432"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MUST NOT</td> align="left"><bcp14>MUST NOT</bcp14></td>
          </tr>
          <tr>
            <td align="left">rsa2048-sha256</td>
            <td align="left">RFC4432</td> align="left"><xref target="RFC4432"/></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
          </tr>
        </tbody>
      </table>

      <t>
        The full set of official

        <xref target="IANA-KEX" target="IANA-SSH" format="default"/>

        key algorithm method names

        "Key Exchange Method Names" not otherwise mentioned in this document MAY
        <bcp14>MAY</bcp14> be implemented.
      </t>

      <t>
        [TO BE REMOVED: This registration should take place at the
        following location URL:
        https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

        It is hoped that the Table 12 in section 4 of this draft
        provide guidance information to be merged into the IANA
        ssh-parameters-16 table.

        Future RFCs may update the these Implementation Guidance
        notations.
        ]
      </t>

    </section>

    <!-- Section 5. -->
    <section numbered="true" toc="default">
      <name>Acknowledgements</name>

      <t>
        Thanks to the following people for review and comments: Denis
        Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt
        Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal, Daniel
        Migault, Anna Johnston, Tero Kivinen, and Travis Finkenauer.
      </t>

      <t>
        Thanks to the following people for code to implement
        interoperable exchanges using some of these groups as found in
        this draft: Darren Tucker for OpenSSH and Matt Johnston
        for Dropbear.

        And thanks to Iwamoto Kouichi for information about RLogin,
        Tera Term (ttssh) and Poderosa implementations also adopting
        new Diffie-Hellman groups based on this draft.
      </t>

    </section>

    <!-- Section 6. -->

    <section numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>
        This SSH protocol provides a secure encrypted channel over an
        insecure network.

        It performs server host authentication, key exchange,
        encryption, and integrity checks.

        It also derives a unique session ID that may be used by
        higher-level protocols.

        The key exchange itself generates a shared secret and uses
        the hash function for both the KDF and integrity.
      </t>

      <t>
        Full security considerations for this protocol are provided in <xref
        target="RFC4251" format="default"/> and continue to apply.  In addition,
        the security considerations provided in <xref target="RFC4432"
        format="default"/> apply.

        Note that Forward Secrecy is NOT available with the
        rsa1024-sha1 or rsa2048-sha256 key exchanges.
      </t>

      <t>
        It is desirable to deprecate or disallow key exchange methods
        that are considered weak, weak so they are not in still actively in
        operation when they are broken.
      </t>

      <t>
        A key exchange method is considered weak when the security
        strength is insufficient to match the symmetric cipher or the
        algorithm has been broken.
      </t>

      <t>
        The 1024-bit MODP group used by diffie-hellman-group1-sha1 is
        too small for the symmetric ciphers used in SSH.
      </t>

      <t>
        MODP groups with a modulus size less than 2048 bits are too
        small for the symmetric ciphers used in SSH.

        If the diffie-hellman-group-exchange-sha256 or
        diffie-hellman-group-exchange-sha1 key exchange method is
        used, the modulus size of the MODP group used needs to be at
        least 2048 bits.
      </t>

      <t>
        At this time, the rsa1024-sha1 key exchange is too small for
        the symmetric ciphers used in SSH.
      </t>

      <t>
        The use of SHA-1 for use with any key exchange may not yet be
        completely broken, but it is time to retire all uses of this
        algorithm as soon as possible.
      </t>

      <t>
        The diffie-hellman-group14-sha1 algorithm is not yet
        completely deprecated.

        This is to provide a practical transition from the MTI
        algorithms to a new one.

        However, it would be best to only be used as a last resort in key
        exchange negotiations.

        All key exchange methods using the SHA-1 hash are to be
        considered as deprecated.
      </t>

    </section>

    <!-- Section 7. -->

    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>
        IANA is requested to add has added a new column to the "Key Exchange Method Names"
        registry <xref target="IANA-KEX" target="IANA-SSH" format="default"/> with the heading
        "OK to Implement", Implement" and to annotate annotated entries therein with the
        implementation guidance provided in section 4 <xref target="key_ex_method"/>,
        "Summary Guidance for Implementation of Key Exchange Method Names
        Implementation" Names", in
        this document.  IANA also added entries for ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, and added references to <xref target="RFC4462"/> and <xref target="RFC8732"/> for gss-gex-sha1-*, gss-group1-sha1-*, gss-group14-sha1-*, diffie-hellman-group-exchange-sha1, and diffie-hellman-group-exchange-sha256.  A summary may be found in Table 12 <xref
        target="iana_key_exchange"/> in section 4. <xref target="key_ex_method"/>.  IANA is additionally requested to include
        has also included this document as an additional registry reference
        for the

        with the suggested implementation guidance provided in
        section 4 "Summary Guidance <xref
        target="key_ex_method"/> of this document and added a note indicating the following:</t>

<blockquote>OK to Implement guidance entries for Key Exchange Method Names
        Implementation" registrations that pre-date [RFC9142] are found in this document.

        <xref target="IANA-KEX" format="default"/>

        registry.

        Registry Table 12 in Section 4 of [RFC9142].</blockquote>

  <t>Registry entries
        annotated with "MUST NOT" "<bcp14>MUST NOT</bcp14>" are considered disallowed.
        Registry entries annotated with "SHOULD NOT" "<bcp14>SHOULD NOT</bcp14>" are
        deprecated and may be disallowed in the future.
      </t>

    </section>

  </middle>

  <back>

    <!-- Section 8. -->

    <references>
      <name>References</name>

      <!-- Section 8.1. -->

      <references>
        <name>Normative References</name>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4250.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8268.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8270.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8308.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8731.xml"/>

      </references>

      <!-- Section 8.2. -->

      <references>
        <name>Informative References</name>

        <!-- Here we use entities that we defined at the beginning. -->

        <reference
            anchor="IANA-KEX"
            target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16">
            anchor="IANA-SSH"
            target="https://www.iana.org/assignments/ssh-parameters/">
          <front>
            <title>Secure Shell (SSH) Protocol Parameters:
            Key Exchange Method Names</title> Parameters</title>
            <author fullname="IANA">
              <organization>Internet Assigned Numbers Authority (IANA)
              </organization>
            </author>
          </front>
        </reference>

 <reference
            anchor="NIST.FIPS.202"
            >

          <front>
            <title>
              SHA-3 Standard: Permutation-Based Hash and
              Extendable-Output Functions
            </title>
            <author>
              <organization>
                National Institute of Standards and Technology
              </organization>
            </author>
            <date month="July" year="2021"/> year="2015" month="August"/>
          </front>
          <refcontent>FIPS PUB 202</refcontent>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>

        <reference
            anchor="NIST.SP.800-57pt1r5"
            target="https://doi.org/10.6028/NIST.SP.800-57pt1r5">
	    >

          <front>
            <title>
              Recommendation for Key Management - Management: Part 1 - General
            </title>
            <author initials="E" surname="Barker" fullname="Elaine Barker">
              <organization>
                National Institute of Standards and Technology (NIST)
              </organization>
            </author>
            <date year="2020" month="may"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
        </reference>

        <reference
            anchor="NIST.SP.800-107r1"
            target="https://doi.org/10.6028/NIST.SP.800-107r1"> anchor="NIST.SP.800-107r1">
          <front>
            <title>
              Recommendation for applications using approved hash algorithms
            </title>
            <author initials="Q" surname="Dang" fullname="Quynh Dang">
              <organization>
                National Institute of Standards and Technology (NIST)
              </organization>
            </author>
            <date year="2012" month="August"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-107r1"/>
        </reference>

	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2409.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4419.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4432.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4462.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8031.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8732.xml"/>

        <reference
            anchor="TRANS-COLL"
            target="https://hal.inria.fr/hal-01244855/document">
            anchor="TRANSCRIPTION">
          <front>
              <title>
                Transcript Collision Attacks:
                Breaking Authentication in TLS, IKE, and SSH
              </title>
              <author fullname="Karthikeyan Bhargavan">
              </author>
              <author fullname="Gaeutan Leurent">
              </author>
<date month="February" year="2016"/>
          </front>
            <seriesInfo
                name="Network
          <refcontent>Network and Distributed System Security Symposium – NDSS 2016, Feb 2016, San Diego, United States."
                value="10.14722/ndss.2016.23418 . hal-01244855"/> (NDSS)</refcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>

	</reference>

      </references>
    </references>

    <!-- Change Log

v00 2015-12-10  MDB   Initial version

v01 2015-12-10  MDB   Fix SHA1 -> SHA-1 for the name of the algorithm.
Add recommendation that DH-group14-sha256 be
in the negotiation list before DH-group14-sha1.

v02 2016-02-12  MDB   List all of the key exchange methods currently
listed in the IANA registry for Secure Shell.
Update the rationale.

v03 2016-02-13  MDB   Adopt some feedback from the list.

v04 2016-02-14  MDB   Update Title to include the text 'Secure Shell'
Drop references to group15 and group17. Fix text
to use group16 and group18.

v05 2016-02-19  MDB   Demote ecdh-sha2-nistp384 to SHOULD from MUST.
Reference safecurves.cr.yp.to as justification.

v06 2016-03-01  MDB   Clarify RFC5656 SSH ECC MUST requirements.
Update to I-D.draft-josefsson-ssh-curves-04.
Add acknowledgements section.
v00 2016-03-07  MDB   Rename as draft-ietf-curdle-ssh-kex-sha2-00
from draft-baushke-ssh-dh-group-sha2-06
v01 2016-03-08  MDB   Reference new draft-ietf-curdle-ssh-curves-00.xml
instead of draft-josefsson-ssh-curves-04.xml
v02 2016-03-08  MDB   Problems with the -01 upload occurred.

v03 2015-03-14  MDB   Clear up abstract and implementation text on
advice of Daniel Migault. Use new title too.

v04 2016-09-05  MDB   Peter Gutman suggests that the embedded world
needs DH-2048+SHA-256 for performance issues.
denis bider requests that entries be made for
both Group 15 and Group 17. Group 15 is also
explicitly referenced in the CNSA Suite.

v05 2016-09-20  MDB   Split the MODP implementation to
draft-ietf-curdle-ssh-modp-dh-sha2 and add gss-*
entries

    <section numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t>
        Thanks to the table. Use 'SHOULD NOT' following people for
'ecmqv-sha2' per suggestion by Damien Miller.
Add clarity to GSS-API SHOULD requirements.
Adjust texttable entries.

v06 2017-03-27  MDB   Point to the GSS Keyex SHA2 draft given in
draft-ssorce-gss-keyex-sha2-00.
Remove some left-over MODP text.
General reformatting.

v07 2017-03-27  MDB   Update references.

v08 2017-04-16  MDB   Clean up nits.

v09 2017-07-17  MDB   Input from Tero Kivinen and IETF meeting minutes.
Try to clear up confusion by listing all known
Kex methods and explicitly providing information
on why they are MUST, SHOULD, MAY, SHOULD NOT,
or MUST NOT implement.

v11 2018-02-24 MDB    Address Eric Rescorla comments.

v11 2020-07-12 MDB    Update references and guidance. Add a few key
exchanges that are in the IANA table, but were
not present in previous versions.

v12 2020-07-31 MDB    Convert from v2 to v3 of the IETF RFC xml form.

v12 2020-11-23 MDB    Re-ordered sections review and rewrote most of the
document.

v13 2021-01-14 MDB    Add a larger list of RFCs comments: <contact
        fullname="Denis Bider"/>, <contact fullname="Peter Gutmann"/>,
        <contact fullname="Damien Miller"/>, <contact fullname="Niels
        Moeller"/>, <contact fullname="Matt Johnston"/>, <contact
        fullname="Iwamoto Kouichi"/>, <contact fullname="Simon Josefsson"/>,
        <contact fullname="Dave Dugal"/>, <contact fullname="Daniel
        Migault"/>, <contact fullname="Anna Johnston"/>, <contact
        fullname="Tero Kivinen"/>, and <contact fullname="Travis
        Finkenauer"/>.
      </t>

      <t>
        Thanks to the updates="" list.
                      for Benjamin Kaduk, Tero Kivinen, Hubert Kario,
                      and Simo Sorce.

 Key Exchange Method Name             | pre draft | Implement

 curve25519-sha256                    | -         | SHOULD
 curve448-sha512                      | -         | MAY
 diffie-hellman-group-exchange-sha1   | -         | SHOULD NOT
 diffie-hellman-group-exchange-sha256 | -         | MAY
 diffie-hellman-group1-sha1           | MUST      | SHOULD NOT
 diffie-hellman-group14-sha1          | MUST      | MAY
 diffie-hellman-group14-sha256        | -         | MUST
 diffie-hellman-group15-sha512        | -         | MAY
 diffie-hellman-group16-sha512        | -         | SHOULD
 diffie-hellman-group17-sha512        | -         | MAY
 diffie-hellman-group18-sha512        | -         | MAY
 ecdh-sha2-*                          | MAY       | MAY
 ecdh-sha2-nistp256                   | MUST      | SHOULD
 ecdh-sha2-nistp384                   | MUST      | SHOULD
 ecdh-sha2-nistp521                   | MUST      | SHOULD
 ecmqv-sha2                           | MAY       | MAY
 ext-info-c                           | SHOULD    | SHOULD
 ext-info-s                           | SHOULD    | SHOULD
 gss-                                 | reserved  | reserved
 gss-curve25519-sha256-*              | SHOULD    | SHOULD
 gss-curve448-sha512-*                | MAY       | MAY
 gss-gex-sha1-*                       | SHOULD NOT| SHOULD NOT
 gss-group1-sha1-*                    | SHOULD NOT| SHOULD NOT
 gss-group14-sha256-*                 | SHOULD    | SHOULD
 gss-group15-sha512-*                 | MAY       | MAY
 gss-group16-sha512-*                 | SHOULD    | MAY
 gss-group17-sha512-*                 | MAY       | MAY
 gss-group18-sha512-*                 | MAY       | MAY
 gss-nistp256-sha256-*                | SHOULD    | SHOULD
 gss-nistp384-sha384-*                | MAY       | MAY
 gss-nistp521-sha512-*                | MAY       | MAY
 rsa1024-sha1                         | MAY       | MUST NOT
 rsa2048-sha256                       | MAY       | MAY

v14 2021-02-10 MDB    Address AD comments from Benjamin Kaduk.

v15 2021-03-17 MDB    - Address IANA issue from Sabrina Tanamal.
                      - The IANA section needs to incorporate
                        information from Table 6 in section 4.
                      - Add XML comments for each table. Add RFC8270
                        references following people for RFC4419 entries.
                      - Removed SHOULD keyword from 1.2.2.
                      - Revised section 1.2.3 to avoid "sufficient"
                        security.
                      - Section 1.2.3 provide more details.
                      - section 3.1 provide better guidance on
                        retaining diffie-hellman-group14-sha1
                      - Avoid 'only one which is more secure' and
                        provide a note concerning SHA-3
                      - Drop "All of the NISTP curves named therein
                        are mandatory code to implement if any of that RFC
                        is implemented." text.
                      - Augment security considerations.
                      - Augment Table 7 for IANA.
                      - Moved hash discussions after FFC, ECC, IFC
                        elements.
                      - Add a few more Ben Kaduk suggested changes.

v16 2021-04-15 MDB    - Update author organization and email address.
                      - Incoprorate comments from James Ralston and
                        Ben Kaduk.

v17 2021-04-12 MDB    - Update author organization and email address.

v18 2021-04-22 MDB    - Simon Tatham <anakin@pobox.com> issue in 3.1.2
    2021-05-12 MDB    - Ben Kaduk suggested changes.

V19 2021-06-25 MDB    - Ben Kaduk suggested changes.

V20 2021-07-16 MDB    - Ben Kaduk suggested changes for IANA section 7.
    through
    2021-07-28 MDB    - Address other comments made on the -19 draft.

  - Lars Eggert <lars@eggert.org>: section 1 nit
    s/against SHA-1 and/against SHA1, and/

      Changed sentence to "Attacks against SHA-1 are collision attacks
      that usually rely on human help, rather than a pre-image attack."
      DONE.

  - Roman Danyliw <rdd@cert.org>: section 1
     s/sha1, sha256, sha384, and sha512/SHA-1, SHA-256, SHA-384, and
     SHA-512/

       I have added a paragraph:
        Various RFCs use different spellings and capitalizaitons for
        the hashing function and encryption function names.
        For the purpose of this document, the following are equivalent
        names: sha1, SHA1, and SHA-1; sha256, SHA256, and SHA2-256;
        sha384, SHA384, and SHA2-384; sha512, SHA512, and SHA2-512;
        aes128 and AES128; aes192 and AES192; aes256 and AES256.
       DONE.

  - Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
    I didn't find this correct for the all the MAY in the table 12. interoperable
        exchanges using some MAY also remains MAY.

      Added sentence: "Some recommendations will be unchanged, but are
      included for completeness."
      DONE.

  - Lars Eggert <lars@eggert.org>: update section 1.1 update term
    "man" to an alternative.
  - Martin Duke <martin.h.duke@gmail.com>: section 1.1
    s/man in the middle/on-path attacker/
  - Roman Danyliw <rdd@cert.org>: section 1.1
    s/man in the middle/on path attacker/

      Changed to "on-path attacker"
      DONE.

  - Lars Eggert <lars@eggert.org>: update section 1.1 "but is is"
    nit.
  - Lars Eggert <lars@eggert.org>: update section 1.1 "but it be"
    nit. s/but it be/but it is/
  - Roman Danyliw <rdd@cert.org>: section 1.1
    s/is is/it is/
  - Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
    s/but is is/but it is/

      Changed to "it is"
      DONE.

  - Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
    Should this be modified to use normative language?
    "It is suggested " -> "It is RECOMMENDED "

      Normative language should not exist in the introduction.
      Rejected modified language.

  - Martin Duke <martin.h.duke@gmail.com>: section 1.1 "It is suggested
    that the minimum secure hashing function that should be used for
    key exchange methods is SHA2-256"

    After the previous sentence just went to the effort of defining
    the security strength of the SHA-* algorithms by bits, is there a
    reason the minimum strength baseline is framed as an algorithm
    name rather than a number of bits?

      Changed to
          It is suggested that the minimum secure hashing function
          that should be used for key exchange methods is SHA2-256
          with 128 bits of security strength. Other hashing functions
          may also have the same number of bits of security strength,
          but none are as yet defined in an RFC for use in a KEX for
          SSH.
      DONE.

  - John Scudder <jgs@juniper.net>: update section 1.2
    s/It is desirable for/It is desirable that/

      DONE.

  - Roman Danyliw <rdd@cert.org>: section 1.2.2
    s/sha256/SHA-256/
    s/aes128/AES-128/
    s/aes192/AES-192/

      Addressed with a section 1 paragraph.

  - Roman Danyliw <rdd@cert.org>: section 1.2.2
    s/Cipher/cipher/

      DONE.

  - Lars Eggert <lars@eggert.org>: section 1.2.2
    s/RSA 1024 bit/RSA 1024-bit/
    s/RSA 2048 bit/RSA 2048-bit/g

      DONE.

  - Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>: section 3:
   Can we stick to one way of referencing the same document? either
   "this memo" or "this document"? we have three paragraphs
   referencing the same in three different ways.

     I replaced 'memo' with 'document'
     DONE.

  - Martin Duke <martin.h.duke@gmail.com>: section 3.1.1 Unable to
    parse "is a reasonable hash" Ben Kaduk addressed this comment.

      To partially address this comment, I have added the following text
      to section 3.1 to try to clear up the confusion.

        RFC4253 section 7.2 "Output of Key Exchange" defines
        generation of a shared secret K (really the output of the KDF)
        and an exchange key hash H. Each key exchange method uses a
        specified HASH function which must be the same for both key
        exchange and Key Derivation. H is used for key exchange
        integrity across the SSH session these groups as it is computed only once.
        It is noted at the end of the 7.2 section that "This process
        will lose entropy if the amount of entropy found in K is larger than
        the internal state size of HASH." so care must be taken that
        the hashing algorithm used is well chosen ("reasonable") for
        the key exchange algorithms being used.
      DONE.

  - Martin Duke <martin.h.duke@gmail.com>: section 3.1.1 Unable to
    parse "is a reasonable hash" Ben Kaduk addressed this comment.
  - Lars Eggert <lars@eggert.org>: section 3.1.1 nit usage error
    "as well as" use "and" after "both"

    Used this replacement text:

            SHA2-256 is a reasonable hash document: <contact
        fullname="Darren Tucker"/> for use in both the KDF and
            session integrity. It is reasonable for both gss and
            non-gss uses of curve25519 key exchange methods.

    ADDRESSED.

  - Lars Eggert <lars@eggert.org>: update section 3.1.1 update term
    "traditional" to an alternative.

      Changed "traditional elliptic curves" to "the patented elliptic
      curve parameters purchased by NIST for the general public to use
      and described in RFC5656."
      DONE.

  - Martin Duke <martin.h.duke@gmail.com>: section 3.1.2 Unable to
    parse "is a reasonable hash" Ben Kaduk addressed this comment.

      I have added the following text to section 3.1 to try to clear up
      the confusion.

        RFC4253 section 7.2 "Output of Key Exchange" defines
        generation of a shared secret K (really the output of the KDF)
        and an exchange key hash H. Each key exchange method uses a
        specified HASH function which must be the same for both key
        exchange OpenSSH and Key Derivation. H is used for key exchange
        integrity across the SSH session as it is computed only once.
        It is noted at the end of the 7.2 section that "This process
        will lose entropy if the amount of entropy in K is larger than
        the internal state size of HASH." so care must be taken that
        the hashing algorithm used is well chosen ("reasonable") <contact fullname="Matt
        Johnston"/> for
        the key exchange algorithms being used.
      DONE.

  - Roman Danyliw <rdd@cert.org>: section 3.2.1
    s/4K/4000/

      DONE.

  - John Scudder <jgs@juniper.net>: update section 3.2.2
    spell out MTI on first use. Use the abbreviation in section 3.4.

      DONE.

  - Lars Eggert <lars@eggert.org>: section 3.2.2 nit usage error
    "as well as" use "and" after "both"

      I think you meant section 3.1.2? I have updated Dropbear.

        And thanks to

            SHA2-512 is a reasonable hash for use in both the KDF and
            session integrity. It is reasonable <contact fullname="Iwamoto Kouichi"/> for both gss and
            non-gss uses of curve448 key exchange methods.

      ADDRESSED.

  - Lars Eggert <lars@eggert.org>: section 3.2.2 nit usage error
    s/laying around/lying around/

      DONE

  - Roman Danyliw <rdd@cert.org>: section 3.4
    This section notes that some legacy situations would find
    group14 useful.  Could you elaborate on that situation?

     I have added:

          ", such as small hardware IOT
          devices which have insufficient compute and memory resources
          to use larger MODP groups before a timeout of the session
          occurs."
     DONE

  - Roman Danyliw <rdd@cert.org>: section 3.4
    s/key exchanges methods/key exchange methods/

      DONE.

  - Lars Eggert <lars@eggert.org>: section 4, paragraph 3 "in an"
    was "and" or "any" intended?

      "in any" was intended.
      DONE.

  - Lars Eggert <lars@eggert.org>: section 4, paragraph 3 "weak so"
    may need a comma before "so"

      DONE.

  - Lars Eggert <lars@eggert.org>: Convert http:// to https:// where
    possible.

      DONE.

  - John Scudder <jgs@juniper.net>: desires general guidance in section
    3 information about minimal properties a method should have to qualify for
    MAY, vs SHOULD NOT or MUST NOT.

      DONE.

  - Roman Danyliw <rdd@cert.org>: table 1, 2, 4, 5 need to have a
    citation on the basis of the estimated security strengths
    * Table 1: NIST 800-57Part1R5, Section 5.6.1.1
    (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)

      I have added a reference to RFC4086 for triple-DES and aes128
      strength as well as "various governmental and cryptographic
      sources." to try to avoid using NIST URLs or DOIs which are not
      entirely trusted by non-US implementers and administrators.

      DOI: 10.6028/NIST.SP.800-57pt1r5

      DONE.

    * Table 2: NIST 800-107r1 Section 4
    (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf); RLogin,
        Tera Term (ttssh), and Poderosa implementations also note that adopting
        new Diffie-Hellman groups based on this security strength is collision resistance

      DOI: 10.6028/NIST.SP.800-107r1

      I noted for collision resistance.

          Table 2 provides a summary of security strength for hashing
          functions for collision resistance.

      DONE.

    * Table 3: RFC7748 for Curve25519 and Curve448; NIST curves is ??

          NIST curve strengths are in RFC5656.

    * Table 5: NIST 800-57Part1R5, Section 5.6.1.1
    (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)

    DOI: 10.6028/NIST.SP.800-57pt1r5

  - Update directions to IANA in section 7 per Benjamin Kaduk
    <kaduk@mit.edu>.
    DONE.

    --> document.
      </t>

    </section>

  </back>
</rfc>