Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 8301 Kitterman Technical Services
Updates: 6376 January 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 8301 Kitterman Technical Services
Updates: 6376 January 2018
Category: Standards Track
ISSN: 2070-1721
Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)
加密算法和密钥使用更新到域密钥识别邮件（DKIM）
Abstract
摘要
The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.
十年前设计DomainKeys Identified Mail（DKIM）时包含的加密算法和密钥大小要求在功能上已经过时，需要立即修改。本文件将DKIM要求更新为最适合当前指定算法运行的要求。
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/rfc8301.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8301.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Updates to DKIM Signing and Verification Requirements . . . . 3
3.1. Signing and Verification Algorithms . . . . . . . . . . . 3
3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Updates to DKIM Signing and Verification Requirements . . . . 3
3.1. Signing and Verification Algorithms . . . . . . . . . . . 3
3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
DKIM [RFC6376] signs email messages by creating hashes of the message headers and content and signing the header hash with a digital signature. Message recipients fetch the signature verification key from the DNS where it is stored in a TXT record.
DKIM[RFC6376]通过创建邮件标题和内容的散列并使用数字签名对标题散列进行签名来对电子邮件进行签名。消息收件人从DNS获取签名验证密钥，该密钥存储在TXT记录中。
The defining documents, RFC 6376 [RFC6376] and its predecessors, specify a single signing algorithm, RSA [RFC8017], and recommend key sizes of 1024 to 2048 bits (but require verification of 512-bit keys). As discussed in US-CERT Vulnerability Note VU#268267 [VULNOTE], the operational community has recognized that shorter keys compromise the effectiveness of DKIM. While 1024-bit signatures are common, stronger signatures are not. Widely used DNS configuration software places a practical limit on key sizes, because the software only handles a single 256-octet string in a TXT record, and RSA keys significantly longer than 1024 bits don't fit in 256 octets.
定义文档RFC 6376[RFC6376]及其前身指定了单签名算法RSA[RFC8017]，并建议密钥大小为1024到2048位（但需要验证512位密钥）。正如US-CERT漏洞说明VU#268267[VULNOTE]中所述，作战社区已经认识到较短的密钥会影响DKIM的有效性。虽然1024位签名很常见，但更强的签名并不常见。广泛使用的DNS配置软件对密钥大小进行了实际限制，因为该软件只处理TXT记录中的单个256个八位字节字符串，而大大超过1024位的RSA密钥不适合256个八位字节。
Due to the recognized weakness of the SHA-1 hash algorithm (see [RFC6194]) and the wide availability of the SHA-256 hash algorithm (it has been a required part of DKIM [RFC6376] since it was originally standardized in 2007), the SHA-1 hash algorithm MUST NOT be used. This is being done now to allow the operational community time to fully shift to SHA-256 in advance of any SHA-1-related crisis.
由于公认的SHA-1哈希算法的弱点（见[RFC6194]）以及SHA-256哈希算法的广泛可用性（自2007年开始标准化以来，它一直是DKIM[RFC6376]的必需部分），因此不能使用SHA-1哈希算法。现在这样做是为了在任何SHA-1相关危机之前，让作战社区的时间完全转移到SHA-256。
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]所述进行解释。
This document updates [RFC6376] as follows:
本文件更新[RFC6376]如下：
o Section 3.1 of this document updates Section 3.3 of [RFC6376].
o 本文件第3.1节更新了[RFC6376]第3.3节。
o Section 3.2 of this document updates Section 3.3.3 of [RFC6376].
o 本文件第3.2节更新了[RFC6376]第3.3.3节。
o The algorithm described in Section 3.3.1 of [RFC6376] is now historic and no longer used by DKIM.
o [RFC6376]第3.3.1节中描述的算法现已成为历史，DKIM不再使用。
Sections 3.3.2 and 3.3.4 of [RFC6376] are not affected.
[RFC6376]第3.3.2节和第3.3.4节不受影响。
DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying.
DKIM支持多种数字签名算法。本规范目前定义了两种算法：rsa-sha1和rsa-sha256。签名者必须使用rsa-sha256签名。验证器必须能够使用rsa-sha256进行验证。rsa-sha1不得用于签名或验证。
DKIM signatures identified as having been signed with historic algorithms (currently, rsa-sha1) have permanently failed evaluation as discussed in Section 3.9 of [RFC6376].
如[RFC6376]第3.9节所述，被确定为使用历史算法（目前为rsa-sha1）签名的DKIM签名已永久失败评估。
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. Verifier policies can use the length of the signing key as one metric for determining whether a signature is acceptable. Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.
选择合适的密钥大小是成本、性能和风险之间的权衡。由于短RSA密钥更容易受到离线攻击，签名者必须对所有密钥使用至少1024位的RSA密钥。签名者应使用至少2048位的RSA密钥。验证器必须能够使用1024位到4096位的密钥验证签名，并且可以使用更大的密钥验证签名。验证器策略可以使用签名密钥的长度作为确定签名是否可接受的一个度量。验证者不能考虑使用小于1024位的RSA密钥作为有效签名的签名。
DKIM signatures with insufficient key sizes (currently, rsa-sha256 with less than 1024 bits) have permanently failed evaluation as discussed in Section 3.9 of [RFC6376].
密钥大小不足的DKIM签名（目前为小于1024位的rsa-sha256）的评估永久失败，如[RFC6376]第3.9节所述。
This document does not change the Security Considerations of [RFC6376]. It reduces the risk of signature compromise due to weak cryptography. The SHA-1 risks discussed in Section 3 of [RFC6194] are resolved due to rsa-sha1 no longer being used by DKIM.
本文件不改变[RFC6376]的安全注意事项。它降低了由于弱加密而导致签名泄露的风险。[RFC6194]第3节中讨论的SHA-1风险已解决，因为DKIM不再使用rsa-sha1。
IANA has updated the Reference and Status fields of the "sha1" registration in the "DKIM Hash Algorithms" registry. The registration now appears as follows:
IANA已更新“DKIM哈希算法”注册表中“sha1”注册的参考和状态字段。注册现在显示如下：
+------+---------------------+----------+
| Type | Reference | Status |
+------+---------------------+----------+
| sha1 | [RFC6376] [RFC8301] | historic |
+------+---------------------+----------+
+------+---------------------+----------+
| Type | Reference | Status |
+------+---------------------+----------+
| sha1 | [RFC6376] [RFC8301] | historic |
+------+---------------------+----------+
[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>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<https://www.rfc-editor.org/info/rfc8017>.
[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>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <https://www.rfc-editor.org/info/rfc6194>.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 6194，DOI 10.17487/RFC6194，2011年3月<https://www.rfc-editor.org/info/rfc6194>.
[VULNOTE] US-CERT, "Vulnerability Note VU#268267: DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust", October 2012, <http://www.kb.cert.org/vuls/id/268267>.
[VULNOTE]US-CERT，“漏洞注释VU#268267：域密钥识别邮件（DKIM）验证程序可能不适当地传递消息信任”，2012年10月<http://www.kb.cert.org/vuls/id/268267>.
Acknowledgements
致谢
The author wishes to acknowledge the following individuals for their review and comments on this proposal: Kurt Andersen, Murray S. Kucherawy, Martin Thomson, John Levine, Russ Housley, and Jim Fenton.
作者希望感谢以下个人对本提案的审查和评论：库尔特·安德森、默里·库奇拉维、马丁·汤姆森、约翰·莱文、罗斯·霍斯利和吉姆·芬顿。
Thanks to John Levine for his DKIM Crypto Update (DCRUP) work that was the source for much of the introductory material in this document.
感谢John Levine的DKIM加密更新（DCRUP）工作，这是本文档中大部分介绍性材料的来源。
Author's Address
作者地址
Scott Kitterman Kitterman Technical Services 3611 Scheel Dr Ellicott City, MD 21042 United States of America
Scott Kitterman Kitterman技术服务3611 Scheel Dr Ellicott City，MD 21042美利坚合众国
Phone: +1 301 325-5475
Email: scott@kitterman.com
Phone: +1 301 325-5475
Email: scott@kitterman.com