rfc9142-mark.original   rfc9142-mark.txt 
skipping to change at line 116 skipping to change at line 116
The hashing algorithms used by key exchange methods described in this The hashing algorithms used by key exchange methods described in this
document are: sha1, sha256, sha384, and sha512. In many cases, the document are: sha1, sha256, sha384, and sha512. In many cases, the
hash name is explicitly appended to the public key exchange algorithm hash name is explicitly appended to the public key exchange algorithm
name. However, some of them are implicit and defined in the RFC that name. However, some of them are implicit and defined in the RFC that
defines the key exchange algorithm name. defines the key exchange algorithm name.
Various RFCs use different spellings and capitalizations for the Various RFCs use different spellings and capitalizations for the
hashing function and encryption function names. For the purpose of hashing function and encryption function names. For the purpose of
this document, the following are equivalent names: sha1, SHA1, and this document, the following are equivalent names: sha1, SHA1, and
SHA-1; sha256, SHA256, and SHA2-256; sha384, SHA384, and SHA2-384; sha1; sha256, SHA256, and SHA2-256; sha384, SHA384, and SHA2-384; and
and sha512, SHA512, and SHA2-512. sha512, SHA512, and SHA2-512.
For the purpose of this document, the following are equivalent: For the purpose of this document, the following are equivalent:
aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256, aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256,
AES256, and AES-256. AES256, and AES-256.
It is good to try to match the security strength of the public key It is good to try to match the security strength of the public key
exchange algorithm with the security strength of the symmetric exchange algorithm with the security strength of the symmetric
cipher. cipher.
There are many possible symmetric ciphers available with multiple There are many possible symmetric ciphers available with multiple
skipping to change at line 153 skipping to change at line 153
| aes256 (cbc, ctr, gcm) | 256 bits | | aes256 (cbc, ctr, gcm) | 256 bits |
+------------------------+-----------------------------+ +------------------------+-----------------------------+
Table 1: Symmetric Cipher Security Strengths Table 1: Symmetric Cipher Security Strengths
The following subsections describe how to select each component of The following subsections describe how to select each component of
the key exchange. the key exchange.
1.1. Selecting an Appropriate Hashing Algorithm 1.1. Selecting an Appropriate Hashing Algorithm
The SHA-1 hash is in the process of being deprecated for many The sha1 hash is in the process of being deprecated for many reasons.
reasons.
There have been attacks against SHA-1, and it is no longer strong There have been attacks against sha1, and it is no longer strong
enough for SSH security requirements. Therefore, it is desirable to enough for SSH security requirements. Therefore, it is desirable to
move away from using it before attacks become more serious. move away from using it before attacks become more serious.
The SHA-1 hash provides for approximately 80 bits of security The sha1 hash provides for approximately 80 bits of security
strength. This means that the shared key being used has at most 80 strength. This means that the shared key being used has at most 80
bits of security strength, which may not be sufficient for most bits of security strength, which may not be sufficient for most
users. users.
For purposes of key exchange methods, attacks against SHA-1 are For purposes of key exchange methods, attacks against sha1 are
collision attacks that usually rely on human help rather than a pre- collision attacks that usually rely on human help rather than a pre-
image attack. The SHA-1 hash resistance against a second pre-image image attack. The sha1 hash resistance against a second pre-image is
is still at 160 bits, but SSH does not depend on second pre-image still at 160 bits, but SSH does not depend on second pre-image
resistance but rather on chosen-prefix collision resistance. resistance but rather on chosen-prefix collision resistance.
Transcript Collision attacks are documented in [TRANSCRIPTION]. This Transcript Collision attacks are documented in [TRANSCRIPTION]. This
paper shows that an on-path attacker does not tamper with the Diffie- paper shows that an on-path attacker does not tamper with the Diffie-
Hellman values and does not know the connection keys. The attack 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 could be used to tamper with both I_C and I_S (as defined in
Section 7.3 of [RFC4253]) and might potentially be able to downgrade Section 7.3 of [RFC4253]) and might potentially be able to downgrade
the negotiated ciphersuite to a weak cryptographic algorithm that the the negotiated ciphersuite to a weak cryptographic algorithm that the
attacker knows how to break. attacker knows how to break.
These attacks are still computationally very difficult to perform, These attacks are still computationally very difficult to perform,
but it is desirable that any key exchange using SHA-1 be phased out but it is desirable that any key exchange using sha1 be phased out as
as soon as possible. soon as possible.
If there is a need for using SHA-1 in a key exchange for If there is a need for using sha1 in a key exchange for
compatibility, it would be desirable to list it last in the compatibility, it would be desirable to list it last in the
preference list of key exchanges. preference list of key exchanges.
Use of the SHA-2 family of hashes found in [RFC6234] rather than the Use of the SHA-2 family of hashes found in [RFC6234] rather than the
SHA-1 hash is strongly advised. sha1 hash is strongly advised.
When it comes to the SHA-2 family of secure hashing functions, When it comes to the SHA-2 family of secure hashing functions, sha256
SHA2-256 has 128 bits of security strength; SHA2-384 has 192 bits of has 128 bits of security strength; sha384 has 192 bits of security
security strength; and SHA2-512 has 256 bits of security strength. strength; and sha512 has 256 bits of security strength. It is
It is suggested that the minimum secure hashing function used for key suggested that the minimum secure hashing function used for key
exchange methods should be SHA2-256 with 128 bits of security exchange methods should be sha256 with 128 bits of security strength.
strength. Other hashing functions may also have the same number of Other hashing functions may also have the same number of bits of
bits of security strength, but none are as yet defined in any RFC for security strength, but none are as yet defined in any RFC for use in
use in a KEX for SSH. a KEX for SSH.
To avoid combinatorial explosion of key exchange names, newer key To avoid combinatorial explosion of key exchange names, newer key
exchanges are generally restricted to *-sha256 and *-sha512. The exchanges are generally restricted to *-sha256 and *-sha512. The
exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which
are defined to use SHA2-384 for the hash algorithm. are defined to use sha384 for the hash algorithm.
Table 2 provides a summary of security strength for hashing functions Table 2 provides a summary of security strength for hashing functions
for collision resistance. You may consult [NIST.SP.800-107r1] for for collision resistance. You may consult [NIST.SP.800-107r1] for
more information on hash algorithm security strength. more information on hash algorithm security strength.
+===========+=============================+ +===========+=============================+
| Hash Name | Estimated Security Strength | | Hash Name | Estimated Security Strength |
+===========+=============================+ +===========+=============================+
| sha1 | 80 bits (before attacks) | | sha1 | 80 bits (before attacks) |
+-----------+-----------------------------+ +-----------+-----------------------------+
skipping to change at line 412 skipping to change at line 411
more device resources than many administrators and/or developers need more device resources than many administrators and/or developers need
are to be allowed ("MAY"). (Eventually, some of these methods could are to be allowed ("MAY"). (Eventually, some of these methods could
be moved by consensus to "SHOULD" to increase interoperability and be moved by consensus to "SHOULD" to increase interoperability and
security.) Methods that are not "weak" and have implementation security.) Methods that are not "weak" and have implementation
consensus are encouraged ("SHOULD"). There needs to be at least one consensus are encouraged ("SHOULD"). There needs to be at least one
consensus method promoted to a status of mandatory to implement consensus method promoted to a status of mandatory to implement
(MTI). This should help to provide continued interoperability even (MTI). This should help to provide continued interoperability even
with the loss of one of the now disallowed MTI methods. with the loss of one of the now disallowed MTI methods.
For this document, 112 bits of security strength is the minimum. Use For this document, 112 bits of security strength is the minimum. Use
of either or both of SHA-1 and RSA 1024 bits at an approximate 80 of either or both of sha1 and RSA 1024 bits at an approximate 80 bits
bits of security fall below this minimum and should be deprecated and of security fall below this minimum and should be deprecated and
moved to disallowed as quickly as possible in configured deployments moved to disallowed as quickly as possible in configured deployments
of SSH. It seems plausible that this minimum may be increased over of SSH. It seems plausible that this minimum may be increased over
time, so authors and administrators may wish to prepare for a switch time, so authors and administrators may wish to prepare for a switch
to algorithms that provide more security strength. to algorithms that provide more security strength.
3.1. Elliptic Curve Cryptography (ECC) 3.1. Elliptic Curve Cryptography (ECC)
The Elliptic Curve (EC) key exchange algorithms used with SSH include The Elliptic Curve (EC) key exchange algorithms used with SSH include
the ECDH and EC Menezes-Qu-Vanstone (ECMQV). the ECDH and EC Menezes-Qu-Vanstone (ECMQV).
skipping to change at line 437 skipping to change at line 436
Section 6 of [RFC5656]. There are key exchange mechanisms based on Section 6 of [RFC5656]. There are key exchange mechanisms based on
the Generic Security Service Application Program Interface (GSS-API) the Generic Security Service Application Program Interface (GSS-API)
that use these curves as well that have a "gss-" prefix. that use these curves as well that have a "gss-" prefix.
3.1.1. curve25519-sha256 and gss-curve25519-sha256-* 3.1.1. curve25519-sha256 and gss-curve25519-sha256-*
Curve25519 is efficient on a wide range of architectures with Curve25519 is efficient on a wide range of architectures with
properties that allow higher-performance implementations compared to properties that allow higher-performance implementations compared to
the patented elliptic curve parameters purchased by NIST for the the patented elliptic curve parameters purchased by NIST for the
general public to use as described in [RFC5656]. The corresponding general public to use as described in [RFC5656]. The corresponding
key exchange methods use SHA2-256 defined in [RFC6234]. SHA2-256 is key exchange methods use sha256 defined in [RFC6234]. sha2 is a
a reasonable hash for use in both the KDF and session integrity. It reasonable hash for use in both the KDF and session integrity. It is
is reasonable for both gss and non-gss uses of curve25519 key reasonable for both gss and non-gss uses of curve25519 key exchange
exchange methods. These key exchange methods are described in methods. These key exchange methods are described in [RFC8731] and
[RFC8731] and [RFC8732] and are similar to the IKEv2 key agreement [RFC8732] and are similar to the IKEv2 key agreement described in
described in [RFC8031]. The curve25519-sha256 key exchange method [RFC8031]. The curve25519-sha256 key exchange method has multiple
has multiple implementations and SHOULD be implemented. The gss- implementations and SHOULD be implemented. The gss-
curve25519-sha256-* key exchange method SHOULD also be implemented curve25519-sha256-* key exchange method SHOULD also be implemented
because it shares the same performance and security characteristics because it shares the same performance and security characteristics
as curve25519-sha256. as curve25519-sha256.
Table 6 contains a summary of the recommendations for Table 6 contains a summary of the recommendations for
curve25519-based key exchanges. curve25519-based key exchanges.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
skipping to change at line 466 skipping to change at line 465
| gss-curve25519-sha256-* | SHOULD | | gss-curve25519-sha256-* | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
Table 6: Curve25519 Implementation Table 6: Curve25519 Implementation
Guidance Guidance
3.1.2. curve448-sha512 and gss-curve448-sha512-* 3.1.2. curve448-sha512 and gss-curve448-sha512-*
Curve448 provides more security strength than curve25519 at a higher Curve448 provides more security strength than curve25519 at a higher
computational and bandwidth cost. The corresponding key exchange computational and bandwidth cost. The corresponding key exchange
methods use SHA2-512 defined in [RFC6234]. SHA2-512 is a reasonable methods use sha512 defined in [RFC6234]. SHA2-512 is a reasonable
hash for use in both the KDF and session integrity. It is 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. for both gss and non-gss uses of curve448 key exchange methods.
These key exchange methods are described in [RFC8731] and [RFC8732] These key exchange methods are described in [RFC8731] and [RFC8732]
and are similar to the IKEv2 key agreement described in [RFC8031]. and are similar to the IKEv2 key agreement described in [RFC8031].
The curve448-sha512 key exchange method MAY be implemented. The gss- The curve448-sha512 key exchange method MAY be implemented. The gss-
curve448-sha512-* key exchange method MAY also be implemented because curve448-sha512-* key exchange method MAY also be implemented because
it shares the same performance and security characteristics as it shares the same performance and security characteristics as
curve448-sha512. curve448-sha512.
Table 7 contains a summary of the recommendations for curve448-based Table 7 contains a summary of the recommendations for curve448-based
skipping to change at line 551 skipping to change at line 550
[RFC4419] defines two key exchange methods that use a random [RFC4419] defines two key exchange methods that use a random
selection from a set of pre-generated moduli for key exchange: the selection from a set of pre-generated moduli for key exchange: the
diffie-hellman-group-exchange-sha1 method and the diffie-hellman- diffie-hellman-group-exchange-sha1 method and the diffie-hellman-
group-exchange-sha256 method. Per [RFC8270], implementations SHOULD group-exchange-sha256 method. Per [RFC8270], implementations SHOULD
use a MODP group whose modulus size is equal to or greater than 2048 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 bits. MODP groups with a modulus size less than 2048 bits are weak
and MUST NOT be used. and MUST NOT be used.
The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT
be used. This method uses SHA-1, which is being deprecated. be used. This method uses sha1, which is being deprecated.
The diffie-hellman-group-exchange-sha256 key exchange method MAY be The diffie-hellman-group-exchange-sha256 key exchange method MAY be
used. This method uses SHA-256, which is reasonable for MODP groups used. This method uses SHA-256, which is reasonable for MODP groups
less than 4096 bits. less than 4096 bits.
Care should be taken in the pre-generation of the moduli P and 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 generator G such that the generator provides a Q-ordered subgroup of
P. Otherwise, the parameter set may leak one bit of the shared P. Otherwise, the parameter set may leak one bit of the shared
secret. secret.
skipping to change at line 580 skipping to change at line 579
+--------------------------------------+------------+ +--------------------------------------+------------+
Table 9: FFC Generated MODP Group Implementation Table 9: FFC Generated MODP Group Implementation
Guidance Guidance
3.2.2. FFC Diffie-Hellman Using Named MODP Groups 3.2.2. FFC Diffie-Hellman Using Named MODP Groups
The diffie-hellman-group14-sha256 key exchange method is defined in The diffie-hellman-group14-sha256 key exchange method is defined in
[RFC8268] and represents a key exchange that has approximately 112 [RFC8268] and represents a key exchange that has approximately 112
bits of security strength that matches 3des-cbc symmetric cipher bits of security strength that matches 3des-cbc symmetric cipher
security strength. It is a reasonably simple transition from SHA-1 security strength. It is a reasonably simple transition from sha1 to
to SHA-2, and given that diffie-hellman-group14-sha1 and diffie- SHA-2, and given that diffie-hellman-group14-sha1 and diffie-hellman-
hellman-group14-sha256 share a MODP group and only differ in the hash group14-sha256 share a MODP group and only differ in the hash
function used for the KDF and integrity, it is a correspondingly function used for the KDF and integrity, it is a correspondingly
simple transition from implementing diffie-hellman-group14-sha1 to simple transition from implementing diffie-hellman-group14-sha1 to
implementing diffie-hellman-group14-sha256. Given that diffie- implementing diffie-hellman-group14-sha256. Given that diffie-
hellman-group14-sha1 is being removed from mandatory to implement hellman-group14-sha1 is being removed from mandatory to implement
(MTI) status, the diffie-hellman-group14-sha256 method MUST be (MTI) status, the diffie-hellman-group14-sha256 method MUST be
implemented. The rest of the FFC MODP group from [RFC8268] have a implemented. The rest of the FFC MODP group from [RFC8268] have a
larger number of security bits and are suitable for symmetric ciphers larger number of security bits and are suitable for symmetric ciphers
that also have a similar number of security bits. that also have a similar number of security bits.
Table 10 provides explicit guidance by name. Table 10 provides explicit guidance by name.
skipping to change at line 624 skipping to change at line 623
+-------------------------------+----------+ +-------------------------------+----------+
| gss-group18-sha512-* | MAY | | gss-group18-sha512-* | MAY |
+-------------------------------+----------+ +-------------------------------+----------+
Table 10: FFC Named Group Implementation Table 10: FFC Named Group Implementation
Guidance Guidance
3.3. Integer Factorization Cryptography (IFC) 3.3. Integer Factorization Cryptography (IFC)
The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses
an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does an RSA 1024-bit modulus with a sha1 hash. This key exchange does NOT
NOT meet security requirements. This method MUST NOT be implemented. meet security requirements. This method MUST NOT be implemented.
The rsa2048-sha256 key exchange method is defined in [RFC4432] and The rsa2048-sha256 key exchange method is defined in [RFC4432] and
uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange uses an RSA 2048-bit modulus with a sha256 hash. This key exchange
meets 112-bit minimum security strength. This method MAY be meets 112-bit minimum security strength. This method MAY be
implemented. implemented.
Table 11 provides a summary of the guidance for IFC key exchanges. Table 11 provides a summary of the guidance for IFC key exchanges.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
| rsa1024-sha1 | MUST NOT | | rsa1024-sha1 | MUST NOT |
+--------------------------+----------+ +--------------------------+----------+
| rsa2048-sha256 | MAY | | rsa2048-sha256 | MAY |
+--------------------------+----------+ +--------------------------+----------+
Table 11: IFC Implementation Guidance Table 11: IFC Implementation Guidance
3.4. KDFs and Integrity Hashing 3.4. KDFs and Integrity Hashing
The SHA-1 and SHA-2 family of hashing algorithms are combined with The sha1 and SHA-2 family of hashing algorithms are combined with the
the FFC, ECC, and IFC algorithms to comprise a key exchange method FFC, ECC, and IFC algorithms to comprise a key exchange method name.
name.
The selected hash algorithm is used both in the KDF as well as for The selected hash algorithm is used both in the KDF as well as for
the integrity of the response. the integrity of the response.
All of the key exchange methods using the SHA-1 hashing algorithm All of the key exchange methods using the sha1 hashing algorithm
should be deprecated and phased out due to security concerns for SHA- should be deprecated and phased out due to security concerns for
1, as documented in [RFC6194]. sha1, as documented in [RFC6194].
Unconditionally deprecating and/or disallowing SHA-1 everywhere will Unconditionally deprecating and/or disallowing sha1 everywhere will
hasten the day when it may be simply removed from implementations hasten the day when it may be simply removed from implementations
completely. Leaving partially broken algorithms lying around is not completely. Leaving partially broken algorithms lying around is not
a good thing to do. a good thing to do.
The SHA-2 family of hashes [RFC6234] is more secure than SHA-1. They The SHA-2 family of hashes [RFC6234] is more secure than sha1. They
have been standardized for use in SSH with many of the currently have been standardized for use in SSH with many of the currently
defined key exchanges. defined key exchanges.
Please note that at the present time, there is no key exchange method Please note that at the present time, there is no key exchange method
for Secure Shell that uses the SHA-3 family of secure hashing for Secure Shell that uses the SHA-3 family of secure hashing
functions or the Extendable-Output Functions [NIST.FIPS.202]. functions or the Extendable-Output Functions ([NIST.FIPS.202]).
Prior to the changes made by this document, diffie-hellman- Prior to the changes made by this document, diffie-hellman-
group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie- group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie-
hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit
MODP group) is defined in [RFC3526]. The group1 MODP group with MODP group) is defined in [RFC3526]. The group1 MODP group with
approximately 80 bits of security is too weak to be retained. approximately 80 bits of security is too weak to be retained.
However, rather than jumping from the MTI status to making it However, rather than jumping from the MTI status to making it
disallowed, many implementers suggested that it should transition to disallowed, many implementers suggested that it should transition to
deprecated first and be disallowed at a later time. The group14 MODP deprecated first and be disallowed at a later time. The group14 MODP
group using a sha1 hash for the KDF is not as weak as the group1 MODP group using a sha1 hash for the KDF is not as weak as the group1 MODP
skipping to change at line 836 skipping to change at line 834
MODP groups with a modulus size less than 2048 bits are too small for 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- the symmetric ciphers used in SSH. If the diffie-hellman-group-
exchange-sha256 or diffie-hellman-group-exchange-sha1 key exchange exchange-sha256 or diffie-hellman-group-exchange-sha1 key exchange
method is used, the modulus size of the MODP group used needs to be method is used, the modulus size of the MODP group used needs to be
at least 2048 bits. at least 2048 bits.
At this time, the rsa1024-sha1 key exchange is too small for the At this time, the rsa1024-sha1 key exchange is too small for the
symmetric ciphers used in SSH. symmetric ciphers used in SSH.
The use of SHA-1 for use with any key exchange may not yet be The use of sha1 for use with any key exchange may not yet be
completely broken, but it is time to retire all uses of this completely broken, but it is time to retire all uses of this
algorithm as soon as possible. algorithm as soon as possible.
The diffie-hellman-group14-sha1 algorithm is not yet completely The diffie-hellman-group14-sha1 algorithm is not yet completely
deprecated. This is to provide a practical transition from the MTI 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 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 as a last resort in key exchange negotiations. All key exchange
methods using the SHA-1 hash are to be considered as deprecated. methods using the sha1 hash are to be considered as deprecated.
6. IANA Considerations 6. IANA Considerations
IANA has added a new column to the "Key Exchange Method Names" IANA has added a new column to the "Key Exchange Method Names"
registry [IANA-KEX] with the heading "OK to Implement" and annotated registry [IANA-KEX] with the heading "OK to Implement" and annotated
entries therein with the implementation guidance provided in entries therein with the implementation guidance provided in
Section 4, "Summary Guidance for Implementation of Key Exchange Section 4, "Summary Guidance for Implementation of Key Exchange
Method Names", in this document. IANA also added entries for ecdh- Method Names", in this document. IANA also added entries for ecdh-
sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, and added sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, and added
references to [RFC4462] and [RFC8732] for gss-gex-sha1-*, gss- references to [RFC4462] and [RFC8732] for gss-gex-sha1-*, gss-
 End of changes. 25 change blocks. 
50 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/