Network Working Group J. Fenton
Request for Comments: 4686 Cisco Systems, Inc.
Category: Informational September 2006
Analysis of Threats Motivating DomainKeys Identified Mail (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.
この文書は、特定のドメインキー・アイデンティファイド・メールでは、シグネチャベースのメール認証によって対処されることを意図しているインターネットメールに対するいくつかの脅威の分析を提供します。それは彼らの能力があり、そして、彼らは彼らの攻撃を経由して達成しようとするものを何悪役、の性質と場所について説明します。
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
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].
ドメインキー・アイデンティファイド・メール（DKIM）プロトコルはIETF DKIM Working Groupによって指定されています。 DKIMプロトコルは、所定の電子メールアドレスを使用するための責任を特徴とする署名ドメインを可能にする、電子メールメッセージを暗号署名することができる機構を定義します。メッセージ受信者は、適切な公開鍵を取得するために直接署名者のドメインに問い合わせることによって、署名を検証し、それによってメッセージが署名ドメイン用の秘密鍵を所持してパーティによって証明されたことを確認することができます。この文書では、DKIMワーキンググループ、DKIM署名仕様[DKIM-BASE]及びDKIM送信者署名プラクティス[DKIM-SSP]により、進行中の2つの作品に対する脅威に対処しています。
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 DKIMワーキンググループの努力の範囲外です。署名を適用することにより、優れたプレイヤーは、それが受信者によって優遇を受けることを期待して、メッセージと正の評判を関連付けることが検証を可能にします。
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.
メッセージの疑惑の作者に関連付けされ、メッセージの送信元として、受信者のメールユーザエージェント（MUA）で表示されたアドレス、：元アドレスからの電子メールメッセージ、通常はRFC 2822でのアドレスです。
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 | | |
| | +---------------------------------+
+-----------+
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は、メッセージの内容（本文と選択ヘッダフィールド）に完全に動作します。 SMTPを介してメッセージの送信は、[RFC2821] RFC 2821で定義され、そしてからエンベロープおよびエンベロープのアドレスとHELOドメインなどの要素は、DKIM検証に関連しません。これは、このようなPOP [RFC1939]やIMAPなどのSMTP以外のプロトコルを介してメッセージの検証を可能にするために作られた意図的な決定であるMUAは、検証として働く[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が対処することが期待される可能性のある問題、およびそれはそうすることで成功する可能性がある程度を説明しています。これらは、潜在的な悪役、ネットワークにおけるそれらの機能と場所、そして、彼らがコミットしたいかもしれない悪い行為の観点から説明されています。
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.
スペクトルの低終わりに、単に受信者が受信したくないことを、おそらく多くの市販のツールのいずれかを使用して、電子メールを送信することが悪役です。これらのツールは、典型的には、1つのメッセージの発信元アドレスを改ざんすることができ、そして、将来的には、同様にメッセージの署名を生成することができます。
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.インターネットに複数の場所でのMTAとメッセージ服従エージェント（のMSA）にメッセージを送信
2. Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents
2.リスト、resenders、および他のメールエージェントを郵送することが主張するものを含む任意のメッセージヘッダフィールドを構築
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.再送信メッセージ
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.
IPルーティングの1.操作。これは、特定の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.
こうしたキャッシュポイズニングなどのメカニズムを使用してDNSの部分の上2.リミテッド影響。これは、メッセージのルーティングに影響を与えるためか、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.
これらのメカニズムの最初の二つのいずれかがその攻撃が有用であれば、悪い俳優は、著者と受信者の間のman-in-the-middleとして機能できるようにするために使用することができます。
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 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は、個別に署名者を識別しようとしないためにも、署名者の説明責任を保証するものではありませんが、むしろ彼らは制御ドメインを識別します。認定と評判システムとローカルに維持ホワイトリストとブラックリストは、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.
特定のアイデンティティに関わるいくつかの悪い行為が時々一部の受信者を欺く似て探してアイデンティティと、おそらくあまり効果が達成できることに注意してください。 （pとEの間に「1」を注意してください）例えば、悪い俳優がドメインを制御することが可能であるならば、「examp1e.com」、彼らは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は、このようなメッセージは、実際には、署名されるという期待がある場合にのみ、特定のIDの使用に対して有効です。これを確立するための主な手段は、IETF DKIMワーキンググループによって指定される送信者の署名・プラクティス（SSP）を使用すること、です。
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.
メッセージ内の特定の発信元アドレスを使用する別の動機は、一般に「ジョー・ジョブ」と呼ばれる、別の評判を傷つけることです。例えば、商業団体は、おそらくその競争者を代表して迷惑メールを送信することで、競合他社の評判を傷つけることを望むかもしれません。これは、評判システムは、実際には、かなり信頼性のあるアイデンティティに基づくものでなければならないのはこのためです。
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 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.
DKIMはないが、一般的に、直接、または任意介して（MAILFROMアドレスはSMTPプロトコルの要素ではなく、DKIMが動作するメッセージの内容であることに注意）、メッセージにRFC2821.mailfromリターンアドレスを検証しようとしリターンパスヘッダフィールドを。 RFC 2821のセクション4.4 [RFC2821]に注目されるようにさらに、それは元アドレスに対応していないメッセージのリターンパスのための一般的かつ有用な慣行です。これらの理由から、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 |
+---------------------------------------------+--------+------------+
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の無人性質のために、そのようなパスフレーズの使用など、いくつかの対策が、キーを「アンロック」するために、使用するのは実用的ではありません。そのような秘密鍵を含む暗号署名動作を行う専用ハードウェア・デバイスの使用などの他の機構は、デバイスに物理的にアクセスすることなく、それらの秘密鍵のエクスポートを拒否するのに非常に有効です。それが起こるはず適切な処置（対応する公開鍵の失効）が撮影することができますように、このようなデバイスは、ほぼ確実に、キー表示の盗難になるだろう。
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:
タイミング解析に対する3一般的に提案されている対策は、以下のとおりです。
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.
まばゆいばかりの使用。これは、一般的に現在のベストプラクティスの対策を検討している、と一般的に安全な証明されていないが、既知のタイミング攻撃に対する対策があります。これは、運用コストを約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やクライアントへの電子メールアカウントを提供する他の人が経験することになるため（この場合、攻撃者）。この問題を解決するための1つのアプローチは、虐待のイベントでメッセージの発信にトレーサビリティを提供するために、審査プロセスに合格したクライアントに対して電子メールに署名するためのドメインのためです。現時点では、電子メールアカウント（ゼロ）の低コストは、それが実用的な任意の審査が発生するために作成しません。これは同様に署名されたメールでのモデルであるかどうかを見守らなければならない、または信頼の高いレベルは、電子メールの署名を得るために必要とされるかどうか。
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.
特に、多くのメーリングリスト、メッセージおよび署名されたヘッダフィールドの内容を変更しない、したがって、署名を無効にせず、署名されたメッセージ・リプレイの形態に従事するもの。メッセージの生存率を高めるために、本体の長さの制限やその他のメカニズムの使用が効果的にそうする能力を高めます。署名されたメッセージの再生の望ましくない形態からこのケースを区別する唯一のものは、ネットワークによって決定することができないreplayerの意図です。
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.
攻撃者は、その発信者のメッセージは、検証不可能にさせるためには、発信者のキーサービスの可用性を低下させるしようとする場合があります。これを行う1つの方法は、迅速、それによって、キーサーバーに大きな負荷を作成し、特定のキーを参照する署名付きのメッセージを大量に送信することがあります。鍵サーバまたはそれにサービスを提供するネットワークインフラストラクチャ上の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.
キーレコードのキャッシングによって得られるメリットは、取り消されたキーは、その失効後のある程度の期間のために使用することができる可能性を開きます。ドメイン管理者によって委譲鍵の所有者が予期せず、ドメイン内の1つ以上のアドレスの代わりにメールを送るから認証解除しなければならないときに、この最良の例が発生します。
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でできるように。 TTLを選択する際に、ドメインのMTAのの1つに属する盗まれた秘密鍵、次のようにリカバリなどのいくつかの例では、盗難やキーの許可を取り消すために必要な努力の可能性が考慮されなければなりません。選ばれた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の場合は、これを行うにはこのような方法の1つは、攻撃者がキャッシュされている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の現在の取り込み率は1つがその展開への依存関係を作成したくないということは十分に遅いです。比較的長い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ハッシュアルゴリズムはかなり同じハッシュ値を持つ2つのメッセージを作成するのに必要な時間を低下させた大規模な数学的分析の対象です。この傾向は継続すると予想することができます。
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.
ハッシュアルゴリズムの弱点の1つの結果は、ハッシュ衝突攻撃です。メッセージの署名システムにおけるハッシュ衝突攻撃は、二つのメッセージの一方のみが正常に署名されるのと同じハッシュ値を持つ二つの異なるメッセージを作成し、同じ人物が関与します。攻撃は、最初の署名を継承する第2のメッセージに基づいています。 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： "ダドリー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、メッセージに署名し、まだメッセージはおそらく、信頼できる個人であるダドリーDoRight、からのものであることを一部の受信者を説得することができます。使い捨てのドメインまたは電子メールアドレスの使用と相まって、別の表示名を使用するための責任攻撃を保持することは困難です。
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は、署名者のアドレス（I =または同等のもの）よりも、任意の上位レベルドメインであると署名（D =タグ）のドメインを可能にします。サブドメインの一般的な管理制御を決定するためのメカニズムがないため、親がDNS階層内でその下の任意のドメインのための有効なキーを発行するためにしかし、それは可能です。つまり、ドメインexample.anytown.ny.usからのメールがドメイン自体に加えて、anytown.ny.us、ny.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.
ドメインの動作は、常に高いレベルドメインとの信頼関係が必要です。より高いレベルのドメインは、すでに自分のサブドメインに対する最終的な力を持っている：彼らは、ドメインのネームサーバーの委任を変更したり、それを完全にdisenfranchiseことができます。だから、より高いレベルのドメインが意図的にこのようにサブドメインを危うくすることはほとんどありません。上位レベルのドメインが自分に代わってメールを送信する場合は、彼らは自分のレベルでキーを発行することを望むかもしれません。より高いレベルのドメインは、彼らがサブドメインのいずれかが、このようなキーの誤用により損なわれないことを保証するために、公開鍵の代表団に特別な注意を使用しなければなりません。
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 | | |
+---------------------------------------------+--------+------------+
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が容易に認識の形式でドメイン名をレンダリングしていない場合、関連する攻撃が可能です。例えば、中国のドメイン名がxn--cjsp26b3obxw7f.comとして「Punycodeで」でレンダリングされ、場合、その表現の不慣れは、より容易に誤認識期待ドメインのように他のドメインを可能にすることができます。
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.
インターネットの命名規則に慣れていないユーザーは、特定の名前を誤認識することができます。例えば、ユーザーが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]は、複数のアドレス指定を含むようにFromアドレス可能。送信者の署名・プラクティスの検索がFromアドレスに基づいて、その複数のドメインからのアドレスがFromアドレスである場合、問題は、使用する署名プラクティス発生しています。ルールは（たとえば、「最初のアドレスを使用する」）に指定することができますが、その後、攻撃者は、前高価値ドメインと使い捨てアドレスを置くことができます。 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 domain may publish sender signing practices stating that it does not use such services, and accordingly that verifiers should view such signatures with suspicion.
メーリングリスト、イベントの招待状、および「この記事を友人に送る」サービスを含む多くの状況では、メッセージにDKIM署名は、発信アドレスのドメインから来ないかもしれません。このため、「サードパーティ」の署名、メーリングリスト、招待状サービス、またはニュースサービスによって取り付けられたものは、しばしばいくつかの妥当性を有するものとみなされる必要があります。これは効果的に任意のメッセージに署名するための任意のドメインのことが可能になりますので、送信ドメインは、それがこのようなサービスを使用していないことを示す送信者の署名プラクティスを公開すること、および検証は疑いの目で、このような署名を表示しなければならないそれに応じていること。
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の導入によって有効にされている他のインターネットインフラに対する攻撃について説明します。次のようにこれらの仮定の攻撃の概要は次のとおりです。
+--------------------------------------+--------+------------+
| 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.
この文書では、ドメインキー・アイデンティファイド・メール（DKIM）は、いくつかの利点を提供することが期待されているセキュリティの脅威環境を説明し、それはその展開に関連する攻撃の数を示します。
[Bernstein04] Bernstein, D., "Cache Timing Attacks on AES", April 2004.
[Bernstein04]バーンスタイン、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]オールマン、E.、 "DomainKeysのは、認証メール（DKIM）署名"、進歩、2006年8月に作業。
[DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in Progress, August 2006.
[DKIM-SSP]オールマン、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]コッヘル、P.、「ディフィー - ヘルマン、RSA、および他の暗号の実装上の攻撃のタイミング」は、暗号理論、ページ104-113、1996年進歩します。
[Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power Analysis: Leaking Secrets", Crypto '99, pages 388-397, 1999.
[Kocher99]コッヘル、P.、ジョフィ、J.、およびB.ユン、 "差分電力解析：漏れの秘密"、暗号'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 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]デイビス、M.とM. Suignard、 "Unicodeのテクニカルレポート＃36：Unicodeのセキュリティの考慮事項"、UTR 36、2005年7月。
Appendix A. Acknowledgements
付録A.謝辞
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.
著者はフィリップハラム - ベイカー、エリオット・リア、トニー・フィンチ、デイブ・クロッカー、バリー・レイバ、Arvel Hathcock、エリック・オールマン、ジョン・カラス、スティーブン・ファレル、ダグ・オーティス、フランクEllermann、エリックレスコラ、ポール・ホフマン、ヘクターサントス、とに感謝したいです貴重な提案や、このドキュメントの以前のバージョンの建設的な批判のために、IETF DKIMメーリングリストの多数の他。
Author's Address
著者のアドレス
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
ジム・フェントンシスコシステムズ、株式会社MS SJ-9月2日170 W.タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 526 5914 EMail: fenton@cisco.com
電話：+1 408 526 5914 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。