idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-09.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 30, 2017) is 2461 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) == Outdated reference: A later version (-10) exists of draft-ietf-curdle-gss-keyex-sha2-02 == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-05 == Outdated reference: A later version (-06) exists of draft-ietf-curdle-ssh-dh-group-exchange-05 == Outdated reference: A later version (-09) exists of draft-ietf-curdle-ssh-modp-dh-sha2-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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 30, 2017 5 Intended status: Standards Track 6 Expires: January 31, 2018 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-09 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 http://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 31, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . 4 60 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 61 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4 62 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 63 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5 64 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 65 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5 66 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 5 67 3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5 68 3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6 69 3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6 70 3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 6 71 3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 6 72 3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 6 73 3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7 74 3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 7 75 3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 7 76 3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 7 77 3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 7 78 3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8 79 3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8 80 3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 8 81 3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 8 82 3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 8 83 3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 8 84 3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 8 85 4. Selecting an appropriate hashing algorithm . . . . . . . . . 8 86 5. Summary Guidance for Key Exchange Method Names . . . . . . . 9 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 9.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Overview and Rationale 97 Secure Shell (SSH) is a common protocol for secure communication on 98 the Internet. In [RFC4253], SSH originally defined two Key Exchange 99 Method Names that MUST be implemented. Over time, what was once 100 considered secure, is no longer considered secure. The purpose of 101 this RFC is to recommend that some published key exchanges be 102 deprecated as well as recommending some that SHOULD and one that MUST 103 be adopted. This document updates [RFC4250]. 105 This document adds recommendations for adoption of Key Exchange 106 Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be 107 implemented. New key exchange methods will use the SHA-2 family of 108 hashes and are drawn from these ssh-curves from 109 [I-D.ietf-curdle-ssh-curves] and new-modp from the 110 [I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex 111 [I-D.ietf-curdle-gss-keyex-sha2]. 113 [TO BE REMOVED: Please send comments on this draft to 114 curdle@ietf.org.] 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Key Exchange Methods 124 This memo adopts the style and conventions of [RFC4253] in specifying 125 how the use of data key exchange is indicated in SSH. 127 This RFC also collects Key Exchange Method Names in various existing 128 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 129 [I-D.ietf-curdle-ssh-modp-dh-sha2], [I-D.ietf-curdle-gss-keyex-sha2], 130 and [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability 131 for implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any 132 method not explicitly listed, MAY be implemented. 134 This document is intended to provide guidance as to what Key Exchange 135 Algorithms are to be considered for new or updated SSH 136 implementations. This document will be superseded when one or more 137 of the listed algorithms are considered too weak to continue to use 138 securely, in which case they will likely be downgraded to SHOULD NOT 139 or MUST NOT. Or, when newer methods have been analyzed and found to 140 be secure with wide enough adoption to upgrade their recommendation 141 from MAY to SHOULD or MUST. 143 3.1. curve25519-sha256 145 The Curve25519 provides strong security and is efficient on a wide 146 range of architectures with properties that allow better 147 implementation properties compared to traditional elliptic curves. 148 The use of SHA2-256 for integrity is a reasonable one for this 149 method. This Key Exchange Method has multiple implementations and 150 SHOULD be implemented in any SSH interested in using elliptic curve 151 based key exchanges. 153 3.2. curve448-sha512 155 The Curve448 provides very strong security. It is probably stronger 156 and more work than is currently needed. This method MAY be 157 implemented. 159 3.3. diffie-hellman-group-exchange-sha1 161 This set of ephemerally generated key exchange groups uses SHA-1 as 162 defined in [RFC4419]. However, SHA-1 has security concerns provided 163 in [RFC6194]. It is recommended that these key exchange groups NOT 164 be used. This key exchange SHOULD NOT be used. 166 3.4. diffie-hellman-group-exchange-sha256 168 This set of ephemerally generated key exchange groups uses SHA2-256 169 as defined in [RFC4419]. [I-D.ietf-curdle-ssh-dh-group-exchange] 170 mandates implementations avoid any MODP group with less than 2048 171 bits. This key exchange MAY be used. 173 3.5. diffie-hellman-group1-sha1 175 This method uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 176 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 177 [RFC6194] and with MODP groups with less than 2048 bits (see [LOGJAM] 178 and [NIST-SP-800-131Ar1]), this method is considered insecure. This 179 method is being moved from MUST to SHOULD NOT instead of MUST NOT 180 only to allow a transition time to get off of it. There are many old 181 implementations out there that may still need to use this key 182 exchange, it should be removed from server implementations as quickly 183 as possible. 185 3.6. diffie-hellman-group14-sha1 187 This method uses [RFC3526] group14 (a 2048-bit MODP group) which is 188 still a reasonable size. This key exchange group uses SHA-1 which 189 has security concerns [RFC6194]. However, this group is still strong 190 enough and is widely deployed. This method is being moved from MUST 191 to SHOULD to aid in transition to stronger SHA-2 based hashes. This 192 method will transition to SHOULD NOT when SHA-2 alternatives are more 193 generally available. 195 3.7. diffie-hellman-group14-sha256 197 This key exchange uses the group14 (a 2048-bit MODP group) along with 198 a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field 199 Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered 200 to be secure. It is a reasonably simple transition to move from 201 SHA-1 to SHA-2. This method MUST be implemented. 203 3.8. diffie-hellman-group15-sha512 205 Note: The use of this 3072-bit MODP group would be equally justified 206 to use SHA2-384 as the hash rather than SHA2-512. However, some 207 small implementations would rather only worry about two rather than 208 three new hashing functions. This group does not really provide much 209 additional head room over the 2048-bit group14 FFC DH and the 210 predominate open source implementations are not adopting it. This 211 method MAY be implemented. 213 3.9. diffie-hellman-group16-sha512 215 The use of FFC DH is well understood and trusted. Adding larger 216 modulus sizes and protecting with SHA2-512 should give enough head 217 room to be ready for the next scare that someone has pre-computed it. 218 This modulus (4096-bit) is larger than that required by [CNSA-SUITE] 219 and should be sufficient to inter-operate with more paranoid nation- 220 states. This method SHOULD be implemented. 222 3.10. diffie-hellman-group17-sha512 224 The use of this 6144-bit MODP group is going to be slower than what 225 may be desirable. It is provided to help those who wish to avoid 226 using ECC algorithms. This method MAY be implemented. 228 3.11. diffie-hellman-group18-sha512 230 The use of this 8192-bit MODP group is going to be slower than what 231 may be desirable. It is provided to help those who wish to avoid 232 using ECC algorithms. This method MAY be implemented. 234 3.12. ecdh-sha2-nistp256 236 Elliptic Curve Diffie-Hellman (ECDH) are often implemented because 237 they are smaller and faster than using large FFC primes with 238 traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and 240 [safe-curves], this curve may not be as useful and strong as desired 241 for handling TOP SECRET information for some applications. The SSH 242 development community is divided on this and many implementations do 243 exist. If traditional ECDH key exchange methods are implemented, 244 then this method SHOULD be implemented. It is advisable to match the 245 ECDSA and ECDH algorithms to use the same family of curves. 247 3.13. ecdh-sha2-nistp384 249 This ECDH method should be implemented because it is smaller and 250 faster than using large FFC primes with traditional Diffie-Hellman 251 (DH). Given [CNSA-SUITE], it is considered good enough for TOP 252 SECRET. If traditional ECDH key exchange methods are implemented, 253 then this method SHOULD be implemented. 255 3.14. ecdh-sha2-nistp521 257 This ECDH method may be implemented because it is smaller and faster 258 than using large FFC primes with traditional Diffie-Hellman (DH). It 259 is not listed in [CNSA-SUITE], so it is not currently appropriate for 260 TOP SECRET. This method MAY be implemented. 262 3.15. gss-gex-sha1-* 264 This set of ephemerally generated key exchange groups uses SHA-1 265 which has security concerns [RFC6194]. It is recommended that these 266 key exchange groups NOT be used. This key exchange SHOULD NOT be 267 used. It is intended that it move to MUST NOT as soon as the 268 majority of server implementations no longer offer it. It should be 269 removed from server implementations as quickly as possible. 271 3.16. gss-group1-sha1-* 273 This method suffers from the same problems of diffie-hellman- 274 group1-sha1. It uses [RFC7296] Oakley Group 2 (a 1024-bit MODP 275 group) and SHA-1 [RFC3174]. Due to recent security concerns with 276 SHA-1 [RFC6194] and with MODP groups with less than 2048 bits (see 277 [LOGJAM] and [NIST-SP-800-131Ar1]), this method is considered 278 insecure. This method SHOULD NOT be implemented. It is intended 279 that it move to MUST NOT as soon as the majority of server 280 implementations no longer offer it. It should be removed from server 281 implementations as quickly as possible. 283 3.17. gss-group14-sha1-* 285 This generated key exchange groups uses SHA-1 which has security 286 concerns [RFC6194]. If GSS-API key exchange methods are being used, 287 then this one SHOULD be implemented until such time as SHA-2 variants 288 may be implemented and deployed. This method will transition to 289 SHOULD NOT when SHA-2 alternatives are more generally available. No 290 other standard indicated that this method was anything other than 291 optional even though it was implemented in all GSS-API systems. This 292 method MAY be implemented. 294 3.18. gss-group14-sha256-* 296 This key exchange uses the group14 (a 2048-bit MODP group) along with 297 a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field 298 Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered 299 to be secure. It is a reasonably simple transition to move from 300 SHA-1 to SHA-2. If the GSS-API is to be used, then this method 301 SHOULD be implemented. 303 3.19. gss-group15-sha512-* 305 The use of this 3072-bit MODP group does not really provide much 306 additional head room over the 2048-bit group14 FFC DH. If the GSS- 307 API is to be used, then this method MAY be implemented. 309 3.20. gss-group16-sha512-* 311 The use of FFC DH is well understood and trusted. Adding larger 312 modulus sizes and protecting with SHA2-512 should give enough head 313 room to be ready for the next scare that someone has pre-computed. 314 This modulus (4096-bit) is larger than that required by [CNSA-SUITE] 315 and should be sufficient to inter-operate with more paranoid nation- 316 states. If the GSS-API is to be used, then this method SHOULD be 317 implemented. 319 3.21. gss-group17-sha512-* 321 The use of this 6144-bit MODP group is going to be slower than what 322 may be desirable. It is provided to help those who wish to avoid 323 using ECC algorithms. If the GSS-API is to be used, then this method 324 MAY be implemented. 326 3.22. gss-group18-sha512-* 328 The use of this 8192-bit MODP group is going to be slower than what 329 may be desirable. It is provided to help those who prefer to avoid 330 using ECC algorithms. If the GSS-API is to be used, then this method 331 MAY be implemented. 333 3.23. gss-nistp256-sha256-* 335 If the GSS-API is to be used with ECC algorithms, then this method 336 SHOULD be implemented. 338 3.24. gss-nistp384-sha384-* 340 If the GSS-API is to be used with ECC algorithms, then this method 341 SHOULD be implemented to permit TOP SECRET information to be 342 communicated. 344 3.25. gss-nistp521-sha512-* 346 If the GSS-API is to be used with ECC algorithms, then this method 347 MAY be implemented. 349 3.26. gss-curve25519-sha256-* 351 If the GSS-API is to be used with ECC algorithms, then this method 352 SHOULD be implemented. 354 3.27. gss-curve448-sha512-* 356 If the GSS-API is to be used with ECC algorithms, then this method 357 MAY be implemented. 359 3.28. rsa1024-sha1 361 The security of RSA 1024-bit modulus keys is not good enough any 362 longer. A key size should be 2048-bits. This generated key exchange 363 groups uses SHA-1 which has security concerns [RFC6194]. This method 364 MUST NOT be implemented. 366 3.29. rsa2048-sha256 368 An RSA 2048-bit modulus key with a SHA2-256 hash. This method MAY be 369 implemented. 371 4. Selecting an appropriate hashing algorithm 373 As may be seen from the above, the Key Exchange Methods area all 374 using either SHA256 or SHA512 with the exception of the ecdh- 375 sha2-nistp384 which uses SHA384. 377 The cited CNSA Suite specifies the use of SHA384 and says that SHA256 378 is no longer good enough for TOP SECRET. Nothing is said about the 379 use of SHA512. It may be that the internal state of 1024 bits in 380 both SHA384 and SHA512 makes the SHA384 more secure because it does 381 not leak an additional 128 bits of state. Of course, use of SHA384 382 also reduces the security strength to 192 bits instead of being 256 383 bits or more. This seems to contradict the desire to double the 384 symmetric key strength in order to try to be safe from Post Quantum 385 Computing (PQC) attacks given a session key derived from the key 386 exchange will be limited to the security strength of the hash being 387 used. 389 The move away from SHA256 to SHA512 for the newer key exchange 390 methods is more to try to slow Grover's algorithm (a PQC attack) 391 slightly. It is also the case that SHA2-512 may, in many modern 392 CPUs, be implemented more efficiently using 64-bit arithmetic than 393 SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs 394 SHA512 is more about reducing the number of code point alternatives 395 to negotiate. There seemed to be consensus in favor of SHA2-512 over 396 SHA2-384 for key exchanges. 398 5. Summary Guidance for Key Exchange Method Names 400 The Implement column is the current recommendations of this RFC. Key 401 Exchange Method Names are listed alphabetically. 403 Key Exchange Method Name Reference Implement 404 ---------------------------------- ---------- ---------- 405 curve25519-sha256 ssh-curves SHOULD 406 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 407 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 408 diffie-hellman-group14-sha1 RFC4253 SHOULD 409 diffie-hellman-group14-sha256 new-modp MUST 410 diffie-hellman-group16-sha512 new-modp SHOULD 411 ecdh-sha2-nistp256 RFC5656 SHOULD 412 ecdh-sha2-nistp384 RFC5656 SHOULD 413 gss-gex-sha1-* RFC4462 SHOULD NOT 414 gss-group1-sha1-* RFC4462 SHOULD NOT 415 gss-group14-sha256-* gss-keyex SHOULD 416 gss-group16-sha512-* gss-keyex SHOULD 417 gss-nistp256-sha256-* gss-keyex SHOULD 418 gss-nistp384-sha384-* gss-keyex SHOULD 419 gss-curve25519-sha256-* gss-keyex SHOULD 420 rsa1024-sha1 RFC4432 MUST NOT 422 The full set of official [IANA-KEX] key algorithm method names not 423 otherwise mentioned in this document MAY be implemented. 425 The guidance of this document is that the SHA-1 algorithm hashing 426 SHOULD NOT be used. If it is used in implementations, it should only 427 be provided for backwards compatibility, should not be used in new 428 designs, and should be phased out of existing key exchanges as 429 quickly as possible because of its known weaknesses. Any key 430 exchange using SHA-1 should not be in a default key exchange list if 431 at all possible. If they are needed for backward compatibility, they 432 SHOULD be listed after all of the SHA-2 based key exchanges. 434 The [RFC4253] MUST diffie-hellman-group14-sha1 method SHOULD be 435 retained for compatibility with older Secure Shell implementations. 436 It is intended that this key exchange method be phased out as soon as 437 possible. It SHOULD be listed after all possible SHA-2 based key 438 exchanges. 440 It is believed that all current SSH implementations should be able to 441 achieve an implementation of the "diffie-hellman-group14-sha256" 442 method. To that end, this is one method that MUST be implemented. 444 [TO BE REMOVED: This registration should take place at the following 445 location: ] 448 6. Acknowledgements 450 Thanks to the following people for review and comments: Denis Bider, 451 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 452 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 453 and Tero Kivinen. 455 Thanks to the following people for code to implement inter-operable 456 exchanges using some of these groups as found in an this draft: 457 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 458 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 459 and Poderosa implementations also adopting new Diffie-Hellman groups 460 based on this draft. 462 7. Security Considerations 464 This SSH protocol provides a secure encrypted channel over an 465 insecure network. It performs server host authentication, key 466 exchange, encryption, and integrity protection. It also derives a 467 unique session ID that may be used by higher-level protocols. 469 Full security considerations for this protocol are provided in 470 [RFC4251] 472 It is desirable to deprecate or remove key exchange method name that 473 are considered weak. A key exchange method may be weak because too 474 few bits are used, or the hashing algorithm is considered too weak. 476 The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. 477 This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 478 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 479 [RFC6194] and with MODP groups with less than 2048 bits 480 [NIST-SP-800-131Ar1], this method is no longer considered secure. 482 The United States Information Assurance Directorate (IAD) at the 483 National Security Agency (NSA) has published a FAQ 484 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 485 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 486 less than SHA2-384 are no longer sufficient for transport of TOP 487 SECRET information. If your systems need to be concerned with TOP 488 SECRET information, then the guidance for supporting lesser security 489 strength key exchanges may be omitted for your implementations. 491 The MODP group14 is already required for SSH implementations and most 492 implementations already have a SHA2-256 implementation, so diffie- 493 hellman-group14-sha256 is provided as an easy to implement and faster 494 to use key exchange. Small embedded applications may find this KEX 495 desirable to use. 497 The NSA Information Assurance Directorate (IAD) has also published 498 the Commercial National Security Algorithm Suite (CNSA Suite) 499 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is 500 explicitly mentioned as the minimum modulus to protect TOP SECRET 501 communications. 503 It has been observed in [safe-curves] that the NIST Elliptic Curve 504 Prime Curves (P-256, P-384, and P-521) are perhaps not the best 505 available for Elliptic Curve Cryptography (ECC) Security. For this 506 reason, none of the [RFC5656] curves are mandatory to implement. 507 However, the requirement that "every compliant SSH ECC implementation 508 MUST implement ECDH key exchange" is now taken to mean that if ecdsa- 509 sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be 510 implemented. 512 In a Post-Quantum Computing (PQC) world, it will be desirable to use 513 larger cyclic subgroups. To do this using Elliptic Curve 514 Cryptography will require much larger prime base fields, greatly 515 reducing their efficiency. Finite Field based Cryptography already 516 requires large enough base fields to accommodate larger cyclic 517 subgroups. Until such time as a PQC method of key exchange is 518 developed and adopted, it may be desirable to generate new and larger 519 DH groups to avoid pre-calculation attacks that are provably not 520 backdoored. 522 8. IANA Considerations 524 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 525 implemented as being deprecated by this document. 527 9. References 529 9.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, 534 . 536 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 537 Diffie-Hellman groups for Internet Key Exchange (IKE)", 538 RFC 3526, DOI 10.17487/RFC3526, May 2003, 539 . 541 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 542 Protocol Assigned Numbers", RFC 4250, 543 DOI 10.17487/RFC4250, January 2006, 544 . 546 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 547 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 548 January 2006, . 550 9.2. Informative References 552 [CNSA-SUITE] 553 "Information Assurance by the National Security Agency", 554 "Commercial National Security Algorithm Suite", September 555 2016, . 558 [I-D.ietf-curdle-gss-keyex-sha2] 559 Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", 560 draft-ietf-curdle-gss-keyex-sha2-02 (work in progress), 561 June 2017. 563 [I-D.ietf-curdle-ssh-curves] 564 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 565 Shell (SSH) Key Exchange Method using Curve25519 and 566 Curve448", draft-ietf-curdle-ssh-curves-05 (work in 567 progress), May 2017. 569 [I-D.ietf-curdle-ssh-dh-group-exchange] 570 Velvindron, L. and M. Baushke, "Increase SSH minimum 571 recommended DH modulus size to 2048 bits", draft-ietf- 572 curdle-ssh-dh-group-exchange-05 (work in progress), July 573 2017. 575 [I-D.ietf-curdle-ssh-modp-dh-sha2] 576 Baushke, M., "More Modular Exponential (MODP) Diffie- 577 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 578 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-07 (work in 579 progress), June 2017. 581 [IANA-KEX] 582 Internet Assigned Numbers Authority (IANA), "Secure Shell 583 (SSH) Protocol Parameters: Key Exchange Method Names", 584 March 2017, . 587 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 588 Green, M., Halderman, J., Heninger, N., Springall, D., 589 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 590 Zanella-Beguelin, S., and P. Zimmermann, "Imperfect 591 Forward Secrecy: How Diffie-Hellman Fails in Practice", 592 ACM Conference on Computer and Communications Security 593 (CCS) 2015, 2015, . 596 [MFQ-U-OO-815099-15] 597 "National Security Agency/Central Security Service", "CNSA 598 Suite and Quantum Computing FAQ", January 2016, 599 . 603 [NIST-SP-800-131Ar1] 604 Barker and Roginsky, "Transitions: Recommendation for the 605 Transitioning of the Use of Cryptographic Algorithms and 606 Key Lengths", NIST Special Publication 800-131A Revision 607 1, November 2015, 608 . 611 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 612 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 613 . 615 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 616 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 617 January 2006, . 619 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 620 Group Exchange for the Secure Shell (SSH) Transport Layer 621 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 622 . 624 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 625 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 626 March 2006, . 628 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 629 "Generic Security Service Application Program Interface 630 (GSS-API) Authentication and Key Exchange for the Secure 631 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 632 2006, . 634 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 635 Integration in the Secure Shell Transport Layer", 636 RFC 5656, DOI 10.17487/RFC5656, December 2009, 637 . 639 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 640 Considerations for the SHA-0 and SHA-1 Message-Digest 641 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 642 . 644 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 645 Kivinen, "Internet Key Exchange Protocol Version 2 646 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 647 2014, . 649 [safe-curves] 650 Bernstein and Lange, "SafeCurves: choosing safe curves for 651 elliptic-curve cryptography.", February 2016, 652 . 654 Author's Address 655 Mark D. Baushke 656 Juniper Networks, Inc. 657 1133 Innovation Way 658 Sunnyvale, CA 94089-1228 659 US 661 Email: mdb@juniper.net 662 URI: http://www.juniper.net/