Network Working Group J. Fenton
Request for Comments: 4686 Cisco Systems, Inc.
Category: Informational September 2006
Network Working Group J. Fenton
Request for Comments: 4686 Cisco Systems, Inc.
Category: Informational September 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
激发域密钥识别邮件（DKIM）的威胁分析
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks.
本文档分析了针对Internet邮件的一些威胁，这些威胁旨在通过基于签名的邮件身份验证来解决，特别是通过电子邮件识别的域密钥。它讨论了坏行为者的性质和位置，他们的能力是什么，以及他们打算通过攻击实现什么。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology and Model ......................................3
1.2. Document Structure .........................................5
2. The Bad Actors ..................................................6
2.1. Characteristics ............................................6
2.2. Capabilities ...............................................6
2.3. Location ...................................................8
2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing .....................................12
4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records
and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack against Signing
Practices ..........................................24
4.2.4. Use of Multiple From Addresses .....................24
4.2.5. Abuse of Third-Party Signatures ....................24
4.2.6. Falsification of Sender Signing Practices Replies ..25
1. Introduction ....................................................3
1.1. Terminology and Model ......................................3
1.2. Document Structure .........................................5
2. The Bad Actors ..................................................6
2.1. Characteristics ............................................6
2.2. Capabilities ...............................................6
2.3. Location ...................................................8
2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing .....................................12
4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records
and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack against Signing
Practices ..........................................24
4.2.4. Use of Multiple From Addresses .....................24
4.2.5. Abuse of Third-Party Signatures ....................24
4.2.6. Falsification of Sender Signing Practices Replies ..25
4.3. Other Attacks .............................................25
4.3.1. Packet Amplification Attacks via DNS ...............25
5. Derived Requirements ...........................................26
6. Security Considerations ........................................26
7. Informative References .........................................27
Appendix A. Acknowledgements ......................................28
4.3. Other Attacks .............................................25
4.3.1. Packet Amplification Attacks via DNS ...............25
5. Derived Requirements ...........................................26
6. Security Considerations ........................................26
7. Informative References .........................................27
Appendix A. Acknowledgements ......................................28
The DomainKeys Identified Mail (DKIM) protocol is being specified by the IETF DKIM Working Group. The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. This document addresses threats relative to two works in progress by the DKIM Working Group, the DKIM signature specification [DKIM-BASE] and DKIM Sender Signing Practices [DKIM-SSP].
IETF DKIM工作组正在指定域密钥识别邮件（DKIM）协议。DKIM协议定义了一种可以对电子邮件进行加密签名的机制，允许签名域声明对使用给定电子邮件地址的责任。消息接收者可以通过直接查询签名者的域以检索适当的公钥来验证签名，从而确认消息已由拥有签名域私钥的一方证明。本文件阐述了与DKIM工作组正在进行的两项工作相关的威胁，即DKIM签名规范[DKIM-BASE]和DKIM发送方签名实践[DKIM-SSP]。
Once the attesting party or parties have been established, the recipient may evaluate the message in the context of additional information such as locally-maintained whitelists, shared reputation services, and/or third-party accreditation. The description of these mechanisms is outside the scope of the IETF DKIM Working Group effort. By applying a signature, a good player enables a verifier to associate a positive reputation with the message, in hopes that it will receive preferential treatment by the recipient.
一旦认证方成立，接收方可在附加信息的背景下评估信息，如本地维护的白名单、共享声誉服务和/或第三方认证。这些机制的描述不在IETF工作组的范围内。通过应用签名，一个好的玩家可以让验证者将正面的声誉与消息联系起来，希望它能得到接收者的优惠待遇。
This effort is not intended to address threats associated with message confidentiality nor does it intend to provide a long-term archival signature.
这项工作不是为了解决与消息机密性相关的威胁，也不是为了提供长期存档签名。
An administrative unit (AU) is the portion of the path of an email message that is under common administration. The originator and recipient typically develop trust relationships with the administrative units that send and receive their email, respectively, to perform the signing and verification of their messages.
管理单元（AU）是电子邮件路径中受共同管理的部分。发起者和接收者通常与分别发送和接收其电子邮件的管理单位建立信任关系，以对其邮件进行签名和验证。
The origin address is the address on an email message, typically the RFC 2822 From: address, which is associated with the alleged author of the message and is displayed by the recipient's Mail User Agent (MUA) as the source of the message.
原始地址是电子邮件上的地址，通常是RFC 2822 From:address，它与据称的邮件作者关联，并由收件人的邮件用户代理（MUA）显示为邮件的来源。
The following diagram illustrates a typical usage flowchart for DKIM:
下图说明了DKIM的典型使用流程图：
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
DKIM operates entirely on the content (body and selected header fields) of the message, as defined in RFC 2822 [RFC2822]. The transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and such elements as the envelope-from and envelope-to addresses and the HELO domain are not relevant to DKIM verification. This is an intentional decision made to allow verification of messages via protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501] which an MUA acting as a verifier might use.
根据RFC 2822[RFC2822]中的定义，DKIM完全对消息的内容（正文和选定的标题字段）进行操作。通过RFC 2821[RFC2821]中定义的SMTP传输消息，以及信封发件人和信封收件人地址以及HELO域等元素与DKIM验证无关。这是为了允许通过SMTP以外的协议（例如MUA作为验证器可能使用的POP[RFC1939]和IMAP[RFC3501]）验证消息而故意做出的决定。
The Sender Signing Practices Query referred to in the diagram above is a means by which the verifier can query the alleged author's domain to determine their practices for signing messages, which in turn may influence their evaluation of the message. If, for example, a message arrives without any valid signatures, and the alleged author's domain advertises that they sign all messages, the verifier might handle that message differently than if a signature was not necessarily to be expected.
上图中提到的发送方签名实践查询是一种手段，验证者可以通过该手段查询所谓作者的域，以确定其对消息进行签名的实践，这反过来可能会影响其对消息的评估。例如，如果消息到达时没有任何有效的签名，并且被指控的作者的域宣布他们对所有消息进行了签名，那么验证者处理该消息的方式可能与不一定需要签名的情况不同。
The remainder of this document describes the problems that DKIM might be expected to address, and the extent to which it may be successful in so doing. These are described in terms of the potential bad actors, their capabilities and location in the network, and the bad acts that they might wish to commit.
本文档的其余部分描述了DKIM可能需要解决的问题，以及DKIM成功解决这些问题的程度。这些被描述为潜在的不良行为者、他们在网络中的能力和位置，以及他们可能希望实施的不良行为。
This is followed by a description of postulated attacks on DKIM message signing and on the use of Sender Signing Practices to assist in the treatment of unsigned messages. A list of derived requirements is also presented, which is intended to guide the DKIM design and review process.
接下来介绍了对DKIM消息签名的假设攻击，以及使用发送方签名实践来帮助处理未签名消息的假设攻击。还提供了衍生需求列表，用于指导DKIM设计和评审过程。
The sections dealing with attacks on DKIM each begin with a table summarizing the postulated attacks in each category along with their expected impact and likelihood. The following definitions were used as rough criteria for scoring the attacks:
关于DKIM攻击的章节都以一个表格开始，该表格总结了每类假设攻击及其预期影响和可能性。以下定义用作评分攻击的粗略标准：
Impact:
影响：
High: Affects the verification of messages from an entire domain or multiple domains
高：影响来自整个域或多个域的消息验证
Medium: Affects the verification of messages from specific users, Mail Transfer Agents (MTAs), and/or bounded time periods
介质：影响对来自特定用户、邮件传输代理（MTA）和/或限定时间段的邮件的验证
Low: Affects the verification of isolated individual messages only
低：仅影响孤立单个消息的验证
Likelihood:
可能性：
High: All email users should expect this attack on a frequent basis
高：所有电子邮件用户都应该经常遇到这种攻击
Medium: Email users should expect this attack occasionally; frequently for a few users
中等：电子邮件用户偶尔会遇到这种攻击；经常为少数用户使用
Low: Attack is expected to be rare and/or very infrequent
低：预计攻击很少和/或非常罕见
The problem space being addressed by DKIM is characterized by a wide range of attackers in terms of motivation, sophistication, and capabilities.
DKIM正在解决的问题空间在动机、复杂性和能力方面具有广泛的攻击者特征。
At the low end of the spectrum are bad actors who may simply send email, perhaps using one of many commercially available tools, that the recipient does not want to receive. These tools typically allow one to falsify the origin address of messages, and may, in the future, be capable of generating message signatures as well.
处于低端的是糟糕的参与者，他们可能只是简单地发送电子邮件，也许是使用许多商业工具中的一种，收件人不想接收。这些工具通常允许伪造消息的原始地址，并且将来可能也能够生成消息签名。
At the next tier are what would be considered "professional" senders of unwanted email. These attackers would deploy specific infrastructure, including Mail Transfer Agents (MTAs), registered domains and networks of compromised computers ("zombies") to send messages, and in some cases to harvest addresses to which to send. These senders often operate as commercial enterprises and send messages on behalf of third parties.
下一层是那些被认为是“专业”的无用电子邮件发送者。这些攻击者会部署特定的基础设施，包括邮件传输代理（MTA）、已注册的域和受损计算机网络（“僵尸”）来发送邮件，在某些情况下还会获取要发送的地址。这些发送者通常作为商业企业运营，并代表第三方发送消息。
The most sophisticated and financially-motivated senders of messages are those who stand to receive substantial financial benefit, such as from an email-based fraud scheme. These attackers can be expected to employ all of the above mechanisms and additionally may attack the Internet infrastructure itself, including DNS cache-poisoning attacks and IP routing attacks.
最老练、最有经济动机的邮件发送者是那些能够从电子邮件欺诈计划中获得巨大经济利益的人。这些攻击者可能会使用上述所有机制，并且还可能攻击互联网基础设施本身，包括DNS缓存中毒攻击和IP路由攻击。
In general, the bad actors described above should be expected to have access to the following:
一般而言，上文所述的不良行为者应能够获得以下信息：
1. An extensive corpus of messages from domains they might wish to impersonate
1. 来自他们可能希望模拟的域的大量消息
2. Knowledge of the business aims and model for domains they might wish to impersonate
2. 了解他们可能希望模拟的领域的业务目标和模型
3. Access to public keys and associated authorization records associated with the domain
3. 访问与域关联的公钥和相关授权记录
and the ability to do at least some of the following:
以及至少完成以下部分工作的能力：
1. Submit messages to MTAs and Message Submission Agents (MSAs) at multiple locations in the Internet
1. 将邮件提交到Internet上多个位置的MTA和邮件提交代理（MSA）
2. Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents
2. 构造任意消息头字段，包括那些声称是邮件列表、重发者和其他邮件代理的字段
3. Sign messages on behalf of domains under their control
3. 代表其控制下的域对邮件进行签名
4. Generate substantial numbers of either unsigned or apparently-signed messages that might be used to attempt a denial-of-service attack
4. 生成大量未签名或明显签名的消息，这些消息可能用于尝试拒绝服务攻击
5. Resend messages that may have been previously signed by the domain
5. 重新发送以前可能已由域签名的邮件
6. Transmit messages using any envelope information desired
6. 使用所需的任何信封信息发送消息
7. Act as an authorized submitter for messages from a compromised computer
7. 作为来自受损计算机的消息的授权提交者
As noted above, certain classes of bad actors may have substantial financial motivation for their activities, and therefore should be expected to have more capabilities at their disposal. These include:
如上所述，某些类别的不良行为者可能对其活动有很大的经济动机，因此应该期望他们拥有更多的能力。这些措施包括：
1. Manipulation of IP routing. This could be used to submit messages from specific IP addresses or difficult-to-trace addresses, or to cause diversion of messages to a specific domain.
1. 操纵IP路由。这可用于提交来自特定IP地址或难以跟踪地址的消息，或导致消息转移到特定域。
2. Limited influence over portions of DNS using mechanisms such as cache poisoning. This might be used to influence message routing or to falsify advertisements of DNS-based keys or signing practices.
2. 使用缓存中毒等机制对DNS部分的影响有限。这可能用于影响消息路由或伪造基于DNS的密钥或签名实践的广告。
3. Access to significant computing resources, for example, through the conscription of worm-infected "zombie" computers. This could allow the bad actor to perform various types of brute-force attacks.
3. 获取重要的计算资源，例如，通过征募受蠕虫感染的“僵尸”计算机。这可能会让坏人执行各种类型的暴力攻击。
4. Ability to eavesdrop on existing traffic, perhaps from a wireless network.
4. 窃听现有流量的能力，可能来自无线网络。
Either of the first two of these mechanisms could be used to allow the bad actor to function as a man-in-the-middle between author and recipient, if that attack is useful.
如果攻击有用的话，前两种机制中的任何一种都可以用来让坏人充当作者和接收者之间的中间人。
Bad actors or their proxies can be located anywhere in the Internet. Certain attacks are possible primarily within the administrative unit of the claimed originator and/or recipient domain have capabilities beyond those elsewhere, as described in the below sections. Bad actors can also collude by acting from multiple locations (a "distributed bad actor").
坏演员或他们的代理人可以在互联网的任何地方找到。某些攻击可能主要发生在声称的发起人和/或接收人域的管理单元内，其能力超出其他地方，如以下各节所述。不良行为者也可以通过从多个地点采取行动进行串通（“分布式不良行为者”）。
It should also be noted that with the use of "zombies" and other proxies, externally-located bad actors may gain some of the capabilities of being located within the claimed originator's or recipient's administrative unit. This emphasizes the importance of appropriate security measures, such as authenticated submission of messages, even within administrative units.
还应注意的是，通过使用“僵尸”和其他代理，位于外部的不良行为者可能获得位于声称的发起人或接收人的管理单位内的一些能力。这就强调了适当的安全措施的重要性，例如，即使在行政单位内，也必须提交经过认证的信息。
DKIM focuses primarily on bad actors located outside of the administrative units of the claimed originator and the recipient. These administrative units frequently correspond to the protected portions of the network adjacent to the originator and recipient. It is in this area that the trust relationships required for authenticated message submission do not exist and do not scale adequately to be practical. Conversely, within these administrative units, there are other mechanisms such as authenticated message submission that are easier to deploy and more likely to be used than DKIM.
DKIM主要关注位于索赔发起人和接收人行政单位之外的不良行为者。这些管理单元通常对应于网络中与发起者和接收者相邻的受保护部分。正是在这一领域，经过身份验证的消息提交所需的信任关系不存在，并且不能充分扩展以实现实用性。相反，在这些管理单元中，还有其他机制，例如经过身份验证的消息提交，这些机制比DKIM更易于部署和使用。
External bad actors are usually attempting to exploit the "any to any" nature of email that motivates most recipient MTAs to accept messages from anywhere for delivery to their local domain. They may generate messages without signatures, with incorrect signatures, or with correct signatures from domains with little traceability. They may also pose as mailing lists, greeting cards, or other agents that legitimately send or resend messages on behalf of others.
外部不良行为者通常试图利用电子邮件的“任意对任意”性质，这促使大多数收件人MTA接受来自任何地方的邮件，并将其发送到本地域。它们可能会生成没有签名的消息、签名不正确的消息，或者来自跟踪性很差的域的签名正确的消息。他们还可以冒充邮件列表、贺卡或其他代理，合法地代表他人发送或重新发送邮件。
Bad actors in the form of rogue or unauthorized users or malware-infected computers can exist within the administrative unit corresponding to a message's origin address. Since the submission of messages in this area generally occurs prior to the application of a message signature, DKIM is not directly effective against these bad actors. Defense against these bad actors is dependent upon other means, such as proper use of firewalls, and Message Submission Agents that are configured to authenticate the author.
恶意用户或未经授权的用户或受恶意软件感染的计算机等形式的不良行为者可能存在于与邮件源地址相对应的管理单元中。由于此区域中的消息提交通常发生在应用消息签名之前，因此DKIM不能直接有效地对付这些不良行为者。对这些不良行为者的防御依赖于其他手段，例如正确使用防火墙，以及配置为验证作者身份的消息提交代理。
In the special case where the administrative unit is non-contiguous (e.g., a company that communicates between branches over the external Internet), DKIM signatures can be used to distinguish between legitimate externally-originated messages and attempts to spoof addresses in the local domain.
在行政单位不连续的特殊情况下（例如，通过外部互联网在分支机构之间进行通信的公司），DKIM签名可用于区分合法的外部来源消息和试图欺骗本地域中地址的行为。
Bad actors may also exist within the administrative unit of the message recipient. These bad actors may attempt to exploit the trust relationships that exist within the unit. Since messages will typically only have undergone DKIM verification at the administrative unit boundary, DKIM is not effective against messages submitted in this area.
在邮件收件人的管理单元中也可能存在不良参与者。这些不良行为者可能会试图利用单位内存在的信任关系。由于消息通常只在管理单元边界进行DKIM验证，因此DKIM对在该区域提交的消息无效。
For example, the bad actor may attempt to spoof a header field indicating the results of verification. This header field would normally be added by the verifier, which would also detect spoofed header fields on messages it was attempting to verify. This could be used to falsely indicate that the message was authenticated successfully.
例如，坏行为人可能试图伪造指示验证结果的头字段。此标头字段通常由验证器添加，验证器还将检测其试图验证的消息上的伪造标头字段。这可能用于错误地指示消息已成功通过身份验证。
As in the originator case, these bad actors can be dealt with by controlling the submission of messages within the administrative unit. Since DKIM permits verification to occur anywhere within the recipient's administrative unit, these threats can also be minimized by moving verification closer to the recipient, such as at the Mail Delivery Agent (MDA), or on the recipient's MUA itself.
与发起者的情况一样，可以通过控制行政单位内信息的提交来处理这些不良行为者。由于DKIM允许在收件人管理单元内的任何位置进行验证，因此也可以通过将验证移到收件人附近（例如在邮件传递代理（MDA）或收件人的MUA本身）来将这些威胁降至最低。
One of the most fundamental bad acts being attempted is the delivery of messages that are not intended to have been sent by the alleged originating domain. As described above, these messages might merely be unwanted by the recipient, or might be part of a confidence scheme or a delivery vector for malware.
试图进行的最基本的不良行为之一是传递不打算由声称的发起域发送的消息。如上所述，这些消息可能只是收件人不想要的，或者可能是恶意软件的信任方案或传递载体的一部分。
This class of bad acts includes the sending of messages that aim to obscure the identity of the actual author. In some cases, the actual sender might be the bad actor, or in other cases might be a third-party under the control of the bad actor (e.g., a compromised computer).
这类不良行为包括发送旨在掩盖实际作者身份的信息。在某些情况下，实际发送者可能是坏行为人，或者在其他情况下可能是受坏行为人控制的第三方（例如，受损的计算机）。
Particularly when coupled with sender signing practices that indicate the domain owner signs all messages, DKIM can be effective in mitigating against the abuse of addresses not controlled by bad
特别是当与表明域所有者对所有消息进行签名的发送方签名实践相结合时，DKIM可以有效地防止不受bad控制的地址滥用
actors. DKIM is not effective against the use of addresses controlled by bad actors. In other words, the presence of a valid DKIM signature does not guarantee that the signer is not a bad actor. It also does not guarantee the accountability of the signer, since DKIM does not attempt to identify the signer individually, but rather identifies the domain that they control. Accreditation and reputation systems and locally-maintained whitelists and blacklists can be used to enhance the accountability of DKIM-verified addresses and/or the likelihood that signed messages are desirable.
演员。DKIM不能有效地阻止由坏角色控制的地址的使用。换句话说，有效DKIM签名的存在并不能保证签名者不是一个坏的参与者。它也不能保证签名者的责任，因为DKIM不试图单独识别签名者，而是识别他们控制的域。认证和声誉系统以及本地维护的白名单和黑名单可用于增强DKIM验证地址的责任和/或需要签名消息的可能性。
A second major class of bad acts involves the assertion of specific identities in email.
第二大类不良行为涉及在电子邮件中声明特定身份。
Note that some bad acts involving specific identities can sometimes be accomplished, although perhaps less effectively, with similar looking identities that mislead some recipients. For example, if the bad actor is able to control the domain "examp1e.com" (note the "one" between the p and e), they might be able to convince some recipients that a message from admin@examp1e.com is really from admin@example.com. Similar types of attacks using internationalized domain names have been hypothesized where it could be very difficult to see character differences in popular typefaces. Similarly, if example2.com was controlled by a bad actor, the bad actor could sign messages from bigbank.example2.com, which might also mislead some recipients. To the extent that these domains are controlled by bad actors, DKIM is not effective against these attacks, although it could support the ability of reputation and/or accreditation systems to aid the user in identifying them.
请注意，某些涉及特定身份的不良行为有时可能会通过类似的身份误导某些接收者而完成，尽管效果可能较低。例如，如果坏角色能够控制域“examp1e.com”（注意p和e之间的“one”），那么他们可能能够说服某些收件人admin@examp1e.com是真的吗admin@example.com. 使用国际化域名的类似类型的攻击被假设为很难在流行字体中看到字符差异。类似地，如果example2.com由坏行为人控制，坏行为人可能会签署来自bigbank.example2.com的消息，这也可能误导某些收件人。如果这些域由坏人控制，DKIM无法有效抵御这些攻击，尽管它可以支持声誉和/或认证系统帮助用户识别这些域。
DKIM is effective against the use of specific identities only when there is an expectation that such messages will, in fact, be signed. The primary means for establishing this is the use of Sender Signing Practices (SSP), which will be specified by the IETF DKIM Working Group.
只有当DKIM的实际有效使用时，才会对DKIM进行签名。确定这一点的主要方法是使用发送方签名实践（SSP），这将由IETF DKIM工作组指定。
One reason for asserting a specific origin address is to encourage a recipient to read and act on particular email messages by appearing to be an acquaintance or previous correspondent that the recipient might trust. This tactic has been used by email-propagated malware that mail themselves to addresses in the infected host's address book. In this case, however, the author's address may not be falsified, so DKIM would not be effective in defending against this act.
声明特定的原始地址的一个原因是鼓励收件人阅读特定的电子邮件并对其采取行动，表现为收件人可能信任的熟人或以前的通讯员。这种策略已被电子邮件传播的恶意软件使用，这些恶意软件将自己发送到受感染主机通讯簿中的地址。然而，在本案中，提交人的地址不得伪造，因此DKIM无法有效地为这一行为辩护。
It is also possible for address books to be harvested and used by an attacker to post messages from elsewhere. DKIM could be effective in mitigating these acts by limiting the scope of origin addresses for which a valid signature can be obtained when sending the messages from other locations.
攻击者还可能获取地址簿并利用其从其他地方发布消息。DKIM可以通过限制从其他位置发送消息时可以获得有效签名的源地址的范围来有效缓解这些行为。
Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author.
与基于电子邮件的欺诈相关的不良行为通常（但并非总是）涉及使用其他实体的特定原始地址传输消息，作为欺诈计划的一部分。使用特定的来源地址有时有助于使收件人相信邮件实际上是由被指控的作者发送的，从而有助于欺诈的成功。
To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use.
如果欺诈行为的成功取决于或通过使用特定的原始地址而增强，则不良行为人可能有重大的财务动机和资源来规避为保护特定地址不被未经授权使用而采取的任何措施。
When signatures are verified by or for the recipient, DKIM is effective in defending against the fraudulent use of origin addresses on signed messages. When the published sender signing practices of the origin address indicate that all messages from that address should be signed, DKIM further mitigates against the attempted fraudulent use of the origin address on unsigned messages.
当收件人验证签名或为收件人验证签名时，DKIM可有效防止欺诈性使用签名邮件的原始地址。当源地址的已发布发件人签名实践表明来自该地址的所有邮件都应签名时，DKIM可进一步降低未签名邮件上欺诈性使用源地址的企图。
Another motivation for using a specific origin address in a message is to harm the reputation of another, commonly referred to as a "joe-job". For example, a commercial entity might wish to harm the reputation of a competitor, perhaps by sending unsolicited bulk email on behalf of that competitor. It is for this reason that reputation systems must be based on an identity that is, in practice, fairly reliable.
在邮件中使用特定来源地址的另一个动机是损害他人的声誉，通常称为“joe job”。例如，商业实体可能希望通过代表竞争对手发送未经请求的批量电子邮件来损害竞争对手的声誉。正是由于这个原因，声誉体系必须建立在一个在实践中相当可靠的身份基础上。
A commonly-used tactic by some bad actors is the indirect transmission of messages by intentionally mis-addressing the message and causing it to be "bounced", or sent to the return address (RFC 2821 envelope-from address) on the message. In this case, the specific identity asserted in the email is that of the actual target of the message, to whom the message is "returned".
一些不良行为者常用的一种策略是，通过故意对消息寻址错误并导致消息被“反弹”或发送到消息上的返回地址（RFC 2821信封发件人地址）来间接传输消息。在这种情况下，电子邮件中声明的特定身份是消息的实际目标的身份，消息将“返回”给该目标。
DKIM does not, in general, attempt to validate the RFC2821.mailfrom return address on messages, either directly (noting that the mailfrom
DKIM通常不会直接尝试验证消息上的RFC2821.mailfrom返回地址（注意mailfrom
address is an element of the SMTP protocol, and not the message content on which DKIM operates), or via the optional Return-Path header field. Furthermore, as is noted in Section 4.4 of RFC 2821 [RFC2821], it is common and useful practice for a message's return path not to correspond to the origin address. For these reasons, DKIM is not effective against reflection attacks.
地址是SMTP协议的一个元素，而不是DKIM操作的邮件内容），或通过可选的返回路径标头字段。此外，如RFC 2821[RFC2821]第4.4节所述，消息的返回路径不对应于源地址是常见且有用的做法。由于这些原因，DKIM对反射攻击无效。
Bad actors can be expected to exploit all of the limitations of message authentication systems. They are also likely to be motivated to degrade the usefulness of message authentication systems in order to hinder their deployment. Both the signature mechanism itself and declarations made regarding use of message signatures (referred to here as Sender Signing Practices or SSP) can be expected to be the target of attacks.
坏的参与者可能会利用消息身份验证系统的所有限制。他们还可能被动机降低消息身份验证系统的有用性，以阻碍其部署。签名机制本身和关于消息签名使用的声明（此处称为发件人签名实践或SSP）都可能成为攻击的目标。
The following is a summary of postulated attacks against DKIM signatures:
以下是针对DKIM签名的假设攻击摘要：
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel attack| High | Low |
| Chosen message replay | Low | M/H |
| Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key service| High | Medium |
| Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low |
| Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low |
| signatures | | |
| Cryptographic weaknesses in signature | High | Low |
| generation | | |
| Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium |
| network | | |
| Verification probe attack | Medium | Medium |
| Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel attack| High | Low |
| Chosen message replay | Low | M/H |
| Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key service| High | Medium |
| Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low |
| Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low |
| signatures | | |
| Cryptographic weaknesses in signature | High | Low |
| generation | | |
| Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium |
| network | | |
| Verification probe attack | Medium | Medium |
| Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+
Message signing technologies such as DKIM are vulnerable to theft of the private keys used to sign messages. This includes "out-of-band" means for this theft, such as burglary, bribery, extortion, and the like, as well as electronic means for such theft, such as a compromise of network and host security around the place where a private key is stored.
诸如DKIM之类的消息签名技术容易受到用于签名消息的私钥被盗的攻击。如盗取主机的私钥，以及对周围的电子设备的勒索等手段。
Keys that are valid for all addresses in a domain typically reside in MTAs that should be located in well-protected sites, such as data centers. Various means should be employed for minimizing access to private keys, such as non-existence of commands for displaying their value, although ultimately memory dumps and the like will probably contain the keys. Due to the unattended nature of MTAs, some countermeasures, such as the use of a pass phrase to "unlock" a key, are not practical to use. Other mechanisms, such as the use of dedicated hardware devices that contain the private key and perform the cryptographic signature operation, would be very effective in denying export of the private key to those without physical access to the device. Such devices would almost certainly make the theft of the key visible, so that appropriate action (revocation of the corresponding public key) can be taken should that happen.
对域中的所有地址有效的密钥通常位于MTA中，MTA应位于受良好保护的站点（如数据中心）中。应采用各种方法来最小化对私钥的访问，例如不存在用于显示其值的命令，尽管最终内存转储等可能会包含密钥。由于MTA的无人值守性质，一些对策（如使用密码短语“解锁”钥匙）不实用。其他机制，例如使用包含私钥并执行加密签名操作的专用硬件设备，将非常有效地拒绝将私钥导出给那些没有物理访问该设备的人。这样的设备几乎肯定会使钥匙被盗可见，因此，如果发生这种情况，可以采取适当的行动（撤销相应的公钥）。
There are several circumstances where a domain owner will want to delegate the ability to sign messages for the domain to an individual user or a third party associated with an outsourced activity such as a corporate benefits administrator or a marketing campaign. Since these keys may exist on less well-protected devices than the domain's own MTAs, they will in many cases be more susceptible to compromise.
在某些情况下，域所有者希望将为域签名邮件的能力委托给个人用户或与外包活动（如公司福利管理员或营销活动）相关的第三方。由于这些密钥可能存在于比域自己的MTA保护较差的设备上，因此在许多情况下，它们更容易被泄露。
In order to mitigate this exposure, keys used to sign such messages can be restricted by the domain owner to be valid for signing messages only on behalf of specific addresses in the domain. This maintains protection for the majority of addresses in the domain.
为了减轻这种暴露，域所有者可以限制用于签名此类消息的密钥仅对代表域中特定地址的消息进行签名有效。这将为域中的大多数地址提供保护。
A related threat is the exploitation of weaknesses in the delegation process itself. This threat can be mitigated through the use of customary precautions against the theft of private keys and the falsification of public keys in transit. For example, the exposure to theft can be minimized if the delegate generates the keypair to be used, and sends the public key to the domain owner. The exposure to falsification (substitution of a different public key) can be reduced if this transmission is signed by the delegate and verified by the domain owner.
一个相关的威胁是利用授权过程本身的弱点。这种威胁可以通过使用惯常的预防措施来减轻，防止私钥被盗和在运输过程中伪造公钥。例如，如果代理生成要使用的密钥对，并将公钥发送给域所有者，则可以将被盗风险降至最低。如果此传输由代理签名并由域所有者验证，则可以减少伪造（替换不同公钥）的风险。
All popular digital signature algorithms are subject to a variety of side channel attacks. The most well-known of these are timing channels [Kocher96], power analysis [Kocher99], and cache timing analysis [Bernstein04]. Most of these attacks require either physical access to the machine or the ability to run processes directly on the target machine. Defending against these attacks is out of scope for DKIM.
所有流行的数字签名算法都会受到各种边通道攻击。其中最著名的是定时通道[Kocher96]、功率分析[Kocher99]和缓存定时分析[Bernstein04]。大多数攻击都需要物理访问机器或直接在目标机器上运行进程。DKIM无法防御这些攻击。
However, remote timing analysis (at least on local area networks) is known to be feasible [Boneh03], particularly in server-type platforms where the attacker can inject traffic that will immediately be subject to the cryptographic operation in question. With enough samples, these techniques can be used to extract private keys even in the face of modest amounts of noise in the timing measurements.
然而，远程定时分析（至少在局域网上）是可行的[Boneh03]，特别是在服务器型平台中，攻击者可以注入流量，这些流量将立即受到相关密码操作的影响。有了足够的样本，这些技术可以用于提取私钥，即使在定时测量中遇到少量的噪声。
The three commonly proposed countermeasures against timing analysis are:
针对时间分析，通常提出的三种对策是：
1. Make the operation run in constant time. This turns out in practice to be rather difficult.
1. 使操作在恒定时间内运行。事实证明，这在实践中相当困难。
2. Make the time independent of the input data. This can be difficult, but see [Boneh03] for more details.
2. 使时间独立于输入数据。这可能很困难，但有关更多详细信息，请参见[Boneh03]。
3. Use blinding. This is generally considered the best current practice countermeasure, and while not proved generally secure is a countermeasure against known timing attacks. It adds about 2-10% to the cost of the operation and is implemented in many common cryptographic libraries. Unfortunately, Digital Signature Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have standard methods though some defenses may exist.
3. 使用盲法。这通常被认为是当前最佳实践对策，虽然未证明通常是安全的，但却是针对已知定时攻击的对策。它增加了大约2-10%的操作成本，并在许多常见的加密库中实现。不幸的是，数字签名算法（DSA）和椭圆曲线DSA（ECDSA）虽然存在一些防御措施，但并没有标准的方法。
Note that adding random delays to the operation is only a partial countermeasure. Because the noise is generally uniformly distributed, a large enough number of samples can be used to average it out and extract an accurate timing signal.
请注意，向操作添加随机延迟只是一种局部对策。由于噪声通常均匀分布，因此可以使用足够多的样本对其进行平均并提取准确的定时信号。
Chosen message replay refers to the scenario where the attacker creates a message and obtains a signature for it by sending it through an MTA authorized by the originating domain to himself/herself or an accomplice. They then "replay" the signed message by sending it, using different envelope addresses, to a (typically large) number of other recipients.
所选邮件重播是指攻击者通过发起域授权的MTA将邮件发送给自己或同谋，从而创建邮件并获取其签名的场景。然后，他们通过使用不同的信封地址将签名邮件发送给（通常是大量）其他收件人来“重播”该邮件。
Due to the requirement to get an attacker-generated message signed, chosen message replay would most commonly be experienced by consumer ISPs or others offering email accounts to clients, particularly where there is little or no accountability to the account holder (the attacker in this case). One approach to solving this problem is for the domain to only sign email for clients that have passed a vetting process to provide traceability to the message originator in the event of abuse. At present, the low cost of email accounts (zero) does not make it practical for any vetting to occur. It remains to be seen whether this will be the model with signed mail as well, or whether a higher level of trust will be required to obtain an email signature.
由于需要获得攻击者生成的消息签名，消费者ISP或向客户端提供电子邮件帐户的其他人通常会体验到选择的消息重播，特别是在对帐户持有人（本例中的攻击者）几乎没有责任的情况下。解决此问题的一种方法是，域仅为通过审查流程的客户端签署电子邮件，以便在发生滥用时向消息发起人提供可追溯性。目前，电子邮件帐户的低成本（零）使得任何审查都不可行。这是否也是带有签名邮件的模型，或者是否需要更高级别的信任才能获得电子邮件签名，还有待观察。
A variation on this attack involves the attacker sending a message with the intent of obtaining a signed reply containing their original message. The reply might come from an innocent user or might be an automatic response such as a "user unknown" bounce message. In some cases, this signed reply message might accomplish the attacker's objectives if replayed. This variation on chosen message replay can be mitigated by limiting the extent to which the original content is quoted in automatic replies, and by the use of complementary mechanisms such as egress content filtering.
此攻击的一种变体是攻击者发送消息，目的是获取包含其原始消息的签名回复。回复可能来自无辜用户，也可能是自动响应，如“用户未知”跳出消息。在某些情况下，如果重播此签名回复消息，可能会实现攻击者的目标。通过限制自动回复中引用原始内容的范围，以及使用出口内容过滤等补充机制，可以缓解所选消息重播的这种变化。
Revocation of the signature or the associated key is a potential countermeasure. However, the rapid pace at which the message might be replayed (especially with an army of "zombie" computers), compared with the time required to detect the attack and implement the revocation, is likely to be problematic. A related problem is the likelihood that domains will use a small number of signing keys for a large number of customers, which is beneficial from a caching standpoint but is likely to result in a great deal of collateral damage (in the form of signature verification failures) should a key be revoked suddenly.
撤销签名或相关密钥是一种潜在的对策。然而，与检测攻击和实施撤销所需的时间相比，消息的快速重放速度（特别是在“僵尸”计算机大军的情况下）可能存在问题。一个相关的问题是，域可能会为大量客户使用少量签名密钥，这从缓存的角度来看是有益的，但如果突然撤销密钥，则可能会导致大量附带损害（以签名验证失败的形式）。
Signature revocation addresses the collateral damage problem at the expense of significant scaling requirements. At the extreme, verifiers could be required to check for revocation of each signature verified, which would result in very significant transaction rates. An alternative, "revocation identifiers", has been proposed, which would permit revocation on an intermediate level of granularity, perhaps on a per-account basis. Messages containing these identifiers would result in a query to a revocation database, which might be represented in DNS.
签名撤销以显著的扩展需求为代价解决了附带损害问题。在极端情况下，需要验证者对每个交易的撤销进行检查，这将导致非常严重的签名撤销。提出了另一种“撤销标识符”，允许在中间粒度级别上撤销，可能是在每个帐户的基础上。包含这些标识符的消息将导致对吊销数据库的查询，该数据库可能在DNS中表示。
Further study is needed to determine if the benefits from revocation (given the potential speed of a replay attack) outweigh the transactional cost of querying a revocation database.
需要进一步研究以确定撤销的好处（考虑到重播攻击的潜在速度）是否超过查询撤销数据库的事务成本。
Signed message replay refers to the retransmission of already-signed messages to additional recipients beyond those intended by the author or the original poster of the message. The attacker arranges to receive a message from the victim, and then retransmits it intact but with different envelope addresses. This might be done, for example, to make it look like a legitimate sender of messages is sending a large amount of spam. When reputation services are deployed, this could damage the author's reputation or that of the author's domain.
签名邮件重播是指将已签名的邮件重新传输给其他收件人，而不是作者或邮件原始海报所指定的收件人。攻击者安排接收来自受害者的消息，然后使用不同的信封地址完整地重新传输该消息。例如，可以这样做，使其看起来像一个合法的消息发送者正在发送大量的垃圾邮件。部署声誉服务时，这可能会损害作者的声誉或作者所在域的声誉。
A larger number of domains are potential victims of signed message replay than chosen message replay because the former does not require the ability for the attacker to send messages from the victim domain. However, the capabilities of the attacker are lower. Unless coupled with another attack such as body length limit abuse, it isn't possible for the attacker to use this, for example, for advertising.
与选定的消息重播相比，更多的域是签名消息重播的潜在受害者，因为前者不要求攻击者能够从受害者域发送消息。但是，攻击者的能力较低。除非再加上另一种攻击，例如滥用体长限制，否则攻击者不可能将其用于广告。
Many mailing lists, especially those that do not modify the content of the message and signed header fields and hence do not invalidate the signature, engage in a form of signed message replay. The use of body length limits and other mechanisms to enhance the survivability of messages effectively enhances the ability to do so. The only things that distinguish this case from undesirable forms of signed message replay is the intent of the replayer, which cannot be determined by the network.
许多邮件列表，特别是那些不修改邮件内容和签名头字段，因此不会使签名无效的邮件列表，都采用了签名邮件重播的形式。使用正文长度限制和其他机制来增强消息的生存能力可以有效地增强这样做的能力。唯一能将这种情况与不受欢迎的签名消息重放形式区分开来的是重放层的意图，这是网络无法确定的。
While it takes some computing resources to sign and verify a signature, it takes negligible computing resources to generate an invalid signature. An attacker could therefore construct a "make work" attack against a verifier, by sending a large number of incorrectly-signed messages to a given verifier, perhaps with multiple signatures each. The motivation might be to make it too expensive to verify messages.
虽然签名和验证签名需要一些计算资源，但生成无效签名所需的计算资源可以忽略不计。因此，攻击者可以通过向给定的验证器发送大量未正确签名的消息（可能每个消息都有多个签名），对验证器发起“使工作”攻击。其动机可能是使验证消息的成本过高。
While this attack is feasible, it can be greatly mitigated by the manner in which the verifier operates. For example, it might decide to accept only a certain number of signatures per message, limit the maximum key size it will accept (to prevent outrageously large signatures from causing unneeded work), and verify signatures in a particular order. The verifier could also maintain state representing the current signature verification failure rate and adopt a defensive posture when attacks may be under way.
虽然这种攻击是可行的，但可以通过验证器的操作方式大大减轻这种攻击。例如，它可能决定每个消息只接受一定数量的签名，限制它将接受的最大密钥大小（以防止异常大的签名导致不必要的工作），并按特定顺序验证签名。验证器还可以保持表示当前签名验证失败率的状态，并在可能发生攻击时采取防御姿态。
An attacker might also attempt to degrade the availability of an originator's key service, in order to cause that originator's messages to be unverifiable. One way to do this might be to quickly send a large number of messages with signatures that reference a particular key, thereby creating a heavy load on the key server. Other types of DoS attacks on the key server or the network infrastructure serving it are also possible.
攻击者还可能试图降低发起人密钥服务的可用性，以导致该发起人的消息无法验证。一种方法可能是快速发送大量带有引用特定密钥的签名的消息，从而在密钥服务器上造成沉重的负载。对密钥服务器或为其提供服务的网络基础设施的其他类型的DoS攻击也是可能的。
The best defense against this attack is to provide redundant key servers, preferably on geographically-separate parts of the Internet. Caching also helps a great deal, by decreasing the load on authoritative key servers when there are many simultaneous key requests. The use of a key service protocol that minimizes the transactional cost of key lookups is also beneficial. It is noted that the Domain Name System has all these characteristics.
针对这种攻击的最佳防御措施是提供冗余的密钥服务器，最好是在互联网的地理位置不同的部分。缓存也有很大帮助，当同时有许多密钥请求时，它可以减少权威密钥服务器上的负载。使用密钥服务协议将密钥查找的事务成本降至最低也是有益的。值得注意的是，域名系统具有所有这些特征。
Canonicalization algorithms represent a tradeoff between the survival of the validity of a message signature and the desire not to allow the message to be altered inappropriately. In the past, canonicalization algorithms have been proposed that would have permitted attackers, in some cases, to alter the meaning of a message.
规范化算法代表了在消息签名的有效性和不允许消息被不适当地修改之间的折衷。在过去，已经提出了规范化算法，在某些情况下允许攻击者改变消息的含义。
Message signatures that support multiple canonicalization algorithms give the signer the ability to decide the relative importance of signature survivability and immutability of the signed content. If an unexpected vulnerability appears in a canonicalization algorithm in general use, new algorithms can be deployed, although it will be a slow process because the signer can never be sure which algorithm(s) the verifier supports. For this reason, canonicalization algorithms, like cryptographic algorithms, should undergo a wide and careful review process.
支持多种规范化算法的消息签名使签名者能够确定签名生存性和签名内容不变性的相对重要性。如果在一般使用的规范化算法中出现意外漏洞，可以部署新算法，尽管这将是一个缓慢的过程，因为签名者永远无法确定验证器支持哪种算法。因此，规范化算法和密码算法一样，应该经历一个广泛而仔细的审查过程。
A body length limit is an optional indication from the signer of how much content has been signed. The verifier can either ignore the limit, verify the specified portion of the message, or truncate the message to the specified portion and verify it. The motivation for this feature is the behavior of many mailing lists that add a trailer, perhaps identifying the list, at the end of messages.
正文长度限制是签名者关于签名内容数量的可选指示。验证器可以忽略限制、验证消息的指定部分，或者将消息截断到指定部分并进行验证。此功能的动机是许多邮件列表的行为，这些邮件列表在邮件末尾添加了一个预告，可能是标识列表。
When body length limits are used, there is the potential for an attacker to add content to the message. It has been shown that this content, although at the end, can cover desirable content, especially in the case of HTML messages.
使用正文长度限制时，攻击者可能会向邮件中添加内容。已经证明，尽管最终这些内容可以覆盖所需的内容，特别是在HTML消息的情况下。
If the body length isn't specified, or if the verifier decides to ignore the limit, body length limits are moot. If the verifier or recipient truncates the message at the signed content, there is no opportunity for the attacker to add anything.
如果未指定主体长度，或者如果验证者决定忽略该限制，则主体长度限制是没有意义的。如果验证器或收件人在签名内容处截断消息，则攻击者没有机会添加任何内容。
If the verifier observes body length limits when present, there is the potential that an attacker can make undesired content visible to the recipient. The size of the appended content makes little difference, because it can simply be a URL reference pointing to the actual content. Receiving MUAs can mitigate this threat by, at a minimum, identifying the unsigned content in the message.
如果验证器在存在时遵守正文长度限制，则攻击者可能会使收件人看到不需要的内容。附加内容的大小差别不大，因为它可以只是指向实际内容的URL引用。接收MUA至少可以通过识别消息中未签名的内容来减轻这种威胁。
The benefits obtained by caching of key records opens the possibility that keys that have been revoked may be used for some period of time after their revocation. The best examples of this occur when a holder of a key delegated by the domain administrator must be unexpectedly deauthorized from sending mail on behalf of one or more addresses in the domain.
通过缓存密钥记录所获得的好处使已经被撤销的密钥在被撤销后可以使用一段时间。最好的例子是，域管理员委派的密钥持有人必须意外地取消代表域中一个或多个地址发送邮件的权限。
The caching of key records is normally short-lived, on the order of hours to days. In many cases, this threat can be mitigated simply by setting a short time-to-live (TTL) for keys not under the domain administrator's direct control (assuming, of course, that control of the TTL value may be specified for each record, as it can with DNS). In some cases, such as the recovery following a stolen private key belonging to one of the domain's MTAs, the possibility of theft and the effort required to revoke the key authorization must be considered when choosing a TTL. The chosen TTL must be long enough to mitigate denial-of-service attacks and provide reasonable transaction efficiency, and no longer.
关键记录的缓存通常是短期的，时间从几小时到几天不等。在许多情况下，只需为不受域管理员直接控制的密钥设置短生存时间（TTL）即可减轻此威胁（当然，假设可以为每个记录指定TTL值的控制，就像DNS一样）。在某些情况下，例如在属于某个域的MTA的私钥被盗后进行恢复，在选择TTL时必须考虑被盗的可能性以及撤销密钥授权所需的努力。所选择的TTL必须足够长，以减轻拒绝服务攻击并提供合理的事务效率，而不再是。
Rather than by attempting to obtain a private key, an attacker might instead focus efforts on the server used to publish public keys for a domain. As in the key theft case, the motive might be to allow the attacker to sign messages on behalf of the domain. This attack provides the attacker with the additional capability to remove legitimate keys from publication, thereby denying the domain the ability for the signatures on its mail to verify correctly.
攻击者可能会将精力集中在用于发布域公钥的服务器上，而不是试图获取私钥。与密钥盗窃案一样，其动机可能是允许攻击者代表域签署消息。此攻击使攻击者能够从发布中删除合法密钥，从而使域无法正确验证其邮件上的签名。
In order to limit the ability to sign a message to entities authorized by the owner of a signing domain, a relationship must be established between the signing address and the location from which a public key is obtained to verify the message. DKIM does this by publishing either the public key or a reference to it within the DNS hierarchy of the signing domain. The verifier derives the location from which to retrieve the public key from the signing address or domain. The security of the verification process is therefore dependent on the security of the DNS hierarchy for the signing domain.
为了限制签名域所有者授权的实体对消息进行签名的能力，必须在签名地址和获取公钥以验证消息的位置之间建立关系。DKIM通过在签名域的DNS层次结构中发布公钥或对公钥的引用来实现这一点。验证器从签名地址或域中获取公钥的位置。因此，验证过程的安全性取决于签名域的DNS层次结构的安全性。
An attacker might successfully compromise the host that is the primary key server for the signing domain, such as the domain's DNS master server. Another approach might be to compromise a higher-level DNS server and change the delegation of name servers for the signing domain to others under the control of the attacker.
攻击者可能会成功破坏作为签名域的主键服务器的主机，例如域的DNS主服务器。另一种方法可能是破坏更高级别的DNS服务器，并将签名域的名称服务器委派给攻击者控制下的其他服务器。
This attack can be mitigated somewhat by independent monitoring to audit the key service. Such auditing of the key service should occur by means of zone transfers rather than queries to the zone's primary server, so that the addition of records to the zone can be detected.
通过独立监视以审核密钥服务，可以在一定程度上缓解此攻击。对密钥服务的此类审核应通过区域传输而不是查询区域的主服务器来进行，以便可以检测到向区域添加的记录。
Replies from the key service may also be spoofed by a suitably positioned attacker. For DNS, one such way to do this is "cache poisoning", in which the attacker provides unnecessary (and incorrect) additional information in DNS replies, which is cached.
来自密钥服务的回复也可能被位置合适的攻击者欺骗。对于DNS，这样做的一种方式是“缓存中毒”，即攻击者在缓存的DNS回复中提供不必要（且不正确）的附加信息。
DNSSEC [RFC4033] is the preferred means of mitigating this threat, but the current uptake rate for DNSSEC is slow enough that one would not like to create a dependency on its deployment. In the case of a cache poisoning attack, the vulnerabilities created by this attack are both localized and of limited duration, although records with relatively long TTL may persist beyond the attack itself.
DNSSEC[RFC4033]是缓解这一威胁的首选手段，但目前DNSSEC的使用速度非常缓慢，人们不希望依赖其部署。在缓存中毒攻击的情况下，此攻击产生的漏洞是局部的，持续时间有限，尽管TTL相对较长的记录可能会持续到攻击本身之外。
In this attack, the attacker publishes suitably crafted key records or sends mail with intentionally malformed signatures, in an attempt to confuse the verifier and perhaps disable verification altogether. This attack is really a characteristic of an implementation vulnerability, a buffer overflow or lack of bounds checking, for example, rather than a vulnerability of the signature mechanism itself. This threat is best mitigated by careful implementation and creation of test suites that challenge the verification process.
在此攻击中，攻击者发布精心编制的密钥记录或发送带有故意错误签名的邮件，试图混淆验证器并可能完全禁用验证。这种攻击实际上是实现漏洞、缓冲区溢出或缺少边界检查的特征，而不是签名机制本身的漏洞。通过仔细实施和创建挑战验证过程的测试套件，可以最好地缓解这种威胁。
The cryptographic algorithms used to generate mail signatures, specifically the hash algorithm and digital signature generation and verification operations, may over time be subject to mathematical techniques that degrade their security. At this writing, the SHA-1 hash algorithm is the subject of extensive mathematical analysis that has considerably lowered the time required to create two messages with the same hash value. This trend can be expected to continue.
用于生成邮件签名的加密算法，特别是哈希算法和数字签名生成与验证操作，随着时间的推移，可能会受到降低其安全性的数学技术的影响。在本文中，SHA-1哈希算法是广泛数学分析的主题，它大大减少了创建具有相同哈希值的两条消息所需的时间。这一趋势有望继续下去。
One consequence of a weakness in the hash algorithm is a hash collision attack. Hash collision attacks in message signing systems involve the same person creating two different messages that have the same hash value, where only one of the two messages would normally be signed. The attack is based on the second message inheriting the signature of the first. For DKIM, this means that a sender might create a "good" message and a "bad" message, where some filter at the signing party's site would sign the good message but not the bad message. The attacker gets the good message signed, and then incorporates that signature in the bad message. This scenario is not common, but could happen, for example, at a site that does content analysis on messages before signing them.
哈希算法中的一个弱点的一个后果是哈希冲突攻击。消息签名系统中的散列冲突攻击涉及同一个人创建两条具有相同散列值的不同消息，而这两条消息中通常只有一条被签名。攻击基于继承第一条消息签名的第二条消息。对于DKIM，这意味着发送者可能会创建一条“好”消息和一条“坏”消息，其中签名方站点上的一些过滤器会对好消息进行签名，但不会对坏消息进行签名。攻击者会对好消息进行签名，然后将该签名合并到坏消息中。这种情况并不常见，但可能会发生，例如，在对邮件进行内容分析后再签名的站点。
Current known attacks against SHA-1 make this attack extremely difficult to mount, but as attacks improve and computing power becomes more readily available, such an attack could become achievable.
目前已知的针对SHA-1的攻击使得这种攻击极难发动，但随着攻击的改进和计算能力的提高，这种攻击可能会实现。
The message signature system must be designed to support multiple signature and hash algorithms, and the signing domain must be able to specify which algorithms it uses to sign messages. The choice of algorithms must be published in key records, and not only in the signature itself, to ensure that an attacker is not able to create signatures using algorithms weaker than the domain wishes to permit.
消息签名系统必须设计为支持多个签名和哈希算法，并且签名域必须能够指定用于签名消息的算法。算法的选择必须发布在密钥记录中，而不仅仅是在签名本身中，以确保攻击者无法使用比域希望允许的算法弱的算法创建签名。
Because the signer and verifier of email do not, in general, communicate directly, negotiation of the algorithms used for signing cannot occur. In other words, a signer has no way of knowing which algorithm(s) a verifier supports or (due to mail forwarding) where the verifier is. For this reason, it is expected that once message signing is widely deployed, algorithm change will occur slowly, and legacy algorithms will need to be supported for a considerable period. Algorithms used for message signatures therefore need to be secure against expected cryptographic developments several years into the future.
由于电子邮件的签名者和验证者通常不直接通信，因此无法对用于签名的算法进行协商。换句话说，签名者无法知道验证器支持哪种算法或（由于邮件转发）验证器在哪里。因此，预计一旦消息签名被广泛部署，算法更改将缓慢发生，遗留算法将需要在相当长的一段时间内得到支持。因此，用于消息签名的算法需要在未来几年针对预期的密码发展进行安全保护。
Message signatures only relate to the address-specification portion of an email address, while some MUAs only display (or some recipients only pay attention to) the display name portion of the address. This inconsistency leads to an attack where the attacker uses a From header field such as:
消息签名仅与电子邮件地址的地址规范部分相关，而某些MUA仅显示（或某些收件人仅注意）地址的显示名称部分。这种不一致性会导致攻击者使用From标头字段进行攻击，例如：
From: "Dudley DoRight" <whiplash@example.org>
From: "Dudley DoRight" <whiplash@example.org>
In this example, the attacker, whiplash@example.org, can sign the message and still convince some recipients that the message is from Dudley DoRight, who is presumably a trusted individual. Coupled with the use of a throw-away domain or email address, it may be difficult to hold the attacker accountable for using another's display name.
在本例中，攻击者，whiplash@example.org，可以在邮件上签名，但仍然可以让一些收件人相信邮件来自达德利·多赖特，他可能是一个值得信任的人。再加上使用一次性域名或电子邮件地址，攻击者可能很难对使用他人显示名负责。
This is an attack that must be dealt with in the recipient's MUA. One approach is to require that the signer's address specification (and not just the display name) be visible to the recipient.
这是必须在接收者的MUA中处理的攻击。一种方法是要求签名者的地址规范（而不仅仅是显示名）对收件人可见。
In many cases, MTAs may be configured to accept and sign messages that originate within the topological boundaries of the originator's network (i.e., within a firewall). The increasing use of compromised systems to send email presents a problem for such policies, because the attacker, using a compromised system as a proxy, can generate signed mail at will.
在许多情况下，MTA可能被配置为接受和签署在发起人网络拓扑边界内（即防火墙内）发起的邮件。越来越多地使用受损系统发送电子邮件给此类策略带来了问题，因为攻击者使用受损系统作为代理，可以随意生成签名邮件。
Several approaches exist for mitigating this attack. The use of authenticated submission, even within the network boundaries, can be used to limit the addresses for which the attacker may obtain a signature. It may also help locate the compromised system that is the source of the messages more quickly. Content analysis of outbound mail to identify undesirable and malicious content, as well as monitoring of the volume of messages being sent by users, may also prevent arbitrary messages from being signed and sent.
有几种方法可以减轻这种攻击。即使在网络边界内，也可以使用经过身份验证的提交来限制攻击者可能获得签名的地址。它还可能有助于更快地定位作为消息源的受损系统。对出站邮件进行内容分析，以识别不需要的和恶意的内容，并监控用户发送的邮件量，还可以防止对任意邮件进行签名和发送。
As noted above, bad actors (attackers) can sign messages on behalf of domains they control. Since they may also control the key service (e.g., the authoritative DNS name servers for the _domainkey subdomain), it is possible for them to observe public key lookups, and their source, when messages are verified.
如上所述，恶意参与者（攻击者）可以代表他们控制的域对消息进行签名。由于它们还可以控制密钥服务（例如，用于_domainkey子域的权威DNS名称服务器），因此在验证消息时，它们可以观察公钥查找及其来源。
One such attack, which we will refer to as a "verification probe", is to send a message with a DKIM signature to each of many addresses in a mailing list. The messages need not contain valid signatures, and each instance of the message would typically use a different selector. The attacker could then monitor key service requests and determine which selectors had been accessed, and correspondingly which addressees used DKIM verification. This could be used to target future mailings at recipients who do not use DKIM verification, on the premise that these addressees are more likely to act on the message contents.
其中一种攻击，我们称之为“验证探测”，就是向邮件列表中的每个地址发送带有DKIM签名的邮件。消息不需要包含有效的签名，消息的每个实例通常使用不同的选择器。然后，攻击者可以监视密钥服务请求并确定访问了哪些选择器，以及相应地哪些收件人使用了DKIM验证。这可用于针对不使用DKIM验证的收件人的未来邮件，前提是这些收件人更有可能对邮件内容采取行动。
In order to support the ability of a domain to sign for subdomains under its administrative control, DKIM permits the domain of a signature (d= tag) to be any higher-level domain than the signature's address (i= or equivalent). However, since there is no mechanism for determining common administrative control of a subdomain, it is possible for a parent to publish keys that are valid for any domain below them in the DNS hierarchy. In other words, mail from the domain example.anytown.ny.us could be signed using keys published by anytown.ny.us, ny.us, or us, in addition to the domain itself.
为了支持域对其管理控制下的子域进行签名的能力，DKIM允许签名域（d=标记）为比签名地址（i=或等效地址）更高级别的域。但是，由于没有确定子域的公共管理控制的机制，因此父级可以在DNS层次结构中发布对其下方的任何域有效的密钥。换句话说，来自域example.anytown.ny.us的邮件除了域本身之外，还可以使用anytown.ny.us、ny.us或us发布的密钥进行签名。
Operation of a domain always requires a trust relationship with higher-level domains. Higher-level domains already have ultimate power over their subdomains: they could change the name server delegation for the domain or disenfranchise it entirely. So it is unlikely that a higher-level domain would intentionally compromise a subdomain in this manner. However, if higher-level domains send mail on their own behalf, they may wish to publish keys at their own level. Higher-level domains must employ special care in the delegation of keys they publish to ensure that any of their subdomains are not compromised by misuse of such keys.
Operation of a domain always requires a trust relationship with higher-level domains. Higher-level domains already have ultimate power over their subdomains: they could change the name server delegation for the domain or disenfranchise it entirely. So it is unlikely that a higher-level domain would intentionally compromise a subdomain in this manner. However, if higher-level domains send mail on their own behalf, they may wish to publish keys at their own level. Higher-level domains must employ special care in the delegation of keys they publish to ensure that any of their subdomains are not compromised by misuse of such keys.translate error, please retry
The following is a summary of postulated attacks against signing practices:
以下是针对签名实践的假定攻击的摘要：
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+
Attackers may attempt to circumvent signing practices of a domain by using a domain name that is close to, but not the same as, the domain with signing practices. For instance, "example.com" might be replaced by "examp1e.com". If the message is not to be signed, DKIM does not require that the domain used actually exist (although other mechanisms may make this a requirement). Services exist to monitor domain registrations to identify potential domain name abuse, but naturally do not identify the use of unregistered domain names.
攻击者可能试图通过使用与具有签名实践的域接近但不相同的域名来规避域的签名实践。例如，“example.com”可以替换为“examp1e.com”。如果消息不需要签名，DKIM不要求所使用的域实际存在（尽管其他机制可能会要求这样）。现有的服务用于监控域名注册，以识别潜在的域名滥用，但自然不会识别未注册域名的使用。
A related attack is possible when the MUA does not render the domain name in an easily recognizable format. If, for example, a Chinese domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the unfamiliarity of that representation may enable other domains to more easily be mis-recognized as the expected domain.
当MUA无法以易于识别的格式呈现域名时，可能会发生相关攻击。例如，如果一个中文域名在“punycode”中呈现为xn--cjsp26b3obxw7f.com，那么不熟悉该表示可能会使其他域更容易被误认为是预期的域。
Users that are unfamiliar with internet naming conventions may also mis-recognize certain names. For example, users may confuse online.example.com with online-example.com, the latter of which may have been registered by an attacker.
不熟悉internet命名约定的用户也可能错误识别某些名称。例如，用户可能会将online.example.com与online-example.com混淆，后者可能已被攻击者注册。
Internationalized domain names present a special case of the look-alike domain name attack described above. Due to similarities in the appearance of many Unicode characters, domains (particularly those drawing characters from different groups) may be created that are visually indistinguishable from other, possibly high-value domains. This is discussed in detail in Unicode Technical Report 36 [UTR36].
国际化域名是上述类似域名攻击的一个特例。由于许多Unicode字符的外观相似，创建的域（特别是从不同组中绘制字符的域）可能在视觉上与其他可能的高值域无法区分。Unicode技术报告36[UTR36]对此进行了详细讨论。
Surveillance of domain registration records may point out some of these, but there are many such similarities. As in the look-alike domain attack above, this technique may also be used to circumvent sender signing practices of other domains.
对域名注册记录的监控可能会指出其中一些，但也有许多类似之处。与上面的相似域攻击一样，此技术也可用于规避其他域的发件人签名实践。
Just as the publication of public keys by a domain can be impacted by an attacker, so can the publication of Sender Signing Practices (SSP) by a domain. In the case of SSP, the transmission of large amounts of unsigned mail purporting to come from the domain can result in a heavy transaction load requesting the SSP record. More general DoS attacks against the servers providing the SSP records are possible as well. This is of particular concern since the default signing practices are "we don't sign everything", which means that SSP failures result in the verifier's failure to heed more stringent signing practices.
正如域发布公钥会受到攻击者的影响一样，域发布发件人签名实践（SSP）也会受到攻击者的影响。在SSP的情况下，传输大量声称来自域的未签名邮件可能会导致请求SSP记录的大量事务负载。也可能对提供SSP记录的服务器发起更一般的DoS攻击。这是一个特别值得关注的问题，因为默认的签名实践是“我们不签署所有内容”，这意味着SSP失败会导致验证者没有注意到更严格的签名实践。
As with defense against DoS attacks for key servers, the best defense against this attack is to provide redundant servers, preferably on geographically-separate parts of the Internet. Caching again helps a great deal, and signing practices should rarely change, so TTL values can be relatively large.
与针对关键服务器的DoS攻击的防御一样，针对这种攻击的最佳防御措施是提供冗余服务器，最好是在互联网的地理位置不同的部分。缓存同样有很大帮助，签名实践应该很少改变，因此TTL值可能相对较大。
Although this usage is never seen by most recipients, RFC 2822 [RFC2822] permits the From address to contain multiple address specifications. The lookup of Sender Signing Practices is based on the From address, so if addresses from multiple domains are in the From address, the question arises which signing practices to use. A rule (say, "use the first address") could be specified, but then an attacker could put a throwaway address prior to that of a high-value domain. It is also possible for SSP to look at all addresses, and choose the most restrictive rule. This is an area in need of further study.
尽管大多数收件人从未见过这种用法，但RFC 2822[RFC2822]允许发件人地址包含多个地址规范。发件人签名实践的查找是基于发件人地址的，因此，如果多个域的地址位于发件人地址中，则会出现使用哪种签名实践的问题。可以指定规则（例如，“使用第一个地址”），但攻击者可以将一次性地址放在高值域的地址之前。SSP也可以查看所有地址，并选择最严格的规则。这是一个需要进一步研究的领域。
In a number of situations, including mailing lists, event invitations, and "send this article to a friend" services, the DKIM signature on a message may not come from the originating address domain. For this reason, "third-party" signatures, those attached by the mailing list, invitation service, or news service, frequently need to be regarded as having some validity. Since this effectively makes it possible for any domain to sign any message, a sending
在许多情况下，包括邮件列表、活动邀请和“将本文发送给朋友”服务，邮件上的DKIM签名可能不来自原始地址域。因此，“第三方”签名，即邮件列表、邀请服务或新闻服务所附的签名，通常需要被视为具有某种有效性。由于这有效地使任何域都可以对任何消息进行签名，因此发送
domain may publish sender signing practices stating that it does not use such services, and accordingly that verifiers should view such signatures with suspicion.
域可能会发布发送方签名实践，声明它不使用此类服务，因此验证者应怀疑地查看此类签名。
However, the restrictions placed on a domain by publishing "no third-party" signing practices effectively disallows many existing uses of email. For the majority of domains that are unable to adopt these practices, an attacker may with some degree of success sign messages purporting to come from the domain. For this reason, accreditation and reputation services, as well as locally-maintained whitelists and blacklists, will need to play a significant role in evaluating messages that have been signed by third parties.
然而，通过发布“无第三方”签名实践对域施加的限制实际上禁止了电子邮件的许多现有用途。对于大多数无法采用这些做法的域，攻击者可能会在一定程度上成功签署声称来自该域的消息。因此，认证和声誉服务以及本地维护的白名单和黑名单将需要在评估已由第三方签署的邮件方面发挥重要作用。
In an analogous manner to the falsification of key service replies described in Section 4.1.12, replies to sender signing practices queries can also be falsified. One such attack would be to weaken the signing practices to make unsigned messages allegedly from a given domain appear less suspicious. Another attack on a victim domain that is not signing messages could attempt to make the domain's messages look more suspicious, in order to interfere with the victim's ability to send mail.
与第4.1.12节中描述的伪造关键服务回复类似，对发件人签名实践查询的回复也可以被伪造。其中一种攻击是削弱签名做法，使据称来自给定域的未签名邮件看起来不那么可疑。对未对邮件进行签名的受害者域的另一次攻击可能会试图使该域的邮件看起来更可疑，从而干扰受害者发送邮件的能力。
As with the falsification of key service replies, DNSSEC is the preferred means of mitigating this attack. Even in the absence of DNSSEC, vulnerabilities due to cache poisoning are localized.
与伪造密钥服务回复一样，DNSSEC是减轻此攻击的首选方法。即使在没有DNSSEC的情况下，也会定位由于缓存中毒而导致的漏洞。
This section describes attacks against other Internet infrastructure that are enabled by deployment of DKIM. A summary of these postulated attacks is as follows:
本节介绍对部署DKIM启用的其他Internet基础设施的攻击。这些假定攻击的摘要如下：
+--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+
+--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+
Recently, there has been an increase in denial-of-service attacks involving the transmission of spoofed UDP DNS requests to openly-accessible domain name servers [US-CERT-DNS]. To the extent that the response from the name server is larger than the request, the name server functions as an amplifier for such an attack.
最近，拒绝服务攻击增加，涉及将伪造的UDP DNS请求传输到可公开访问的域名服务器[US-CERT-DNS]。如果名称服务器的响应大于请求，则名称服务器将充当此类攻击的放大器。
DKIM contributes indirectly to this attack by requiring the publication of fairly large DNS records for distributing public keys. The names of these records are also well known, since the record names can be determined by examining properly-signed messages. This attack does not have an impact on DKIM itself. DKIM, however, is not the only application that uses large DNS records, and a DNS-based solution to this problem will likely be required.
DKIM要求发布相当大的DNS记录以分发公钥，从而间接助长了这种攻击。这些记录的名称也是众所周知的，因为可以通过检查正确签名的消息来确定记录名称。此攻击对DKIM本身没有影响。然而，DKIM并不是唯一使用大型DNS记录的应用程序，可能需要基于DNS的解决方案来解决此问题。
This section lists requirements for DKIM not explicitly stated in the above discussion. These requirements include:
本节列出了上述讨论中未明确说明的DKIM要求。这些要求包括：
The store for key and SSP records must be capable of utilizing multiple geographically-dispersed servers.
密钥和SSP记录的存储必须能够利用多个地理位置分散的服务器。
Key and SSP records must be cacheable, either by the verifier requesting them or by other infrastructure.
密钥和SSP记录必须是可缓存的，可由请求它们的验证器或其他基础结构缓存。
The cache time-to-live for key records must be specifiable on a per-record basis.
关键记录的缓存生存时间必须基于每个记录指定。
The signature algorithm identifier in the message must be one of the ones listed in a key record for the identified domain.
消息中的签名算法标识符必须是已标识域的密钥记录中列出的标识符之一。
The algorithm(s) used for message signatures need to be secure against expected cryptographic developments several years in the future.
用于消息签名的算法需要在未来几年针对预期的密码发展进行安全保护。
This document describes the security threat environment in which DomainKeys Identified Mail (DKIM) is expected to provide some benefit, and it presents a number of attacks relevant to its deployment.
本文档描述了安全威胁环境，其中DomainKeys Identified Mail（DKIM）有望提供一些好处，并介绍了一些与其部署相关的攻击。
[Bernstein04] Bernstein, D., "Cache Timing Attacks on AES", April 2004.
[Bernstein04]Bernstein，D.，“AES上的缓存定时攻击”，2004年4月。
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are Practical", Proc. 12th USENIX Security Symposium, 2003.
[Boneh03]Boneh，D.和D.Brumley，“远程定时攻击是可行的”，Proc。第12届USENIX安全研讨会，2003年。
[DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM) Signatures", Work in Progress, August 2006.
[DKIM-BASE]Allman，E.“域密钥识别邮件（DKIM）签名”，正在进行的工作，2006年8月。
[DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in Progress, August 2006.
[DKIM-SSP]Allman，E.，“DKIM发送者签名实践”，正在进行的工作，2006年8月。
[Kocher96] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, and other Cryptosystems", Advances in Cryptology, pages 104-113, 1996.
[Kocher96]Kocher，P.，“对Diffie-Hellman、RSA和其他密码系统实现的定时攻击”，《密码学进展》，第104-113页，1996年。
[Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power Analysis: Leaking Secrets", Crypto '99, pages 388-397, 1999.
[Kocher99]Kocher，P.，Joffe，J.，和B.Yun，“差异功率分析：泄露秘密”，Crypto'99，第388-397页，1999年。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat Posed by DNS Recursion".
[US-CERT-DNS]US-CERT，“DNS递归造成的持续拒绝服务威胁”。
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", UTR 36, July 2005.
[UTR36]Davis，M.和M.Suignard，“Unicode技术报告#36：Unicode安全注意事项”，UTR36，2005年7月。
The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla, Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim mailing list for valuable suggestions and constructive criticism of earlier versions of this document.
作者希望感谢菲利普·哈勒姆·贝克、艾略特·李尔、托尼·芬奇、戴夫·克罗克、巴里·莱巴、阿维尔·哈特科克、埃里克·奥尔曼、乔恩·卡拉斯、斯蒂芬·法雷尔、道格·奥蒂斯、弗兰克·埃勒曼、埃里克·雷索拉、保罗·霍夫曼、赫克托·桑托斯、，以及ietf dkim邮件列表中的许多其他人，以获得对本文件早期版本的宝贵建议和建设性批评。
Author's Address
作者地址
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
Jim Fenton Cisco Systems，Inc.美国加利福尼亚州圣何塞塔斯曼大道西侧SJ-9/2 170号，邮编95134-1706
Phone: +1 408 526 5914
EMail: fenton@cisco.com
Phone: +1 408 526 5914
EMail: fenton@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。