idnits 2.17.1 draft-ietf-curdle-ssh-dh-group-exchange-06.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 RFC4419, updated by this document, for RFC5378 checks: 2001-01-30) -- 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 (September 21, 2017) is 2409 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 L. Velvindron 3 Internet-Draft Hackers.mu 4 Updates: 4419 (if approved) M. Baushke 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: March 25, 2018 September 21, 2017 8 Increase SSH minimum recommended DH modulus size to 2048 bits 9 draft-ietf-curdle-ssh-dh-group-exchange-06 11 Abstract 13 The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) 14 Transport layer Protocol specifies that servers and clients should 15 support groups with a modulus length of k bits, where the recommended 16 minimum value is 1024 bits. Recent security research has shown that 17 a minimum value of 1024 bits is insufficient against state-sponsored 18 actors, and possibly any organization with enough computing 19 resources. As such, this document formally updates the specification 20 such that the minimum recommended value for k is 2048 bits and the 21 group size is 2048 bits at minimum. This RFC updates RFC4419 which 22 allowed for DH moduli less than 2048 bits. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 25, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 [RFC4419] specifies a recommended minimum size of 1024 bits for k, 59 which is the modulus length of the DH Group. It also suggests that 60 in all cases, the size of the group needs be at least 1024 bits. 61 This document updates [RFC4419] so that the minimum recommended size 62 be 2048 bits. This recommendation is based on recent research 63 [LOGJAM] on DH Group weaknesses. 65 1.1. Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 2. 2048 bits DH Group 73 Recent research [LOGJAM] strongly suggests that DH groups that are 74 1024 bits can be broken by state actors, and possibly any 75 organization with enough computing resources. The authors show how 76 they are able to break 768 bits DH group and extrapolate the attack 77 to 1024 bits DH groups. In their analysis, they show that breaking 78 1024 bits can be done with enough computing resources. This document 79 provides the following recommendation: SSH Servers and SSH clients 80 SHOULD support groups with a modulus length of k bits where 2048 <= k 81 <= 8192, where it is possible to set k to 3072 should the need arise 82 in the coming years. 84 [RFC4419] specifies a recommended minimum size of 1024 bits for k, 85 which is the modulus length of the DH Group. It also suggests that 86 in all cases, the size of the group needs be at least 1024 bits. 87 This document updates [RFC4419] as described below: 89 o section 3 Paragraph 9: Servers and clients SHOULD support groups 90 with a modulus length of k bits where 2048 <= k <= 8192. The 91 recommended minimum values for min and max are 2048 and 8192, 92 respectively. k SHOULD be able to be set to 3072 by an 93 implementation should the need arise in the coming years. 95 o Section 3 Paragraph 11: In all cases, the size of the group SHOULD 96 be at least 2048 bits, with the possibility to be set to 3072 bits 97 should the need arise in the coming years. 99 3. Interoperability 101 This document keeps the [RFC4419] requirement "The server should 102 return the smallest group it knows that is larger than the size the 103 client requested. If the server does not know a group that is larger 104 than the client request, then it SHOULD return the largest group it 105 knows." and updates the sentence that follows to read: "In all cases, 106 the size of the returned group SHOULD be at least 2048 bits." 108 4. Security Considerations 110 This document discusses security issues of DH groups that are 1024 111 bits in size, and formally updates the minimum size of DH groups to 112 be 2048 bits. A hostile or "owned" Secure Shell server 113 implementation could potentially use Backdoored Diffie-Hellman primes 114 using the methods described in [Backdoor-DH] to provide the g,p 115 values to be used. Or, they could just send the calculated secret 116 through a covert channel of some sort to a passive listener. 118 A malicious client could cause a Denial of Service by making multiple 119 connections which are less 2048 bits in size on purpose. Therefore, 120 Operating Systems SHOULD NOT log DH groups less than 2048 bits in 121 size, as it would create an additional attack surface. 123 5. IANA Considerations 125 This document contains no considerations for IANA. 127 6. References 129 6.1. Normative References 131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 132 Requirement Levels", BCP 14, RFC 2119, 133 DOI 10.17487/RFC2119, March 1997, 134 . 136 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 137 Group Exchange for the Secure Shell (SSH) Transport Layer 138 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 139 . 141 6.2. Informative References 143 [Backdoor-DH] 144 Wong, D., "How to Backdoor Diffie-Hellman", Cryptology 145 ePrint Archive Report 2016/644, June 2016, 146 . 148 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 149 Green, M., Halderman, J., Heninger, N., Springall, D., 150 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 151 Zanella-Beguelin, S., and P. Zimmermann, "Imperfect 152 Forward Secrecy: How Diffie-Hellman Fails in Practice", 153 ACM Conference on Computer and Communications Security 154 (CCS) 2015, 2015, 155 . 157 Authors' Addresses 159 Loganaden Velvindron 160 Hackers.mu 161 88, Avenue De Plevitz 162 Roches Brunes 163 MU 165 Phone: +230 59762817 166 Email: logan@hackers.mu 168 Mark D. Baushke 169 Juniper Networks, Inc. 171 Email: mdb@juniper.net