idnits 2.17.00 (12 Aug 2021) /tmp/idnits13483/draft-ietf-curdle-ssh-kex-sha2-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4250, updated by this document, for RFC5378 checks: 2002-06-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2020) is 676 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Baushke 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 4250 (if approved) July 13, 2020 5 Intended status: Standards Track 6 Expires: January 14, 2021 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-11 12 Abstract 14 This document is intended to update the recommended set of key 15 exchange methods for use in the Secure Shell (SSH) protocol to meet 16 evolving needs for stronger security. This document updates RFC 17 4250. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 14, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 4 56 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 57 3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 59 3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 5 60 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 5 61 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5 62 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 63 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 6 64 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 6 65 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 6 66 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6 67 3.12. ecdh-sha2-* . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.12.1. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . 6 69 3.12.2. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . 7 70 3.12.3. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . 7 71 3.13. ecmqv-sha2 . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.14. ext-info-c . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.15. ext-info-s . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.16. gss-* . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.16.1. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . 8 76 3.16.2. gss-group1-sha1-* . . . . . . . . . . . . . . . . . 8 77 3.16.3. gss-group14-sha1-* . . . . . . . . . . . . . . . . . 8 78 3.16.4. gss-group14-sha256-* . . . . . . . . . . . . . . . . 9 79 3.16.5. gss-group15-sha512-* . . . . . . . . . . . . . . . . 9 80 3.16.6. gss-group16-sha512-* . . . . . . . . . . . . . . . . 9 81 3.16.7. gss-group17-sha512-* . . . . . . . . . . . . . . . . 9 82 3.16.8. gss-group18-sha512-* . . . . . . . . . . . . . . . . 9 83 3.16.9. gss-nistp256-sha256-* . . . . . . . . . . . . . . . 10 84 3.16.10. gss-nistp384-sha384-* . . . . . . . . . . . . . . . 10 85 3.16.11. gss-nistp521-sha512-* . . . . . . . . . . . . . . . 10 86 3.16.12. gss-curve25519-sha256-* . . . . . . . . . . . . . . 10 87 3.16.13. gss-curve448-sha512-* . . . . . . . . . . . . . . . 10 88 3.17. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 10 89 3.18. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 10 90 4. Selecting an appropriate hashing algorithm . . . . . . . . . 11 91 5. Summary Guidance for Key Exchange Method Names . . . . . . . 11 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 9.2. Informative References . . . . . . . . . . . . . . . . . 16 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Overview and Rationale 102 Secure Shell (SSH) is a common protocol for secure communication on 103 the Internet. In [RFC4253], SSH originally defined two Key Exchange 104 Method Names that MUST be implemented. Over time, what was once 105 considered secure is no longer considered secure. The purpose of 106 this RFC is to recommend that some published key exchanges be 107 deprecated as well as recommending some that SHOULD and one that MUST 108 be adopted. This document updates [RFC4250]. 110 New key exchange methods will use the SHA-2 family of hashes found in 111 [RFC6234] rather than the SHA-1 hash which is in the process of being 112 deprecated for many purposes as no longer providing enough security. 114 SSH uses multiple mathematically hard problems for doing Key 115 Exchange. Finite Field Cryptography (FFC) with "safe primes" for 116 diffie-hellman (DH) key exchange. Elliptic Curve Cryptography (ECC) 117 using NIST prime curves with Elliptic Curve Diffie-Hellman (ECDH) and 118 the similar Curve25519 and Curve448 key exchanges. 120 For FFC, many experts have suggested that a prime field of 2048-bits 121 is the minimum (2048-bits is said to have 112 bits of security and 122 3072-bits is said to have 128 bits of security) allowed and larger 123 sizes up to 8192 bits are considered to be much stronger. The 124 minimum MODP group that MAY be used is the 2048-bit MODP group14. 126 For ECC, many experts have suggested that a 256-bits curve is the 127 minimum allowed (256-bits is said to have 128 bits of security) and 128 larger sizes up to 521-bits are considered to be much stronger 129 (521-bits are considered to have around 256-bits of security). 131 When it comes to Secure Hashing functions, SHA2-256 is said to have 132 128-bits of security SHA2-384 to have 192-bits of security, and 133 SHA2-512 to have 256-bits of security. The older SHA-1 hash is 134 supposed to have about 80-bits of security. The minimum secure 135 hashing function that should be used is SHA2-256 in the year of this 136 RFC. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Key Exchange Methods 148 This memo adopts the style and conventions of [RFC4253] in specifying 149 how the use of data key exchange is indicated in SSH. 151 This RFC also collects Key Exchange Method Names in various existing 152 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 153 [RFC8268], [RFC8731] [RFC8732], and [RFC8308], and provides a 154 suggested suitability for implementation of MUST, SHOULD, SHOULD NOT, 155 and MUST NOT. Any method not explicitly listed MAY be implemented. 157 This document is intended to provide guidance as to what Key Exchange 158 Algorithms are to be considered for new or updated SSH 159 implementations. This document will be superseded when one or more 160 of the listed algorithms are considered too weak to continue to use 161 securely, in which case they will likely be downgraded to one of MAY, 162 SHOULD NOT, or MUST NOT. Or, when newer methods have been analyzed 163 and found to be secure with wide enough adoption, upgrade their 164 recommendation from MAY to SHOULD or MUST. 166 3.1. curve25519-sha256 168 Curve25519 is efficient on a wide range of architectures with 169 properties that allow higher performance implementations compared to 170 traditional elliptic curves. The use of SHA2-256 (also known as 171 SHA-256 and sha256) as defined in [RFC6234] for integrity is a 172 reasonable one for this method. This Key Exchange Method is 173 described in [RFC8731] and is similar to the IKEv2 Key Agreement 174 described in [RFC8031]. This Key Exchange Method has multiple 175 implementations and SHOULD be implemented in any SSH implementation 176 interested in using elliptic curve based key exchanges. 178 3.2. curve448-sha512 180 The Curve448 requires more work than Curve25519. It uses SHA2-512 181 (also known as SHA-512) defined in [RFC6234] for integrity. This Key 182 Exchange Method is described in [RFC8731] and is similar to the IKEv2 183 Key Agreement described in [RFC8031]. This method MAY be 184 implemented. 186 3.3. diffie-hellman-group-exchange-sha1 188 This random selection from a set of pre-generated moduli for key 189 exchange uses SHA-1 as defined in [RFC4419]. However, SHA-1 has 190 security concerns provided in [RFC6194], so it would be better to use 191 a key exchange method which uses a SHA-2 hash as in [RFC6234] for 192 integrity. This key exchange SHOULD NOT be used. 194 3.4. diffie-hellman-group-exchange-sha256 196 This random selection from a set of pre-generated moduli for key 197 exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates 198 implementations avoid any MODP group with less than 2048 bits. Care 199 should be taken in the pre-generation of the moduli P and generator G 200 such that the generator provides a Q-ordered subgroup of P or the 201 parameter set may leak one bit of the shared private key leaving the 202 MODP group half as strong as desired as compared with the number of 203 bits. This key exchange MAY be used. 205 3.5. diffie-hellman-group1-sha1 207 This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group 208 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent 209 security concerns with SHA-1 [RFC6194] and with MODP groups with less 210 than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar2]), this method 211 is considered insecure. This method is being moved from MUST to 212 SHOULD NOT instead of MUST NOT only to allow a transition time to get 213 off of it. There are many old implementations out there that may 214 still need to use this key exchange; it should be removed from server 215 implementations as quickly as possible. 217 3.6. diffie-hellman-group14-sha1 219 This method uses [RFC3526] group14 (a 2048-bit MODP group) which is 220 still a reasonable size. This key exchange group uses SHA-1 which 221 has security concerns [RFC6194]. However, this group is still strong 222 enough and is widely deployed. This method is being moved from MUST 223 to SHOULD to aid in transition to stronger SHA-2 based hashes. This 224 method will transition to SHOULD NOT when SHA-2 alternatives are more 225 generally available. 227 3.7. diffie-hellman-group14-sha256 229 This key exchange method is defined in [RFC8268] and uses the group14 230 (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in 231 [RFC6234] for integrity. This represents the smallest FFC DH key 232 exchange method considered to be secure. It is a reasonably simple 233 transition to move from SHA-1 to SHA-2. This method SHOULD be 234 implemented. 236 3.8. diffie-hellman-group15-sha512 238 This key exchange method is defined in [RFC8268] and uses group15 (a 239 3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 240 [RFC6234] for integrity. This modulus is the minimum required by 241 [CNSA-SUITE]. This method MAY be implemented. 243 3.9. diffie-hellman-group16-sha512 245 This key exchange method is defined in [RFC8268] and uses group16 (a 246 4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 247 [RFC6234] for integrity. The use of FFC DH is well understood and 248 trusted. Adding larger modulus sizes and protecting with SHA2-512 249 should give enough head room to be ready for the next scare that 250 someone has pre-computed it. This method MAY be implemented. 252 3.10. diffie-hellman-group17-sha512 254 This key exchange method is defined in [RFC8268] and uses group17 (a 255 6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 256 [RFC6234] for integrity. The use of this 6144-bit MODP group is 257 going to be slower than what may be desirable. It is provided to 258 help those who wish to avoid using ECC algorithms. This method MAY 259 be implemented. 261 3.11. diffie-hellman-group18-sha512 263 This key exchange method is defined in [RFC8268] and uses group18 (a 264 8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 265 [RFC6234] for integrity. The use of this 8192-bit MODP group is 266 going to be slower than what may be desirable. It is provided to 267 help those who wish to avoid using ECC algorithms. This method MAY 268 be implemented. 270 3.12. ecdh-sha2-* 272 This namespace allows for other curves to be defined for the elliptic 273 curve Diffie Hellman key exchange. At present, there are three 274 members of this namespace They appear in [RFC5656] which are covered 275 below. This set of methods MAY be implemented. 277 3.12.1. ecdh-sha2-nistp256 279 This key exchange method is defined in [RFC5656]. ECDH methods are 280 often implemented because they are smaller and faster than using 281 large FFC DH parameters. However, given [CNSA-SUITE] and 282 [safe-curves], this curve may not be as useful and strong as desired 283 for handling TOP SECRET information for some applications. The SSH 284 development community is divided on this and many implementations do 285 exist. If traditional ECDH key exchange methods are implemented, 286 then this method SHOULD be implemented. 288 It is advisable to match the ECDSA and ECDH algorithms to use the 289 same curve for both. 291 3.12.2. ecdh-sha2-nistp384 293 This key exchange method is defined in [RFC5656]. This ECDH method 294 should be implemented because it is smaller and faster than using 295 large FFC primes with traditional DH. Given [CNSA-SUITE], it is 296 considered good enough for TOP SECRET. However, given 297 [ECDSA-Nonce-Leak], care must be used when using this algorithm. If 298 traditional ECDH key exchange methods are implemented, then this 299 method SHOULD be implemented. 301 Concerns raised in [safe-curves] may mean that this algorithm will 302 need to be downgraded in the future along the other ECDSA NIST Prime 303 curves. 305 3.12.3. ecdh-sha2-nistp521 307 This key exchange method is defined in [RFC5656]. This ECDH method 308 may be implemented because it is smaller and faster than using large 309 FFC DH parameters. It is not listed in [CNSA-SUITE], so it is not 310 currently appropriate for TOP SECRET. It is possible that the 311 mismatch between the 521-bit key and the 512-bit hash could mean that 312 as many as nine bits of this key could be at risk of leaking if 313 appropriate padding measures are not taken. This method MAY be 314 implemented. 316 3.13. ecmqv-sha2 318 This key exchange method is defined in [RFC5656]. This method MAY be 319 implemented. 321 3.14. ext-info-c 323 This key exchange method is defined in [RFC8308]. This method is not 324 actually a key exchange, but proivides a method to provide support 325 for extensions to other Secure Shell negotations. Being able to 326 extend functionality is desirable, This method SHOULD be implemented. 328 3.15. ext-info-s 330 This key exchange method is defined in [RFC8308]. This method is not 331 actually a key exchange, but proivides a method to provide support 332 for extensions to other Secure Shell negotations. Being able to 333 extend functionality is desirable, This method SHOULD be implemented. 335 3.16. gss-* 337 This family of key exchange methods is defined in [RFC4462] and 338 [RFC8732] for the GSS-API key exchange methods. The family of 339 methods MAY be implemented for those who need GSS-API methods. 341 3.16.1. gss-gex-sha1-* 343 This key exchange method is defined in [RFC4462]. This set of 344 ephemerally generated key exchange groups uses SHA-1 which has 345 security concerns [RFC6194]. This key exchange SHOULD NOT be used. 346 It is intended that it move to MUST NOT as soon as the majority of 347 server implementations no longer offer it. It should be removed from 348 server implementations as quickly as possible. 350 3.16.2. gss-group1-sha1-* 352 This key exchange method is defined in [RFC4462]. This method 353 suffers from the same problems of diffie-hellman-group1-sha1. It 354 uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1 355 [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and 356 with MODP groups with less than 2048 bits (see [LOGJAM] and 357 [NIST-SP-800-131Ar2]), this method is considered insecure. This 358 method SHOULD NOT be implemented. It is intended that it move to 359 MUST NOT as soon as the majority of server implementations no longer 360 offer it. It should be removed from server implementations as 361 quickly as possible. 363 3.16.3. gss-group14-sha1-* 365 This key exchange method is defined in [RFC4462]. This generated key 366 exchange groups uses SHA-1 which has security concerns [RFC6194]. If 367 GSS-API key exchange methods are being used, then this one SHOULD be 368 implemented until such time as SHA-2 variants may be implemented and 369 deployed. This method will transition to SHOULD NOT when SHA-2 370 alternatives are more generally available. No other standard 371 indicated that this method was anything other than optional even 372 though it was implemented in all GSS-API systems. This method MAY be 373 implemented. 375 3.16.4. gss-group14-sha256-* 377 This key exchange method is defined in [RFC8732]. This key exchange 378 uses the group14 (a 2048-bit MODP group) along with a SHA-2 379 (SHA2-256) hash. This represents the smallest Finite Field 380 Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered 381 to be secure. It is a reasonably simple transition to move from 382 SHA-1 to SHA-2. If the GSS-API is to be used, then this method 383 SHOULD be implemented. 385 3.16.5. gss-group15-sha512-* 387 This key exchange method is defined in [RFC8732] and uses group15 (a 388 3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 389 [RFC6234] for integrity. This modulus is the minimum required by 390 [CNSA-SUITE]. If the GSS-API is to be used, then this method MAY be 391 implemented. 393 3.16.6. gss-group16-sha512-* 395 This key exchange method is defined in [RFC8732] and uses group16 (a 396 4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 397 [RFC6234] for integrity. The use of FFC DH is well understood and 398 trusted. Adding larger modulus sizes and protecting with SHA2-512 399 should give enough head room to be ready for the next scare that 400 someone has pre-computed it. If the GSS-API is to be used, then this 401 method MAY be implemented. 403 3.16.7. gss-group17-sha512-* 405 This key exchange method is defined in [RFC8732]and uses group17 (a 406 6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 407 [RFC6234] for integrity. The use of this 6144-bit MODP group is 408 going to be slower than what may be desirable. It is provided to 409 help those who wish to avoid using ECC algorithms. If the GSS-API is 410 to be used, then this method MAY be implemented. 412 3.16.8. gss-group18-sha512-* 414 This key exchange method is defined in [RFC8732] and uses group18 (a 415 8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in 416 [RFC6234] for integrity. The use of this 8192-bit MODP group is 417 going to be slower than what may be desirable. It is provided to 418 help those who wish to avoid using ECC algorithms. If the GSS-API is 419 to be used, then this method MAY be implemented. 421 3.16.9. gss-nistp256-sha256-* 423 This key exchange method is defined in [RFC8732]. If the GSS-API is 424 to be used with ECC algorithms, then this method SHOULD be 425 implemented. 427 3.16.10. gss-nistp384-sha384-* 429 This key exchange method is defined in [RFC8732]. If the GSS-API is 430 to be used with ECC algorithms, then this method SHOULD be 431 implemented to permit TOP SECRET information to be communicated. 433 3.16.11. gss-nistp521-sha512-* 435 This key exchange method is defined in [RFC8732]. If the GSS-API is 436 to be used with ECC algorithms, then this method MAY be implemented. 438 3.16.12. gss-curve25519-sha256-* 440 This key exchange method is defined in [RFC8732]. If the GSS-API is 441 to be used with ECC algorithms, then this method SHOULD be 442 implemented. 444 3.16.13. gss-curve448-sha512-* 446 This key exchange method is defined in [RFC8732]. If the GSS-API is 447 to be used with ECC algorithms, then this method MAY be implemented. 449 3.17. rsa1024-sha1 451 This key exchange method is defined in [RFC4432]. The security of 452 RSA 1024-bit modulus keys is not good enough any longer per 453 [NIST-SP-800-131Ar2], an RSA key size should be a minimum of 454 2048-bits. This key exchange group uses SHA-1 which has security 455 concerns [RFC6194]. This method MUST NOT be implemented. 457 3.18. rsa2048-sha256 459 This key exchange method is defined in [RFC4432]. An RSA 2048-bit 460 modulus key with a SHA2-256 hash. At the present time, a 2048-bit 461 RSA key is considered to be suffiently strong in [NIST-SP-800-131Ar2] 462 to be permitted. In addition, the use of a SHA-2 hash as defined in 463 [RFC6234] is a good integrity measure. This method MAY be 464 implemented. 466 4. Selecting an appropriate hashing algorithm 468 As may be seen from the above, the Key Exchange Methods area all 469 using either SHA256 or SHA512 with the exception of the ecdh- 470 sha2-nistp384 which uses SHA384. 472 The cited CNSA Suite specifies the use of SHA384 and says that SHA256 473 is no longer good enough for TOP SECRET. Nothing is said about the 474 use of SHA512. It may be that the internal state of 1024 bits in 475 both SHA384 and SHA512 makes the SHA384 more secure because it does 476 not leak an additional 128 bits of state. Of course, the use of 477 SHA384 also reduces the security strength to 384 bits instead of 478 being 512 bits. This seems to contradict the desire to double the 479 symmetric key strength in order to try to be safe from Post Quantum 480 Computing (PQC) attacks given a session key derived from the key 481 exchange will be limited to the security strength of the hash being 482 used. 484 The move away from SHA256 to SHA512 for the newer key exchange 485 methods is more to try to slow Grover's algorithm (a PQC attack) 486 slightly. It is also the case that SHA2-512 may, in many modern 487 CPUs, be implemented more efficiently using 64-bit arithmetic than 488 SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs 489 SHA512 is more about reducing the number of code point alternatives 490 to negotiate. There seemed to be consensus in favor of SHA2-512 over 491 SHA2-384 for key exchanges. 493 5. Summary Guidance for Key Exchange Method Names 495 The Implement column is the current recommendations of this RFC. Key 496 Exchange Method Names are listed alphabetically. 498 Key Exchange Method Name Reference Implement 499 ------------------------------------ --------- ---------- 500 curve25519-sha256 RFC8731 SHOULD 501 curve448-sha512 RFC8731 MAY 502 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 503 diffie-hellman-group-exchange-sha256 RFC4419 MAY 504 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 505 diffie-hellman-group14-sha1 RFC4253 SHOULD 506 diffie-hellman-group14-sha256 RFC8268 SHOULD 507 diffie-hellman-group15-sha512 RFC8268 MAY 508 diffie-hellman-group16-sha512 RFC8268 MAY 509 diffie-hellman-group17-sha512 RFC8268 MAY 510 diffie-hellman-group18-sha512 RFC8268 MAY 511 ecdh-sha2-* RFC5656 MAY 512 ecdh-sha2-nistp256 RFC5656 SHOULD 513 ecdh-sha2-nistp384 RFC5656 SHOULD 514 ecdh-sha2-nistp521 RFC5656 MAY 515 ecmqv-sha2 RFC5656 MAY 516 ext-info-c RFC8308 MAY 517 ext-info-s RFC8308 MAY 518 gss-* RFC4462 MAY 519 gss-curve25519-sha256-* RFC8732 SHOULD 520 gss-curve448-sha512-* RFC8732 MAY 521 gss-gex-sha1-* RFC4462 SHOULD NOT 522 gss-group1-sha1-* RFC4462 SHOULD NOT 523 gss-group14-sha256-* RFC8732 SHOULD 524 gss-group15-sha512-* RFC8732 MAY 525 gss-group16-sha512-* RFC8732 MAY 526 gss-group17-sha512-* RFC8732 MAY 527 gss-group18-sha512-* RFC8732 MAY 528 gss-nistp256-sha256-* RFC8732 SHOULD 529 gss-nistp384-sha384-* RFC8732 SHOULD 530 gss-nistp521-sha512-* RFC8732 MAY 531 rsa1024-sha1 RFC4432 MUST NOT 532 rsa2048-sha256 RFC4432 MAY 534 The full set of official [IANA-KEX] key algorithm method names not 535 otherwise mentioned in this document MAY be implemented. 537 The guidance of this document is that the SHA-1 algorithm hashing 538 SHOULD NOT be used. If it is used in implementations, it should only 539 be provided for backwards compatibility, should not be used in new 540 designs, and should be phased out of existing key exchanges as 541 quickly as possible because of its known weaknesses. Any key 542 exchange using SHA-1 should not be in a default key exchange list if 543 at all possible. If they are needed for backward compatibility, they 544 SHOULD be listed after all of the SHA-2 based key exchanges. 546 The [RFC4253] MUST diffie-hellman-group14-sha1 method SHOULD be 547 retained for compatibility with older Secure Shell implementations. 548 It is intended that this key exchange method be phased out as soon as 549 possible. It SHOULD be listed after all possible SHA-2 based key 550 exchanges. 552 It is believed that all current SSH implementations should be able to 553 achieve an implementation of the "diffie-hellman-group14-sha256" 554 method. To that end, this is one method that MUST be implemented. 556 [TO BE REMOVED: This registration should take place at the following 557 location: ] 560 6. Acknowledgements 562 Thanks to the following people for review and comments: Denis Bider, 563 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 564 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 565 and Tero Kivinen. 567 Thanks to the following people for code to implement interoperable 568 exchanges using some of these groups as found in an this draft: 569 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 570 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 571 and Poderosa implementations also adopting new Diffie-Hellman groups 572 based on this draft. 574 7. Security Considerations 576 This SSH protocol provides a secure encrypted channel over an 577 insecure network. It performs server host authentication, key 578 exchange, encryption, and integrity protection. It also derives a 579 unique session ID that may be used by higher-level protocols. 581 Full security considerations for this protocol are provided in 582 [RFC4251]. 584 It is desirable to deprecate or remove key exchange method name that 585 are considered weak. A key exchange method may be weak because too 586 few bits are used, or the hashing algorithm is considered too weak. 588 The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. 589 This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 590 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 591 [RFC6194] and with MODP groups with less than 2048 bits 592 [NIST-SP-800-131Ar2], this method is no longer considered secure. 594 The United States Information Assurance Directorate (IAD) at the 595 National Security Agency (NSA) has published a FAQ 596 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 597 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 598 less than SHA2-384 are no longer sufficient for transport of TOP 599 SECRET information. If your systems need to be concerned with TOP 600 SECRET information, then the guidance for supporting lesser security 601 strength key exchanges may be omitted for your implementations. 603 The MODP group14 is already required for SSH implementations and most 604 implementations already have a SHA2-256 implementation, so diffie- 605 hellman-group14-sha256 is provided as an easy to implement and faster 606 to use key exchange. Small embedded applications may find this KEX 607 desirable to use. 609 The NSA Information Assurance Directorate (IAD) has also published 610 the Commercial National Security Algorithm Suite (CNSA Suite) 611 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is 612 explicitly mentioned as the minimum modulus to protect TOP SECRET 613 communications. 615 It has been observed in [safe-curves] that the NIST Elliptic Curve 616 Prime Curves (P-256, P-384, and P-521) are perhaps not the best 617 available for Elliptic Curve Cryptography (ECC) Security. For this 618 reason, none of the [RFC5656] curves are mandatory to implement. 619 However, the requirement that "every compliant SSH ECC implementation 620 MUST implement ECDH key exchange" is now taken to mean that if ecdsa- 621 sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be 622 implemented. 624 In a Post-Quantum Computing (PQC) world, it will be desirable to use 625 larger cyclic subgroups. To do this using Elliptic Curve 626 Cryptography will require much larger prime base fields, greatly 627 reducing their efficiency. Finite Field based Cryptography already 628 requires large enough base fields to accommodate larger cyclic 629 subgroups. Until such time as a PQC method of key exchange is 630 developed and adopted, it may be desirable to generate new and larger 631 DH groups to avoid pre-calculation attacks that are provably not 632 backdoored. 634 8. IANA Considerations 636 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 637 implemented as being deprecated by this document. 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 649 Diffie-Hellman groups for Internet Key Exchange (IKE)", 650 RFC 3526, DOI 10.17487/RFC3526, May 2003, 651 . 653 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 654 Protocol Assigned Numbers", RFC 4250, 655 DOI 10.17487/RFC4250, January 2006, 656 . 658 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 659 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 660 January 2006, . 662 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 663 Internet Key Exchange Protocol Version 2 (IKEv2) Key 664 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 665 . 667 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 668 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 669 May 2017, . 671 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 672 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 673 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 674 . 676 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 677 Minimum Recommended Diffie-Hellman Modulus Size to 2048 678 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 679 . 681 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 682 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 683 2018, . 685 9.2. Informative References 687 [CNSA-SUITE] 688 NSA/IAD, "Commercial National Security Algorithm Suite", 689 September 2016, . 692 [ECDSA-Nonce-Leak] 693 Mulder, E. D., Hutter, M., Marson, M. E., and P. Pearson, 694 "Using Bleichenbacher's Solution to the Hidden Number 695 Problem to Attack Nonce Leaks in 384-Bit ECDSA", IACR 696 Cryptology ePrint Archive 2013, August 2013, 697 . 699 [IANA-KEX] 700 Internet Assigned Numbers Authority (IANA), "Secure Shell 701 (SSH) Protocol Parameters: Key Exchange Method Names", 702 July 2020, . 705 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 706 Green, M., Halderman, J., Heninger, N., Springall, D., 707 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 708 Zanella-Beguelin, S., and P. Zimmermann, "Imperfect 709 Forward Secrecy: How Diffie-Hellman Fails in Practice", 710 ACM Conference on Computer and Communications Security 711 (CCS) 2015, 2015, 712 . 714 [MFQ-U-OO-815099-15] 715 NSA/CSS, "CNSA Suite and Quantum Computing FAQ", January 716 2016, . 720 [NIST-SP-800-131Ar2] 721 Barker, E. and A. Roginsky, "Transitions: Recommendation 722 for the Transitioning of the Use of Cryptographic 723 Algorithms and Key Lengths", NIST Special 724 Publication 800-131A Revision 2, March 2019, 725 . 727 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 728 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 729 . 731 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 732 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 733 January 2006, . 735 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 736 Group Exchange for the Secure Shell (SSH) Transport Layer 737 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 738 . 740 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 741 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 742 March 2006, . 744 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 745 "Generic Security Service Application Program Interface 746 (GSS-API) Authentication and Key Exchange for the Secure 747 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 748 2006, . 750 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 751 Integration in the Secure Shell Transport Layer", 752 RFC 5656, DOI 10.17487/RFC5656, December 2009, 753 . 755 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 756 Considerations for the SHA-0 and SHA-1 Message-Digest 757 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 758 . 760 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 761 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 762 DOI 10.17487/RFC6234, May 2011, 763 . 765 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 766 Kivinen, "Internet Key Exchange Protocol Version 2 767 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 768 2014, . 770 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 771 Shell (SSH) Key Exchange Method Using Curve25519 and 772 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 773 . 775 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 776 Application Program Interface (GSS-API) Key Exchange with 777 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 778 . 780 [safe-curves] 781 Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe 782 curves for elliptic-curve cryptography.", February 2016, 783 . 785 Author's Address 787 Mark D. Baushke 788 Juniper Networks, Inc. 790 Email: mdb@juniper.net