RFC4686 日本語訳
4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM).J. Fenton. September 2006. (Format: TXT=70382 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Fenton Request for Comments: 4686 Cisco Systems, Inc. Category: Informational September 2006
コメントを求めるワーキンググループJ.フェントンの要求をネットワークでつないでください: 4686年のシスコシステムズInc.カテゴリ: 情報の2006年9月
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
DomainKeysを動機づける脅威の分析はメールを特定しました。(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).
Copyright(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.
このドキュメントはインターネット・メールに対する署名ベースのメール認証で扱われることを意図するいくつかの脅威の分析を提供します、特定のDomainKeys Identifiedメールで。 それは演技下手な俳優、彼らの能力が何であるかということであり、およびそれらが彼らの攻撃で達成するつもりであることに関する自然と位置について議論します。
Fenton Informational [Page 1] RFC 4686 DKIM Threat Analysis September 2006
[1ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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. 序論…3 1.1. 用語とモデル…3 1.2. 構造を記録してください…5 2. 演技下手な俳優…6 2.1. 特性…6 2.2. 能力…6 2.3. 位置…8 2.3.1. 外部的に、演技下手な俳優の居場所を見つけます…8 2.3.2. 中では、創始者の行政単位が要求しました…8 2.3.3. 受取人の行政単位の中で…9 3. 代表している悪い条例…9 3.1. 任意のアイデンティティの使用…9 3.2. 特定のアイデンティティの使用…10 3.2.1. 社会的関係の攻略…10 3.2.2. アイデンティティ関連の詐欺…11 3.2.3. 評判は攻撃されます…11 3.2.4. 反射は攻撃されます…11 4. メッセージ署名に対する攻撃…12 4.1. メッセージ署名に対する攻撃…12 4.1.1. ドメインへの秘密鍵の窃盗…13 4.1.2. 代表として派遣された秘密鍵の窃盗…13 4.1.3. Side Channel Attackを通した個人的なKey Recovery…14 4.1.4. メッセージ再生を選びます…14 4.1.5. メッセージ再生であると署名されます…16 4.1.6. 検証に対するサービス不能攻撃…16 4.1.7. 主要なサービスに対するサービス不能攻撃…17 4.1.8. Canonicalization乱用…17 4.1.9. ボディー長さの限界乱用…17 4.1.10. 取り消されたキーの使用…18 4.1.11. 主要なサーバの感染…18 4.1.12. 主要にサービスの改竄は返答します…19 4.1.13. 奇形の主要な記録、そして/または、署名の公表…19 4.1.14. 署名世代における暗号の弱点。20 4.1.15. 名前乱用を表示してください…21 4.1.16. 創始者のネットワークの中の感染されたシステム…21 4.1.17. 検証徹底的調査攻撃…21 4.1.18. よりハイレベルのドメインのそばでの主要な公表…22 4.2. メッセージ署名習慣に対する攻撃…23 4.2.1. そっくりなものドメイン名…23 4.2.2. 国際化ドメイン名乱用…23 4.2.3. 署名に対するサービス不能攻撃は練習されます…24 4.2.4. アドレスからの倍数の使用…24 4.2.5. 第三者署名の乱用…24 4.2.6. 送付者署名習慣の改竄は返答します。25
Fenton Informational [Page 2] RFC 4686 DKIM Threat Analysis September 2006
[2ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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. 他の攻撃…25 4.3.1. DNSを通したパケットAmplification Attacks…25 5. 要件を引き出します…26 6. セキュリティ問題…26 7. 有益な参照…27 付録A.承認…28
1. Introduction
1. 序論
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].
DomainKeys Identifiedメール(DKIM)プロトコルはIETF DKIM作業部会によって指定されています。 DKIMプロトコルは暗号でメールメッセージに署名することができるメカニズムを定義します、署名ドメインが与えられたEメールアドレスの使用のために犯行声明を出すことを許可して。 メッセージ受取人は、適切な公開鍵を検索するために署名者のドメインについて質問することによって直接署名について確かめて、その結果、メッセージが秘密鍵の所有物のパーティーによって署名ドメインに証明されたと確認できます。 このドキュメントは、DKIMによる2個の執筆中の作品に比例した脅威がDKIM署名の作業部会と、仕様[DKIM-基地]とDKIM Sender Signing Practices[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.
証明パーティーかパーティーがいったん設立されると、受取人は局所的にwhitelists、共有された評判サービス、そして/または、第三者評価を維持したような追加情報の文脈のメッセージを評価するかもしれません。 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.
この取り組みがメッセージ秘密性に関連している脅威を扱うことを意図しないで、またそれは長期の記録保管所の署名を提供しないつもりです。
1.1. Terminology and Model
1.1. 用語とモデル
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.
発生源アドレスはメールメッセージ、通常RFC2822From:に関するアドレスです。 アドレス。(そのアドレスは、メッセージの申し立てられた作者に関連していて、メッセージの源として受取人のメール・ユーザー・エージェント(MUA)によって表示されます)。
Fenton Informational [Page 3] RFC 4686 DKIM Threat Analysis September 2006
[3ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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 | | |
| | +---------------------------------+
+-----------+
+---------------------------------+ | 署名作成| | (Auを溯源するか、またはリレーします) | | | | (メッセージ、ドメイン、キー)に署名してください。| | | +---------------------------------+ | - メッセージ(ドメイン、キー)| [インターネット]| +に対して---------------------------------+ +-----------+ | 署名照合| | | | (Auをリレーするか、または提供します) | | キー| | | | 質問+--->| (メッセージ、ドメイン、キー)について確かめてください。| | | | | +-----------+ +----------------+----------------+ | - 確かめられたドメイン+-----------+ V--[レポート]| 送付者| +----------------+----------------+ | 署名| | | | 習慣+--->| 署名者評価| | 質問| | | | | +---------------------------------+ +-----------+
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.
DKIMはRFC2822[RFC2822]で定義されるように完全なメッセージの内容(ボディーと選択されたヘッダーフィールド)を作動させます。 そして、RFC2821[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.
ダイヤグラムで上と呼ばれたSender Signing Practices Queryは検証が順番に彼らのメッセージの評価に影響を及ぼすかもしれない署名メッセージのためにそれらの習慣を決定するために申し立てられた作者のドメインについて質問できる手段です。 例えば、メッセージが少しも有効な署名なしで到着して、申し立てられた作者のドメインが、すべてのメッセージに署名するのは広告を出すなら、検証が、予想されるために署名が必ずそうであったというわけではないかどうかと異なってそのメッセージを扱わないかもしれません。
Fenton Informational [Page 4] RFC 4686 DKIM Threat Analysis September 2006
[4ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
1.2. Document Structure
1.2. ドキュメント構造
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メッセージ署名とSender Signing Practicesの使用の仮定された攻撃の記述はこれのあとに続いて、未署名のメッセージの処理を助けます。 また、派生している要件のリスト(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
媒体: 特定のユーザ、メール配達エージェント(MTAs)、そして/または、境界がある期間からメッセージの検証に影響します。
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
安値: まれである、そして/または、攻撃が非常に珍しいと予想されます。
Fenton Informational [Page 5] RFC 4686 DKIM Threat Analysis September 2006
[5ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
2. The Bad Actors
2. 演技下手な俳優
2.1. Characteristics
2.1. 特性
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.
次の層に、迷惑メールの「プロ」の送付者であると考えられるものがあります。 これらの攻撃者は特定のインフラストラクチャを配布するでしょう、メッセージを送って、いくつかの場合、発信するアドレスを取り入れるために感染しているコンピュータ(「ゾンビ」)のメール配達エージェント(MTAs)、登録されたドメイン、およびネットワークを含んでいて。 これらの送付者は、営利事業としてしばしば働いて、第三者を代表してメッセージを送ります。
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ルーティング攻撃を含んでいて。
2.2. Capabilities
2.2. 能力
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. インターネットで複数の所在地でMTAsとMessage Submissionエージェント(MSAs)にメッセージを提出してください。
Fenton Informational [Page 6] RFC 4686 DKIM Threat Analysis September 2006
[6ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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. 感染しているコンピュータからのメッセージのための認可されたsubmitterとして、機能してください。
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.
演技下手な俳優が作者と受取人の間の中央の男性として機能するのを許容するのにこれらの2つの最初のメカニズムもののどちらかを使用できました、その攻撃が役に立つなら。
Fenton Informational [Page 7] RFC 4686 DKIM Threat Analysis September 2006
[7ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
2.3. Location
2.3. 位置
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.
また、「ゾンビ」と他のプロキシの使用で、外部的に見つけられた演技下手な俳優が要求された創始者のものか受取人の行政単位の中に位置する能力のいくつかを獲得するかもしれないことに注意されるべきです。 これは行政単位の中でさえメッセージの認証された服従などの適切な安全策の重要性を強調します。
2.3.1. Externally-Located Bad Actors
2.3.1. 外部的に見つけられた演技下手な俳優
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.
通常、外部の演技下手な俳優は、どこでも、から配送のためにそれらの局所領域にメッセージを受け入れるためにほとんどの受取人MTAsを動機づけるメールの「いずれへのいずれ」本質を利用するのを試みています。 彼らは少ない追随性でドメインから署名のはない正しくない署名か、正しい署名があるメッセージを生成するかもしれません。 また、彼らは合法的に他のものを代表してメッセージを送るか、または再送するメーリングリスト、グリーティングカード、または他のエージェントのふりをするかもしれません。
2.3.2. Within Claimed Originator's Administrative Unit
2.3.2. 中では、創始者の行政単位であると主張されます。
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は直接これらの演技下手な俳優に対して有効ではありません。 これらの演技下手な俳優に対するディフェンスは他の手段に依存しています、作者を認証するために構成されるファイアウォールの適切な使用や、Message Submissionエージェントなどのように。
Fenton Informational [Page 8] RFC 4686 DKIM Threat Analysis September 2006
[8ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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署名を使用できる特別な場合と局所領域でアドレスを偽造する試みで。
2.3.3. Within Recipient's Administrative Unit
2.3.3. 受取人の行政単位の中で
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が、検証が受取人の行政単位の中でどこでも起こるのを可能にするので、また、メールDeliveryエージェントなどの受取人(MDA)の、より近くか受取人のMUA自身の上で感動的な検証でこれらの脅威を最小にすることができます。
3. Representative Bad Acts
3. 代表している悪い条例
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.
試みられる中で最も基本的な悪い行為の1つは申し立てられた起因するドメインによって送られたことを意図しないメッセージの配送です。 上で説明されるように、これらのメッセージは、受取人で単に求められていないかもしれないか、または信用体系かマルウェアのための配送ベクトルの一部であるかもしれません。
3.1. Use of Arbitrary Identities
3.1. 任意のアイデンティティの使用
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).
このクラスの悪い行為は実際の作者のアイデンティティをあいまいにすることを目指すメッセージの発信を含んでいます。 いくつかの場合、実際の送付者は、演技下手な俳優であるかもしれない、または演技下手な俳優(例えば、感染しているコンピュータ)のコントロールの下で他の場合における3番目のパーティーであるかもしれません。
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は悪いことによって制御されなかったアドレスの乱用を困難にするのにおいて有効である場合があります。
Fenton Informational [Page 9] RFC 4686 DKIM Threat Analysis September 2006
[9ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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によって確かめられたアドレスの責任、そして/または、署名しているメッセージが望ましいという見込みを高めるのに認可、評判システム、局所的に維持されたwhitelists、およびブラックリストを使用できます。
3.2. Use of Specific Identities
3.2. 特定のアイデンティティの使用
A second major class of bad acts involves the assertion of specific identities in email.
2番目の主要なクラスの悪い行為はメールにおける、特定のアイデンティティの主張にかかわります。
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の間で「1つ」に注意してください)、彼らは、 admin@examp1e.com からのメッセージが本当に admin@example.com からあると何人かの受取人に納得させることができるかもしれません。 国際化ドメイン名を使用する同様のタイプの攻撃がポピュラーな活字面のキャラクタ差を見るのが非常に難しいかもしれないところで仮定されました。 同様に、example2.comが演技下手な俳優によって制御されるなら、演技下手な俳優はbigbank.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は特定のアイデンティティの使用に対して有効です、事実上、署名されてください。 これを設立するためのプライマリ手段はSender Signing Practices(SSP)の使用です。(Sender Signing PracticesはIETF DKIM作業部会によって指定されるでしょう)。
3.2.1. Exploitation of Social Relationships
3.2.1. 社会的関係の攻略
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.
特定の発生源がアドレスであると断言する1つの理由は受取人が信じるかもしれない知人か前の通信員であるように見えることによって、受取人が特定のメールメッセージを読んで、影響するよう奨励することです。 この戦術は感染宿主のアドレス帳のアドレスへの自分たちに郵送するメールで伝播されたマルウェアによって使用されました。 しかしながら、この場合作者のアドレスが改竄されないかもしれないので、DKIMはこの行為に対して防御するのにおいて有効でないでしょう。
Fenton Informational [Page 10] RFC 4686 DKIM Threat Analysis September 2006
[10ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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は他の位置からメッセージを送るとき有効な署名を得ることができる発生源アドレスの範囲を制限することによってこれらの行為を緩和するのにおいて有効であるかもしれません。
3.2.2. Identity-Related Fraud
3.2.2. アイデンティティ関連の詐欺
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はさらに未署名のメッセージにおける発生源アドレスの試みられた盗用を困難にします。
3.2.3. Reputation Attacks
3.2.3. 評判攻撃
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-仕事」と呼ばれた別のものの評判に害を及ぼすことです。 例えば、商業実体は競争相手の評判に害を及ぼしたがっているかもしれません、恐らくその競争相手を代表して求められていない大量のメールを送ることによって。 それは評判システムをすなわち、習慣におけるかなり信頼できるアイデンティティに基礎づけなければならないこの理由であります。
3.2.4. Reflection Attacks
3.2.4. 反射攻撃
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
Fenton Informational [Page 11] RFC 4686 DKIM Threat Analysis September 2006
[11ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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が作動させるSMTPプロトコルの原理)、任意のReturn-経路ヘッダーフィールドで。 その上、そして、そのままで、RFC2821[RFC2821]のセクション4.4で有名であることで、メッセージのリターンパスが発生源アドレスと食い違うのは、一般的で役に立つ習慣です。 これらの理由で、DKIMは反射攻撃に対して有効ではありません。
4. Attacks on Message Signing
4. メッセージ署名に対する攻撃
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.
演技下手な俳優が通報認証システムの限界のすべてを利用すると予想できます。また、それらも、彼らの展開を妨げるために通報認証システムの有用性を下げるために動機づけられそうです。 攻撃の目標であると署名メカニズム自体とメッセージ署名の使用に関してされた宣言の両方(Sender Signing PracticesかSSPとしてここを参照される)を予想できます。
4.1. Attacks against Message Signatures
4.1. メッセージ署名に対する攻撃
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 | +---------------------------------------------+--------+------------+
+---------------------------------------------+--------+------------+ | 攻撃名| 影響| 見込み| +---------------------------------------------+--------+------------+ | ドメインへの秘密鍵の窃盗| 高値| 安値| | 代表として派遣された秘密鍵の窃盗| 媒体| 媒体| | サイドチャンネル攻撃を通した秘密鍵回復| 高値| 安値| | 選ばれたメッセージ再生| 安値| M/H| | メッセージ再生であると署名されます。| 安値| 高値| | 検証に対するサービス不能攻撃| 高値| 媒体| | 主要なサービスに対するサービス不能攻撃| 高値| 媒体| | Canonicalization乱用| 安値| 媒体| | ボディー長さの限界乱用| 媒体| 媒体| | 取り消されたキーの使用| 媒体| 安値| | 主要なサーバの感染| 高値| 安値| | 主要なサービス回答の改竄| 媒体| 媒体| | そして/または奇形の主要な記録の公表。| 高値| 安値| | 署名| | | | 署名における暗号の弱点| 高値| 安値| | 世代| | | | ディスプレイ名前乱用| 媒体| 高値| | 創始者のところの中の感染されたシステム| 高値| 媒体| | ネットワーク| | | | 検証徹底的調査攻撃| 媒体| 媒体| | よりハイレベルのドメインのそばでの主要な公表| 高値| 安値| +---------------------------------------------+--------+------------+
Fenton Informational [Page 12] RFC 4686 DKIM Threat Analysis September 2006
[12ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.1. Theft of Private Key for Domain
4.1.1. ドメインへの秘密鍵の窃盗
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.
ドメインのすべてのアドレスに、有効なキーはよく保護されたサイトに位置するべきであるMTAsに通常住んでいます、データセンターなどのように。 様々な手段は秘密鍵へのアクセスを最小にするのに使われるべきです、それらの値を表示するためのコマンドの非存在などのように、メモリダンプと同様のものは結局、たぶんキーを含むでしょうが。 MTAsの無人の自然のために、キーを「アンロックする」パス句の使用などのいくつかの対策は、使用するために実用的ではありません。 秘密鍵を含んでいて、暗号の署名操作を実行する専用ハードウェアデバイスの使用などの他のメカニズムはデバイスへの物理的なアクセスなしで秘密鍵の輸出をそれらに対して否定するのにおいて非常に効果的でしょう。 そのようなデバイスでキーの窃盗はほぼ確実に目に見えるようになるでしょう、それが起こるなら適切な行動(対応する公開鍵の取消し)を取ることができるように。
4.1.2. Theft of Delegated Private Key
4.1.2. 代表として派遣された秘密鍵の窃盗
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.
いくつかの事情がドメイン所有者が法人の利益管理者か販売運動などの社外調達された活動に関連している個々のユーザか第三者にドメインへのメッセージに署名する能力を代表として派遣したくなるところにあります。 これらのキーがドメインの自身のMTAsより少ないよく保護されたデバイスで存在するかもしれないので、多くの場合、彼らは妥協するのにおいて、より影響されやすくなるでしょう。
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.
関連する脅威は委譲プロセス自体の弱点の攻略です。 経験上の注意の使用で秘密鍵の窃盗とトランジットにおける、公開鍵の改竄に対してこの脅威を緩和できます。 例えば、代表が使用されるためにkeypairを生成して、ドメイン所有者に公開鍵を送るなら、窃盗への暴露を最小にすることができます。 このトランスミッションが代表によって署名されて、ドメイン所有者によって確かめられるなら、改竄(異なった公開鍵の代替)への暴露は減少できます。
Fenton Informational [Page 13] RFC 4686 DKIM Threat Analysis September 2006
[13ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.3. Private Key Recovery via Side Channel Attack
4.1.3. Side Channel Attackを通した個人的なKey Recovery
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.
3. 盲目を使用してください。 一般に、これは最も良い現在の習慣対策であると考えられます、そして、立証されない間、一般に、安全であるのは、知られているタイミング攻撃に対して対策です。 それは、操作の費用におよそ2-10%を加えて、多くの一般的な暗号の図書館で実装されます。 残念ながら、いくつかのディフェンスが存在するかもしれませんが、Digital Signature Algorithm(DSA)とElliptic Curve 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.
無作為の遅れを操作に加えるのが、部分的な対策にすぎないことに注意してください。 雑音が一般に一様に分配されるので、それを平均して、正確なタイミング信号を抜粋するのに十分多くのサンプルを使用できます。
4.1.4. Chosen Message Replay
4.1.4. 選ばれたメッセージ再生
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を通してそれを送ることによって、攻撃者がメッセージを作成するシナリオを参照して、それのための署名を得ます。 次に、彼らはそれを送ることによって、署名しているメッセージを「再演します」、異なった封筒アドレスを使用して、(通常大きい)の数の他の受取人に。
Fenton Informational [Page 14] RFC 4686 DKIM Threat Analysis September 2006
[14ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
署名取消しは重要なスケーリング要件を犠牲にしてその巻き添え被害問題を訴えます。 検証は、確かめられたそれぞれの署名の取消しがないかどうかどれが極端で非常にかなりのトランザクションレートをもたらすかをチェックできなければなりませんでした。 代替手段、「取消し識別子」(中間的レベルの粒状で取消しを可能にする)は提案されました、恐らく1アカウントあたり1個のベースで。 これらの識別子を含むメッセージが取消しデータベースへの質問をもたらすでしょう。(データベースは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.
さらなる研究が、取消し(反射攻撃の潜在的速度を与える)からの利益が取消しデータベースについて質問する取引の費用より重いかどうか決定するのに必要です。
Fenton Informational [Page 15] RFC 4686 DKIM Threat Analysis September 2006
[15ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.5. Signed Message Replay
4.1.5. メッセージ再生であると署名されます。
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.
多くのメーリングリスト(特にメッセージの内容を変更しないで、またヘッダーフィールドに署名して、したがって署名を無効にしないもの)が署名しているメッセージ再生のフォームに従事しています。 有効にメッセージの生存性を高めるボディー長さの限界と他のメカニズムの使用はそうする能力を高めます。 再生が「再-プレーヤー」の意図であるというネットワークが決定できない望ましくないフォームの署名しているメッセージと本件を区別する唯一のもの。
4.1.6. Denial-of-Service Attack against Verifier
4.1.6. 検証に対するサービス不能攻撃
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.
この攻撃が可能である間、検証が動作する方法でそれを大いに緩和できます。 例えば、それは、ある数の1メッセージあたりの署名だけを受け入れると決めて、それが受け入れる(無法に大きい署名が不要な仕事を引き起こすのを防ぐ)最大の主要なサイズを制限して、特定のオーダーにおける署名について確かめるかもしれません。 攻撃が進行中とき、検証は、また、現在の署名照合故障率を表す州を維持して、防御の姿勢を取ることができました。
Fenton Informational [Page 16] RFC 4686 DKIM Threat Analysis September 2006
[16ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.7. Denial-of-Service Attack against Key Service
4.1.7. 主要なサービスに対するサービス不能攻撃
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.
この攻撃に対する最も良いディフェンスは望ましくはインターネットの地理的に別々の地域で余分な主要なサーバを提供することです。 また、キャッシュは多くを助けます、多くの同時の主要な要求があるとき正式の主要なサーバで負荷を減少させることによって。 また、主要なルックアップの取引の費用を最小にする主要なサービスプロトコルの使用も有益です。 ドメインネームシステムにはこれらのすべての特性があることに注意されます。
4.1.8. Canonicalization Abuse
4.1.8. Canonicalization乱用
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.
Canonicalizationアルゴリズムはメッセージ署名の正当性の生存と不適当に変更されるべきメッセージを許容しない願望の間の見返りを表します。 過去に、いくつかの場合、メッセージの意味を変更するために攻撃者を可能にしたcanonicalizationアルゴリズムが提案されました。
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.
複数のcanonicalizationアルゴリズムをサポートするメッセージ署名が署名の生存性の相対的な重要性と署名している内容の不変性について決める能力を署名者に与えます。 予期していなかった脆弱性が一般に、canonicalizationアルゴリズムで現れるなら、使用、新しいアルゴリズムを配布することができます、署名者が検証がどのアルゴリズムをサポートするかを確信しているはずがないので、遅いプロセスになるでしょうが。 この理由で、暗号アルゴリズムのように、canonicalizationアルゴリズムは広くて慎重な吟味の過程を受けるべきです。
4.1.9. Body Length Limit Abuse
4.1.9. ボディー長さの限界乱用
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.
ボディー長さの限界はどのくらいの内容が署名されたかに関する署名者からの任意の指示です。 検証は、限界を無視するか、メッセージの指定された部分について確かめるか、指定された部分にメッセージに先端を切らせて、またはそれについて確かめることができます。 この特徴に関する動機はトレーラを加える多くのメーリングリストの振舞いです、恐らくリストを特定して、メッセージの終わりで。
Fenton Informational [Page 17] RFC 4686 DKIM Threat Analysis September 2006
[17ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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参照であるかもしれないので。 MUAsを受けると、最小限でメッセージの未署名の内容を特定することによって、この脅威を緩和できます。
4.1.10. Use of Revoked Key
4.1.10. 取り消されたキーの使用
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)をドメインアドミニストレータのどんな直轄でもキーに設定しないことによって、この脅威を緩和できます(もちろんDNSと共に仮定できるようにTTL価値のコントロールが各記録に指定されるかもしれないと仮定して)。 ドメインのMTAsの1つに属す盗まれた秘密鍵に続いて起こる回復などのいくつかの場合では、TTLを選ぶとき、窃盗の可能性と主要な承認を取り消すのに必要である取り組みを考えなければなりません。 選ばれたTTLはサービス不能攻撃を緩和して、妥当なトランザクション効率を提供できるくらいもう長いはずがありません。
4.1.11. Compromise of Key Server
4.1.11. 主要なサーバの感染
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.
むしろ、秘密鍵を得るのを試みるより攻撃者は代わりにドメインに公開鍵を発行するのに使用されるサーバに取り組みの焦点を合わせるかもしれません。 主要な窃盗ケースのように、動機は攻撃者がドメインを代表してメッセージに署名するのを許容することであるかもしれません。 この攻撃は公表から正統のキーを取り外す追加能力を攻撃者に提供します、その結果、メールにおける署名が正しく確かめる能力をドメインに対して否定します。
Fenton Informational [Page 18] RFC 4686 DKIM Threat Analysis September 2006
[18ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
主要なサービスを監査するためにいくらか独立しているモニターでこの攻撃を緩和できます。 主要なサービスのそのような監査は質問よりむしろゾーン転送によってゾーンのプライマリサーバに起こるべきです、ゾーンへの記録の追加を検出できるように。
4.1.12. Falsification of Key Service Replies
4.1.12. 主要なサービス回答の改竄
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は固執するかもしれません。
4.1.13. Publication of Malformed Key Records and/or Signatures
4.1.13. 奇形の主要な記録、そして/または、署名の公表
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.
攻撃者は、この攻撃では、適当に作られた主要な記録を発表するか、または故意に奇形の署名と共にメールを送ります、検証を混乱させて、恐らく全体で検証を無効にする試みで。 この攻撃は、署名メカニズム自体の脆弱性よりむしろ例えば、領域がチェックする本当に実装脆弱性の特性、バッファオーバーフローまたは不足です。 検証プロセスに挑戦するテストスイートの慎重な実装と作成でこの脅威を緩和するのは最も良いです。
Fenton Informational [Page 19] RFC 4686 DKIM Threat Analysis September 2006
[19ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.14. Cryptographic Weaknesses in Signature Generation
4.1.14. 署名世代における暗号の弱点
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つのメッセージの唯一の1つが署名されるだろうのと同じハッシュ値を持っている2つの異なったメッセージを作成する同じ人にかかわります。 攻撃は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.
メールの署名者と検証が一般に直接伝達しないので、署名に使用されるアルゴリズムの交渉は起こることができません。 言い換えれば、署名者には、検証がそうである検証がどのアルゴリズムをサポートするかを知っているか、(推進を郵送する支払われるべきもの)の道が全くありません。 この理由で、メッセージ署名がいったん広く配布されると、アルゴリズム変化がゆっくり起こって、レガシーアルゴリズムが、かなりの期間、サポートされる必要であると予想されます。 したがって、メッセージ署名に使用されるアルゴリズムは、数年間の予想された暗号の未来までの開発に対して安全である必要があります。
Fenton Informational [Page 20] RFC 4686 DKIM Threat Analysis September 2006
[20ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.1.15. Display Name Abuse
4.1.15. ディスプレイ名前乱用
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:
メッセージ署名はEメールアドレスのアドレス指定部分に関連するだけです、いくつかのMUAsが部分というアドレスのディスプレイ名を表示するだけですが(または、受取人が注意を向けるだけであるいくつか)。 攻撃者が以下などのFromヘッダーフィールドを使用するところでこの矛盾は攻撃につながります。
From: "Dudley DoRight" <whiplash@example.org>
From: 「ダドリーDoRight、「 <whiplash@example.org 、gt;、」
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から来ているとまだ何人かの受取人に確信できます。(おそらく、DoRightは信じられた個人です)。 使い捨てのドメインかEメールアドレスの使用と結合されています、別のもののディスプレイ名を使用するのについて責任があるように攻撃者を保つのは難しいかもしれません。
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で対処しなければならない攻撃です。 1つのアプローチは受取人にとって、署名者のアドレス指定(そして、ディスプレイ名であるだけではない)が目に見えるのが必要であることです。
4.1.16. Compromised System within Originator's Network
4.1.16. 創始者のネットワークの中の感染されたシステム
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.
多くの場合、MTAsは、創始者のネットワーク(すなわち、ファイアウォールの中の)の位相的な限界の中で起因するメッセージを受け入れて、署名するために構成されるかもしれません。 送る感染されたシステムの増加する使用はそのような方針のためにプレゼントに問題をメールします、プロキシとして感染されたシステムを使用して、攻撃者が署名しているメールを自由自在に作ることができるので。
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.
いくつかのアプローチが、この攻撃を緩和するために存在しています。 攻撃者が署名を得るかもしれないアドレスを制限するのにネットワーク限界の中でさえ認証された服従の使用を使用できます。 また、それは、よりはやくメッセージの源である感染されたシステムの場所を見つけるのを助けるかもしれません。 また、望ましくなくて悪意がある内容を特定する外国行きのメールの満足している分析、およびユーザによって送られるメッセージのボリュームのモニターは、任意のメッセージが署名されて、送られるのを防ぐかもしれません。
4.1.17. Verification Probe Attack
4.1.17. 検証徹底的調査攻撃
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ネームサーバ)を制御するかもしれないので、公開鍵ルックアップ、および彼らのソースを観察するのは、可能です、メッセージが確かめられるとき。
Fenton Informational [Page 21] RFC 4686 DKIM Threat Analysis September 2006
[21ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
「検証徹底的調査」のようなそのような攻撃の1つ(私たちは言及するつもりである)はDKIM署名と共にメーリングリストのそれぞれの多くのアドレスにメッセージを送ることです。 メッセージは有効な署名を含む必要はありません、そして、メッセージの各インスタンスは異なったセレクタを通常使用するでしょう。 攻撃者は、次に、主要なサービスのリクエストをモニターして、それの受け取り人がDKIM検証を使用したどのセレクタが対応するアクセスされたかと決心できました。 DKIM検証を使用しない受取人で将来の郵送を狙うのにこれを使用できました、そして、これらの受け取り人はメッセージ内容により影響しそうです。
4.1.18. Key Publication by Higher-Level Domain
4.1.18. よりハイレベルのドメインのそばでの主要な公表
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階層構造で有効なキーを発行するのは、可能です。 言い換えれば、anytown.ny.us、ny.us、または私たちによって発行されたキーを使用することでドメインexample.anytown.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.
ドメインの操作はいつもよりハイレベルのドメインとの信頼関係を必要とします。 よりハイレベルのドメインはそれらのサブドメインの上に既に最高権力を持ちます: 彼らは、ネームサーバ委譲をドメインに変えるか、またはそれを完全に権利を奪うかもしれません。 それで、よりハイレベルのドメインが故意にこの様にサブドメインに感染するのは、ありそうもないです。 しかしながら、よりハイレベルのドメインがそれら自身に代わってメールを送るなら、それらはそれら自身のレベルでキーを発行したがっているかもしれません。 よりハイレベルのドメインはそれらがそのようなキーの誤用でそれらのサブドメインのいずれも感染されないのを保証するために発行するキーの委譲で特別な注意を使わなければなりません。
Fenton Informational [Page 22] RFC 4686 DKIM Threat Analysis September 2006
[22ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
4.2. Attacks against Message Signing Practices
4.2. メッセージ署名習慣に対する攻撃
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 | | | +---------------------------------------------+--------+------------+
+---------------------------------------------+--------+------------+ | 攻撃名| 影響| 見込み| +---------------------------------------------+--------+------------+ | そっくりなものドメイン名| 高値| 高値| | 国際化ドメイン名乱用| 高値| 高値| | 署名に対するサービス不能攻撃| 媒体| 媒体| | 習慣| | | | 複数のFromアドレスの使用| 安値| 媒体| | 第三者署名の乱用| 媒体| 高値| | 送付者署名習慣の改竄| 媒体| 媒体| | 返信| | | +---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names
4.2.1. そっくりなものドメイン名
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として"punycode"に表されるなら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.
また、インターネット命名規則になじみがないユーザがそうするかもしれない、誤、認識、ある名前。 例えば、ユーザはオンラインexample.comにonline.example.comを間違えるかもしれません。その後者は攻撃者によって登録されたかもしれません。
4.2.2. Internationalized Domain Name Abuse
4.2.2. 国際化ドメイン名乱用
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].
国際化ドメイン名は上で説明された一様な外観ドメイン名攻撃の特別なケースを提示します。 多くのユニコード文字の外観における類似性、目視により他の、そして、ことによると高い値のドメインから区別がつかないドメイン(特に異なったグループからキャラクタを得るもの)が作成されますように。 ユニコードTechnical Report36[UTR36]で詳細にこれについて議論します。
Fenton Informational [Page 23] RFC 4686 DKIM Threat Analysis September 2006
[23ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
ドメインの取得記録の監視はこれらのいくつかを指摘するかもしれませんが、そのような多くの類似性があります。 また上では、このテクニックがそうするかもしれないそっくりなものドメイン攻撃のように、使用されて、他のドメインの送付者署名習慣を回避してください。
4.2.3. Denial-of-Service Attack against Signing Practices
4.2.3. 署名習慣に対するサービス不能攻撃
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.
ちょうど攻撃者がドメインのそばの公開鍵の公表に影響を与えることができるように、ドメインのそばのSender 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値は比較的大きい場合があります。
4.2.4. Use of Multiple From Addresses
4.2.4. アドレスからの倍数の使用
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.
この用法はほとんどの受取人によって決して見られませんが、RFC2822[RFC2822]は、Fromアドレスが複数のアドレス指定を含むのを可能にします。 Sender Signing PracticesのルックアップがFromアドレスに基づいているので、複数のドメインからのアドレスがFromアドレスにあるなら、どの署名が使用に練習されるかという質問は起こります。 規則(「最初のアドレスを使用してください」と言う)を指定できましたが、攻撃者は高値のドメインのものの前に使い捨てのアドレスを置くことができました。 また、SSPがすべてのアドレスを見て、最も制限している規則を選ぶのも、可能です。 これはさらなる研究を必要とした領域です。
4.2.5. Abuse of Third-Party Signatures
4.2.5. 第三者署名の乱用
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署名は起因しているアドレスドメインから来ないかもしれません。 この理由で、「第三者」署名(メーリングリスト、招待サービス、または通信社で付けられたもの)は、頻繁に何らかの正当性を持っていると見なされる必要があります。 これでどんなドメインもどんなメッセージ、送付にも署名するのが事実上可能になるので
Fenton Informational [Page 24] RFC 4686 DKIM Threat Analysis September 2006
[24ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
しかしながら、有効に習慣に署名しながら「第三者がありません」を発行するのによるドメインに関して課される制限はメールの多くの既存の用途を禁じます。 これらの習慣を採用できないドメインの大部分に、いくらかの成功サインメッセージが、ドメインから来ることを意味している状態で、攻撃者はそうするかもしれません。 この理由で、認可、評判サービス、局所的に維持されたwhitelists、およびブラックリストは、第三者によって署名されたメッセージを評価することにおける重要な役割をプレーする必要があるでしょう。
4.2.6. Falsification of Sender Signing Practices Replies
4.2.6. 習慣が回答であると署名する送付者の改竄
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で説明された主要なサービス回答の改竄への類似の方法で、習慣が質問であると署名する送付者への回答を改竄できます。 そのような攻撃の1つは申し立てによると与えられたドメインからの未署名のメッセージをより疑わしげでなく見えさせるように署名習慣を弱めるだろうことです。 メッセージに署名していない犠牲者ドメインに対する別の攻撃は、ドメインのメッセージが、より疑わしげに見えさせるのを試みるかもしれません、メールを送る犠牲者の能力を妨げるために。
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がないときでさえ、キャッシュ中毒による脆弱性はローカライズされます。
4.3. Other Attacks
4.3. 他の攻撃
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 |
+--------------------------------------+--------+------------+
+--------------------------------------+--------+------------+ | 攻撃名| 影響| 見込み| +--------------------------------------+--------+------------+ | DNSを通したパケット増幅攻撃| なし| 媒体| +--------------------------------------+--------+------------+
4.3.1. Packet Amplification Attacks via DNS
4.3.1. DNSを通したパケットAmplification Attacks
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.
最近、オープンにアクセスしやすいドメイン名サーバ[米国-CERT-DNS]に偽造しているUDP DNS要求の伝達にかかわるサービス不能攻撃の増加がありました。 ネームサーバからの応答が要求より大きいという範囲に、ネームサーバはそのような攻撃のためのアンプとして機能します。
Fenton Informational [Page 25] RFC 4686 DKIM Threat Analysis September 2006
[25ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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ベースの解決がおそらく必要でしょう。
5. Derived Requirements
5. 派生している要件
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.
キーが記録するので、生きるキャッシュ時間は1記録あたり1個のベースで明記できるに違いありません。
The signature algorithm identifier in the message must be one of
the ones listed in a key record for the identified domain.
メッセージの署名アルゴリズム識別子は特定されたドメインのための主要な記録に記載されたものの1つであるに違いありません。
The algorithm(s) used for message signatures need to be secure
against expected cryptographic developments several years in the
future.
メッセージ署名に使用されるアルゴリズムは、将来数年間の予想された暗号の開発に対して安全である必要があります。
6. Security Considerations
6. セキュリティ問題
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メール(DKIM)が何らかの利益を提供すると予想される軍事的脅威環境について説明します、そして、それは展開に関連している多くの攻撃を提示します。
Fenton Informational [Page 26] RFC 4686 DKIM Threat Analysis September 2006
[26ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
7. Informative References
7. 有益な参照
[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、「リモートTiming AttacksはPracticalである」Proc。 第12USENIXセキュリティシンポジウム、2003。
[DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", Work in Progress, August 2006.
[DKIM-ベース] オールマン、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]コッハー、104-113ページ、1996Cryptology、年のP.、「ディフィー-ヘルマンのImplementations、RSA、および他のCryptosystemsの上のタイミングAttacks」Advances。
[Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power
Analysis: Leaking Secrets", Crypto '99, pages 388-397,
1999.
[Kocher99] コッハー、P.、ジョフィ、J.、およびB.ユン、「デフ装置は分析を動かします」。 「シークレットを漏らします」、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インチ、STD53、RFC1939、1996年5月。」
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat
Posed by DNS Recursion".
[米国の本命DNS] 米国の本命であり、「継続するサービス妨害の脅威はDNS再帰によって引き起こしました」。
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report
#36: Unicode Security Considerations", UTR 36,
July 2005.
[UTR36] デイヴィス、M.、およびM.Suignard、「ユニコード技術報告書#36:」 「ユニコードセキュリティ問題」、UTR36、2005年7月。
Fenton Informational [Page 27] RFC 4686 DKIM Threat Analysis September 2006
[27ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
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.
作者はこのドキュメントの以前のバージョンの貴重な提案と建設的批判のためのietf-dkimメーリングリストでフィリップ・ハラム-ベイカー、エリオットリア、トニーFinch、デーヴ・クロッカー、バリーLeiba、Arvel Hathcock、エリック・オールマン、ジョン・カラス、スティーブン・ファレル、ダグオーティス、フランクEllermann、エリック・レスコラ、ポール・ホフマン、ヘクトル・サントス、および多数の他のものに感謝したがっています。
Author's Address
作者のアドレス
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
ジムフェントンシスコシステムズInc.MS SJ-9/2 170W.タスマン・Driveカリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 526 5914 EMail: fenton@cisco.com
以下に電話をしてください。 +1 5914年の408 526メール: fenton@cisco.com
Fenton Informational [Page 28] RFC 4686 DKIM Threat Analysis September 2006
[28ページ]RFC4686DKIM脅威分析2006年9月の情報のフェントン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Fenton Informational [Page 29]
フェントンInformationalです。[29ページ]
一覧
スポンサーリンク
