Internet Engineering Task Force (IETF) L. Velvindron
Request for Comments: 8270 Hackers.mu
Updates: 4419 M. Baushke
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 December 2017
Internet Engineering Task Force (IETF) L. Velvindron
Request for Comments: 8270 Hackers.mu
Updates: 4419 M. Baushke
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 December 2017
Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits
将Secure Shell建议的Diffie-Hellman最小模数大小增加到2048位
Abstract
摘要
The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits. Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.
用于Secure Shell（SSH）传输层协议的Diffie-Hellman（DH）组交换指定服务器和客户端应支持最小模数组大小为1024位的组。最近的安全研究表明，1024位的最小值不足以保护国家赞助的参与者和任何拥有足够计算资源的组织。此RFC更新RFC 4419，其允许DH模小于2048位；现在，2048位是可接受的最小组大小。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8270.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8270.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. 2048-Bit DH Group . . . . . . . . . . . . . . . . . . . . . . 3
4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. 2048-Bit DH Group . . . . . . . . . . . . . . . . . . . . . . 3
4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
[RFC4419] specifies a recommended minimum DH modulus group size of 1024 bits. It also suggests that in all cases, the size of the group needs to be at least 1024 bits. This document updates [RFC4419] so that the minimum recommended size is 2048 bits. This recommendation is based on recent research [LOGJAM] on DH group weaknesses. This minimum DH group size may need to be increased to 3072 for forward-looking users.
[RFC4419]指定建议的最小DH模数组大小为1024位。它还表明，在所有情况下，组的大小至少需要1024位。本文档更新了[RFC4419]，因此建议的最小大小为2048位。本建议基于最近关于DH集团弱点的研究[LOGJAM]。对于前瞻性用户，可能需要将DH组的最小规模增加到3072。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Recent research [LOGJAM] strongly suggests that DH groups that are 1024 bits can be broken by state-sponsored actors and any organization with enough computing resources. The authors show how they are able to break 768-bit DH groups and extrapolate the attack to 1024-bit DH groups. In their analysis, they show that breaking 1024 bits can be done with sufficient computing resources. This document provides the following recommendation: SSH servers and SSH clients SHOULD support groups with a minimum acceptable group size of 2048 bits for the "min" value of the SSH_MSG_KEY_DH_GEX_REQUEST client message given in [RFC4419]. Further, SSH clients SHOULD be able to send a value of 3072 bits for the preferred acceptable group size "n" in the SSH_MSG_KEY_DH_GEX_REQUEST message.
最近的研究[LOGJAM]强烈表明，1024位的DH组可以被国家赞助的参与者和任何拥有足够计算资源的组织打破。作者展示了他们如何能够打破768位DH组，并将攻击外推到1024位DH组。在他们的分析中，他们表明，只要有足够的计算资源，就可以断开1024位。本文档提供了以下建议：对于[RFC4419]中给出的SSH_MSG_KEY_DH_GEX_REQUEST client消息的“min”值，SSH服务器和SSH客户端应支持最小可接受组大小为2048位的组。此外，SSH客户端应该能够为SSH_MSG_KEY_DH_GEX_请求消息中的首选可接受组大小“n”发送3072位的值。
[RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH group. It also suggests that, in all cases, the size of the group needs be at least 1024 bits. This document updates [RFC4419] as described below:
[RFC4419]指定k的建议最小大小为1024位，这是DH组的模数长度。它还表明，在所有情况下，组的大小至少需要1024位。本文件更新[RFC4419]，如下所述：
o Section 3, paragraph 9: Servers and clients SHOULD support groups with a modulus length of k bits where 2048 <= k <= 8192. The recommended minimum values for min and max are 2048 and 8192, respectively. Setting k to 3072 SHOULD be possible, as the need may arise in the coming years.
o 第3节第9段：服务器和客户端应支持模数长度为k位的组，其中2048<=k<=8192。最小值和最大值的建议最小值分别为2048和8192。将k设置为3072应该是可能的，因为未来几年可能会出现这种需要。
o Section 3, paragraph 11: In all cases, the size of the group SHOULD be at least 2048 bits. Setting the group size to 3072 SHOULD be possible, as the need may arise in the coming years.
o 第3节第11段：在所有情况下，组的大小应至少为2048位。将集团规模设定为3072是可能的，因为未来几年可能会出现这种需要。
This document keeps the following requirement from [RFC4419]:
本文件保留了[RFC4419]的以下要求：
The server should return the smallest group it knows that is larger than the size the client requested. If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows.
服务器应返回它知道的最小组，该组大于客户端请求的大小。如果服务器不知道比客户端请求大的组，那么它应该返回它知道的最大组。
Also, it updates the subsequent sentence as follows:
此外，它还将后续句子更新如下：
In all cases, the size of the returned group SHOULD be at least 2048 bits. Setting the group size to 3072 SHOULD be possible, as the need may arise in the coming years.
在所有情况下，返回组的大小应至少为2048位。将集团规模设定为3072是可能的，因为未来几年可能会出现这种需要。
This document discusses security issues of DH groups that are 1024 bits in size, and formally updates the minimum size of DH groups to be 2048 bits. A hostile or "owned" SSH server implementation could potentially use backdoored DH primes using the methods described in [Backdoor-DH] to provide the g and p values to be used. Or, it could just send the calculated secret through a covert channel of some sort to a passive listener.
本文档讨论大小为1024位的DH组的安全问题，并正式将DH组的最小大小更新为2048位。恶意或“自有”SSH服务器实现可能使用后门DH prime，使用[Backdoor DH]中描述的方法提供要使用的g和p值。或者，它可以通过某种隐蔽通道将计算出的秘密发送给被动侦听器。
A malicious client could cause a Denial of Service by intentionally making multiple connections that are less than 2048 bits in size. Therefore, operating systems SHOULD NOT log DH groups that are less than 2048 bits in size, as it would create an additional attack surface.
恶意客户端可能会故意建立多个小于2048位的连接，从而导致拒绝服务。因此，操作系统不应记录大小小于2048位的DH组，因为这会产生额外的攻击面。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <https://www.rfc-editor.org/info/rfc4419>.
[RFC4419]Friedl，M.，Provos，N.，和W.Simpson，“用于安全外壳（SSH）传输层协议的Diffie-Hellman组交换”，RFC 4419，DOI 10.17487/RFC4419，2006年3月<https://www.rfc-editor.org/info/rfc4419>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Backdoor-DH] Wong, D., "How to Backdoor Diffie-Hellman", Cryptology ePrint Archive Report 2016/644, June 2016, <http://eprint.iacr.org/2016/644.pdf>.
[后门DH]Wong，D.，“如何后门Diffie Hellman”，密码学ePrint档案报告2016/6442016年6月<http://eprint.iacr.org/2016/644.pdf>.
[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Beguelin, S., and P. Zimmermann, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", ACM Conference on Computer and Communications Security (CCS) 2015, DOI 10.1145/2810103.2813707, 2015, <https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>.
[LOGJAM]Adrian，D.，Bhargavan，K.，Durumeric，Z.，Gaudry，P.，Green，M.，Halderman，J.，Heninger，N.，Springall，D.，Thome，E.，Valenta，L.，VanderSloot，B.，Wustrow，E.，Zanella Beguelin，S.，和P.Zimmermann，“不完美的前向保密：Diffie Hellman如何在实践中失败”，ACM计算机和通信安全会议（CCS）2015，DOI 10.1145/2810103.28137072015<https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>.
Authors' Addresses
作者地址
Loganaden Velvindron Hackers.mu 88, Avenue De Plevitz Roches Brunes Mauritius
毛里求斯布鲁内斯普列维茨罗切斯大道88号洛根纳登维文德罗酒店
Phone: +230 59762817
Email: logan@hackers.mu
Phone: +230 59762817
Email: logan@hackers.mu
Mark D. Baushke Juniper Networks, Inc.
马克·鲍什克·朱尼珀网络公司。
Email: mdb@juniper.net
Email: mdb@juniper.net