[要約] 要約：RFC 4686は、DomainKeys Identified Mail（DKIM）を動機付ける脅威の分析を提供しています。 目的：DKIMの導入によるセキュリティ上の利点と、DKIMの脆弱性に関する理解を促進することを目的としています。
Network Working Group J. Fenton
Request for Comments: 4686 Cisco Systems, Inc.
Category: Informational September 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
ドメインキーを動機付けている脅威の分析識別されたメール（DKIM）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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が識別されたメールによって対処されることを目的としたインターネットメールに対するいくつかの脅威の分析を提供します。それは、悪い俳優の性質と場所、彼らの能力が何であるか、そして彼らが彼らの攻撃によって達成するつもりであることについて議論します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology and Model ......................................3
1.2. Document Structure .........................................5
2. The Bad Actors ..................................................6
2.1. Characteristics ............................................6
2.2. Capabilities ...............................................6
2.3. Location ...................................................8
2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing .....................................12
4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records
and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack against Signing
Practices ..........................................24
4.2.4. Use of Multiple From Addresses .....................24
4.2.5. Abuse of Third-Party Signatures ....................24
4.2.6. Falsification of Sender Signing Practices Replies ..25
4.3. Other Attacks .............................................25
4.3.1. Packet Amplification Attacks via DNS ...............25
5. Derived Requirements ...........................................26
6. Security Considerations ........................................26
7. Informative References .........................................27
Appendix A. Acknowledgements ......................................28
The DomainKeys Identified Mail (DKIM) protocol is being specified by the IETF DKIM Working Group. The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. This document addresses threats relative to two works in progress by the DKIM Working Group, the DKIM signature specification [DKIM-BASE] and DKIM Sender Signing Practices [DKIM-SSP].
domainkeys識別されたメール（DKIM）プロトコルは、IETF DKIMワーキンググループによって指定されています。DKIMプロトコルは、電子メールメッセージを暗号化できるメカニズムを定義し、署名ドメインが特定のメールアドレスの使用に関する責任を請求することを許可します。メッセージ受信者は、署名者のドメインを直接クエリして適切な公開キーを取得することにより、署名を検証し、それにより、署名ドメインの秘密鍵を所有する当事者によってメッセージが証明されたことを確認できます。このドキュメントは、DKIMワーキンググループによる進行中の2つの作業、DKIM署名仕様[DKIM-Base]および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.
証明党または当事者が確立されると、受信者は、地元で維持されたホワイトリスト、共有評判サービス、および/またはサードパーティの認定などの追加情報のコンテキストでメッセージを評価することができます。これらのメカニズムの説明は、IETF DKIMワーキンググループの努力の範囲外です。署名を適用することにより、優れたプレーヤーは、受信者から優先的な扱いを受けることを期待して、検証者が肯定的な評判をメッセージに関連付けることができます。
This effort is not intended to address threats associated with message confidentiality nor does it intend to provide a long-term archival signature.
この取り組みは、メッセージの機密性に関連する脅威に対処することを意図したものでも、長期的なアーカイブの署名を提供することを意図していません。
An administrative unit (AU) is the portion of the path of an email message that is under common administration. The originator and recipient typically develop trust relationships with the administrative units that send and receive their email, respectively, to perform the signing and verification of their messages.
管理ユニット（AU）は、一般的な管理下にある電子メールメッセージのパスの一部です。発信者と受信者は通常、メッセージの署名と検証を実行するために、それぞれ電子メールを送信および受信する管理ユニットとの信頼関係を築きます。
The origin address is the address on an email message, typically the RFC 2822 From: address, which is associated with the alleged author of the message and is displayed by the recipient's Mail User Agent (MUA) as the source of the message.
Origin Addressは、電子メールメッセージのアドレス、通常はRFC 2822からです。アドレスは、メッセージの著者に関連付けられ、受信者のメールユーザーエージェント（MUA）によってメッセージのソースとして表示されます。
The following diagram illustrates a typical usage flowchart for DKIM:
次の図は、DKIMの典型的な使用フローチャートを示しています。
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
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は、RFC 2822 [RFC2822]で定義されているように、メッセージのコンテンツ（ボディおよび選択されたヘッダーフィールド）で完全に動作します。RFC 2821 [RFC2821]で定義されているSMTPを介したメッセージの送信、およびエンベロープからの要素やエンベロープツーアドレスおよびHELOドメインは、DKIM検証には関係ありません。これは、検証剤として機能するMUAが使用する可能性のあるMUAが使用するPOP [RFC1939]やIMAP [RFC3501]など、SMTP以外のプロトコルを介してメッセージの検証を許可するための意図的な決定です。
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.
上記の図で言及されている送信者署名プラクティスクエリは、Verifierが疑いのある著者のドメインを照会して、メッセージの評価に影響を与える可能性のあるメッセージに署名する慣行を決定できる手段です。たとえば、有効な署名なしでメッセージが届き、疑わしい著者のドメインがすべてのメッセージに署名することを宣伝する場合、検証者は署名が必ずしも予想されない場合とは異なる方法でそのメッセージを処理する可能性があります。
The remainder of this document describes the problems that DKIM might be expected to address, and the extent to which it may be successful in so doing. These are described in terms of the potential bad actors, their capabilities and location in the network, and the bad acts that they might wish to commit.
このドキュメントの残りの部分は、DKIMが対処することが期待される可能性のある問題と、そうすることで成功する可能性がある範囲について説明しています。これらは、潜在的な悪い俳優、ネットワーク内の能力と場所、および彼らがコミットしたいと思うかもしれない悪い行為の観点から説明されています。
This is followed by a description of postulated attacks on DKIM message signing and on the use of Sender Signing Practices to assist in the treatment of unsigned messages. A list of derived requirements is also presented, which is intended to guide the DKIM design and review process.
これに続いて、DKIMメッセージの署名に関する仮定攻撃の説明と、署名されていないメッセージの扱いを支援するための送信者署名プラクティスの使用に関する説明が続きます。派生要件のリストも提示されています。これは、DKIMの設計とレビュープロセスをガイドすることを目的としています。
The sections dealing with attacks on DKIM each begin with a table summarizing the postulated attacks in each category along with their expected impact and likelihood. The following definitions were used as rough criteria for scoring the attacks:
DKIMへの攻撃を扱うセクションは、それぞれ、各カテゴリの仮定された攻撃を要約するテーブルから始まり、予想される影響と可能性があります。次の定義は、攻撃を採点するための大まかな基準として使用されました。
Impact:
影響：
High: Affects the verification of messages from an entire domain or multiple domains
高：ドメイン全体または複数のドメインからのメッセージの検証に影響します
Medium: Affects the verification of messages from specific users, Mail Transfer Agents (MTAs), and/or bounded time periods
媒体：特定のユーザー、メール転送エージェント（MTA）、および/または境界期間からのメッセージの検証に影響します
Low: Affects the verification of isolated individual messages only
低：分離された個々のメッセージのみの検証に影響する
Likelihood:
可能性：
High: All email users should expect this attack on a frequent basis
高：すべての電子メールユーザーは、この攻撃を頻繁に期待する必要があります
Medium: Email users should expect this attack occasionally; frequently for a few users
中：電子メールユーザーは、この攻撃を時々期待する必要があります。多くの場合、少数のユーザーの場合
Low: Attack is expected to be rare and/or very infrequent
低：攻撃はまれであり、非常にまれであると予想されます
The problem space being addressed by DKIM is characterized by a wide range of attackers in terms of motivation, sophistication, and capabilities.
DKIMによって対処されている問題スペースは、動機、洗練、能力の観点から幅広い攻撃者によって特徴付けられます。
At the low end of the spectrum are bad actors who may simply send email, perhaps using one of many commercially available tools, that the recipient does not want to receive. These tools typically allow one to falsify the origin address of messages, and may, in the future, be capable of generating message signatures as well.
スペクトルの低端には、おそらく受信者が受け取ったくない多くの市販のツールのいずれかを使用して、おそらく電子メールを送信する可能性のある悪い俳優です。これらのツールは通常、メッセージの原点アドレスを偽造することができ、将来的にはメッセージ署名を生成できる場合もあります。
At the next tier are what would be considered "professional" senders of unwanted email. These attackers would deploy specific infrastructure, including Mail Transfer Agents (MTAs), registered domains and networks of compromised computers ("zombies") to send messages, and in some cases to harvest addresses to which to send. These senders often operate as commercial enterprises and send messages on behalf of third parties.
次の層には、不要な電子メールの「プロフェッショナル」送信者と見なされるものがあります。これらの攻撃者は、メール転送エージェント（MTA）、登録ドメイン、侵害されたコンピューター（「ゾンビ」）のネットワークを含む特定のインフラストラクチャを展開し、メッセージを送信し、場合によっては送信する住所を収穫します。これらの送信者は、多くの場合、商業企業として運営され、第三者に代わってメッセージを送信します。
The most sophisticated and financially-motivated senders of messages are those who stand to receive substantial financial benefit, such as from an email-based fraud scheme. These attackers can be expected to employ all of the above mechanisms and additionally may attack the Internet infrastructure itself, including DNS cache-poisoning attacks and IP routing attacks.
メッセージの最も洗練された経済的に動機付けられた送信者は、電子メールベースの詐欺スキームなど、実質的な財政的利益を受け取ることを支持する人です。これらの攻撃者は、上記のすべてのメカニズムを採用することが期待でき、さらに、DNSキャッシュポジョン攻撃やIPルーティング攻撃など、インターネットインフラストラクチャ自体を攻撃する場合があります。
In general, the bad actors described above should be expected to have access to the following:
一般に、上記の悪い俳優は、以下にアクセスできることが期待されるべきです。
1. An extensive corpus of messages from domains they might wish to impersonate
1. 彼らがなりすましたいと思うかもしれないドメインからのメッセージの広範なコーパス
2. Knowledge of the business aims and model for domains they might wish to impersonate
2. ビジネスの目的とモデルの知識は、彼らがなりすましたいと思うかもしれないドメインのモデル
3. Access to public keys and associated authorization records associated with the domain
3. パブリックキーへのアクセスおよびドメインに関連する関連認証レコード
and the ability to do at least some of the following:
そして、少なくとも次のことをする能力：
1. Submit messages to MTAs and Message Submission Agents (MSAs) at multiple locations in the Internet
1. インターネット内の複数の場所でMTASおよびメッセージ提出エージェント（MSA）にメッセージを送信する
2. Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents
2. メーリングリスト、担当者、その他の郵便エージェントであると主張するものを含む、任意のメッセージヘッダーフィールドを構築する
3. Sign messages on behalf of domains under their control
3. ドメインに代わってメッセージに署名します
4. Generate substantial numbers of either unsigned or apparently-signed messages that might be used to attempt a denial-of-service attack
4. サービス拒否攻撃を試みるために使用される可能性のあるかなりの数の署名されていないまたは明らかに署名されたメッセージを生成する
5. Resend messages that may have been previously signed by the domain
5. 以前にドメインによって署名された可能性のあるメッセージを再送信します
6. Transmit messages using any envelope information desired
6. 必要なエンベロープ情報を使用してメッセージを送信します
7. Act as an authorized submitter for messages from a compromised computer
7. 侵害されたコンピューターからのメッセージの承認された提出者として行動する
As noted above, certain classes of bad actors may have substantial financial motivation for their activities, and therefore should be expected to have more capabilities at their disposal. These include:
上記のように、特定のクラスの悪い俳優は、彼らの活動に対して実質的な経済的動機を持っている可能性があるため、より多くの能力が自由に使えると予想されるはずです。これらには以下が含まれます：
1. Manipulation of IP routing. This could be used to submit messages from specific IP addresses or difficult-to-trace addresses, or to cause diversion of messages to a specific domain.
1. IPルーティングの操作。これを使用して、特定のIPアドレスまたはトレースが困難なアドレスからメッセージを送信したり、特定のドメインにメッセージを転換することもできます。
2. Limited influence over portions of DNS using mechanisms such as cache poisoning. This might be used to influence message routing or to falsify advertisements of DNS-based keys or signing practices.
2. キャッシュ中毒などのメカニズムを使用したDNSの一部に対する限定的な影響。これは、メッセージのルーティングに影響を与えたり、DNSベースのキーの広告や署名プラクティスを偽造したりするために使用される場合があります。
3. Access to significant computing resources, for example, through the conscription of worm-infected "zombie" computers. This could allow the bad actor to perform various types of brute-force attacks.
3. たとえば、ワームに感染した「ゾンビ」コンピューターの徴兵を介した重要なコンピューティングリソースへのアクセス。これにより、悪い俳優がさまざまな種類のブルートフォース攻撃を実行できるようになります。
4. Ability to eavesdrop on existing traffic, perhaps from a wireless network.
4. おそらくワイヤレスネットワークから、既存のトラフィックを盗聴する能力。
Either of the first two of these mechanisms could be used to allow the bad actor to function as a man-in-the-middle between author and recipient, if that attack is useful.
これらのメカニズムの最初の2つのいずれかを使用して、その攻撃が有用な場合、悪い俳優が著者と受信者の間の中間の男として機能することを可能にすることができます。
Bad actors or their proxies can be located anywhere in the Internet. Certain attacks are possible primarily within the administrative unit of the claimed originator and/or recipient domain have capabilities beyond those elsewhere, as described in the below sections. Bad actors can also collude by acting from multiple locations (a "distributed bad actor").
悪い俳優またはそのプロキシは、インターネットのどこにでも配置できます。以下のセクションで説明されているように、特定の攻撃は、主に主張されたオリジネーターおよび/またはレシピエントドメインの管理単位内で可能です。悪い俳優は、複数の場所から行動することで共謀することもできます（「分散型の悪い俳優」）。
It should also be noted that with the use of "zombies" and other proxies, externally-located bad actors may gain some of the capabilities of being located within the claimed originator's or recipient's administrative unit. This emphasizes the importance of appropriate security measures, such as authenticated submission of messages, even within administrative units.
また、「ゾンビ」やその他のプロキシを使用すると、外部に配置された悪い俳優が、主張された創始者または受信者の管理ユニット内にある能力の一部を獲得する可能性があることに注意する必要があります。これは、管理ユニット内であっても、メッセージの認証された提出など、適切なセキュリティ対策の重要性を強調しています。
DKIM focuses primarily on bad actors located outside of the administrative units of the claimed originator and the recipient. These administrative units frequently correspond to the protected portions of the network adjacent to the originator and recipient. It is in this area that the trust relationships required for authenticated message submission do not exist and do not scale adequately to be practical. Conversely, within these administrative units, there are other mechanisms such as authenticated message submission that are easier to deploy and more likely to be used than DKIM.
DKIMは、主に主張された発信者と受信者の管理単位の外にある悪い俳優に焦点を当てています。これらの管理ユニットは、発信者と受信者に隣接するネットワークの保護された部分にしばしば対応します。この分野では、認証されたメッセージの提出に必要な信頼関係が存在せず、実用的であるために適切に拡大しません。逆に、これらの管理ユニット内には、展開が容易であり、DKIMよりも使用される可能性が高い認証されたメッセージ送信など、他のメカニズムがあります。
External bad actors are usually attempting to exploit the "any to any" nature of email that motivates most recipient MTAs to accept messages from anywhere for delivery to their local domain. They may generate messages without signatures, with incorrect signatures, or with correct signatures from domains with little traceability. They may also pose as mailing lists, greeting cards, or other agents that legitimately send or resend messages on behalf of others.
外部の悪い俳優は通常、ほとんどの受信者MTAがローカルドメインへの配信のためにどこからでもメッセージを受け入れるように動機付ける電子メールの「あらゆる」性質を悪用しようとしています。署名なし、誤った署名、またはトレーサビリティがほとんどないドメインからの正しい署名を使用してメッセージを生成する場合があります。また、メーリングリスト、グリーティングカード、または他の人に代わってメッセージを合法的に送信または再送信する他のエージェントとしてポーズをとることもできます。
Bad actors in the form of rogue or unauthorized users or malware-infected computers can exist within the administrative unit corresponding to a message's origin address. Since the submission of messages in this area generally occurs prior to the application of a message signature, DKIM is not directly effective against these bad actors. Defense against these bad actors is dependent upon other means, such as proper use of firewalls, and Message Submission Agents that are configured to authenticate the author.
不正なユーザーまたは不正ユーザーまたはマルウェアに感染したコンピューターの形の悪い俳優は、メッセージの起源アドレスに対応する管理ユニット内に存在する可能性があります。この領域でのメッセージの提出は一般に、メッセージ署名を適用する前に発生するため、DKIMはこれらの悪い俳優に対して直接効果的ではありません。これらの悪い俳優に対する防御は、ファイアウォールの適切な使用や、著者を認証するように構成されたメッセージ提出エージェントなど、他の手段に依存しています。
In the special case where the administrative unit is non-contiguous (e.g., a company that communicates between branches over the external Internet), DKIM signatures can be used to distinguish between legitimate externally-originated messages and attempts to spoof addresses in the local domain.
管理ユニットが不連続である特別な場合（たとえば、外部インターネット上のブランチ間で通信する会社）、DKIM署名を使用して、正当な外部に由来するメッセージとローカルドメインのアドレスをスプーフィングする試みを区別できます。
Bad actors may also exist within the administrative unit of the message recipient. These bad actors may attempt to exploit the trust relationships that exist within the unit. Since messages will typically only have undergone DKIM verification at the administrative unit boundary, DKIM is not effective against messages submitted in this area.
悪い俳優は、メッセージ受信者の管理単位内にも存在する場合があります。これらの悪い俳優は、ユニット内に存在する信頼関係を悪用しようとするかもしれません。メッセージは通常、管理ユニットの境界でDKIM検証のみを受けているため、DKIMはこの領域で提出されたメッセージに対して効果的ではありません。
For example, the bad actor may attempt to spoof a header field indicating the results of verification. This header field would normally be added by the verifier, which would also detect spoofed header fields on messages it was attempting to verify. This could be used to falsely indicate that the message was authenticated successfully.
たとえば、悪い俳優は、検証の結果を示すヘッダーフィールドをスプーフィングしようとする場合があります。このヘッダーフィールドは通常、検証剤によって追加され、検証を試みていたメッセージでスプーフィングされたヘッダーフィールドも検出されます。これは、メッセージが正常に認証されたことを誤って示すために使用できます。
As in the originator case, these bad actors can be dealt with by controlling the submission of messages within the administrative unit. Since DKIM permits verification to occur anywhere within the recipient's administrative unit, these threats can also be minimized by moving verification closer to the recipient, such as at the Mail Delivery Agent (MDA), or on the recipient's MUA itself.
発信者の場合と同様に、これらの悪い俳優は、管理ユニット内のメッセージの提出を制御することで対処できます。DKIMは、受信者の管理ユニット内のどこでも検証を行うことを許可しているため、これらの脅威は、メール配送エージェント（MDA）などの受信者に近づくか、受信者のMUA自体などの検証を移動することで最小限に抑えることもできます。
One of the most fundamental bad acts being attempted is the delivery of messages that are not intended to have been sent by the alleged originating domain. As described above, these messages might merely be unwanted by the recipient, or might be part of a confidence scheme or a delivery vector for malware.
試みられている最も根本的な悪い行為の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).
このクラスの悪い行為には、実際の著者の身元を曖昧にすることを目的とするメッセージの送信が含まれます。場合によっては、実際の送信者が悪い俳優である可能性があります。または、他のケースでは、悪い俳優の管理下にあるサードパーティ（たとえば、妥協したコンピューター）である場合があります。
Particularly when coupled with sender signing practices that indicate the domain owner signs all messages, DKIM can be effective in mitigating against the abuse of addresses not controlled by bad actors. DKIM is not effective against the use of addresses controlled by bad actors. In other words, the presence of a valid DKIM signature does not guarantee that the signer is not a bad actor. It also does not guarantee the accountability of the signer, since DKIM does not attempt to identify the signer individually, but rather identifies the domain that they control. Accreditation and reputation systems and locally-maintained whitelists and blacklists can be used to enhance the accountability of DKIM-verified addresses and/or the likelihood that signed messages are desirable.
特に、ドメインの所有者がすべてのメッセージに署名することを示す送信者署名プラクティスと相まって、DKIMは、悪い俳優によって制御されていない住所の乱用に対して緩和するのに効果的です。DKIMは、悪い俳優によって制御されたアドレスの使用に対して効果的ではありません。言い換えれば、有効なDKIM署名の存在は、署名者が悪い俳優ではないことを保証するものではありません。また、DKIMは署名者を個別に特定しようとせず、むしろ制御するドメインを特定しようとするため、署名者の説明責任を保証するものではありません。認定と評判システム、および地元で維持されたホワイトリストとブラックリストを使用して、DKIM検証アドレスの説明責任や、署名されたメッセージが望ましい可能性を高めることができます。
A second major class of bad acts involves the assertion of specific identities in email.
悪い行為の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からのメッセージに署名することができます。これらのドメインが悪い俳優によって制御される限り、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は、そのようなメッセージが実際に署名されるという期待がある場合にのみ、特定のアイデンティティの使用に対して効果的です。これを確立するための主な手段は、IETF DKIMワーキンググループによって指定される送信者署名プラクティス（SSP）の使用です。
One reason for asserting a specific origin address is to encourage a recipient to read and act on particular email messages by appearing to be an acquaintance or previous correspondent that the recipient might trust. This tactic has been used by email-propagated malware that mail themselves to addresses in the infected host's address book. In this case, however, the author's address may not be falsified, so DKIM would not be effective in defending against this act.
特定の起源の住所を主張する理由の1つは、受信者が信頼できる知人または以前の特派員のように見えることにより、受信者が特定の電子メールメッセージを読んで行動することを奨励することです。この戦術は、感染した宿主のアドレス帳のアドレスに自分自身を郵送する電子メールプロパゲッドマルウェアによって使用されています。ただし、この場合、著者の住所は偽造されない可能性があるため、DKIMはこの法律に対する擁護に効果的ではありません。
It is also possible for address books to be harvested and used by an attacker to post messages from elsewhere. DKIM could be effective in mitigating these acts by limiting the scope of origin addresses for which a valid signature can be obtained when sending the messages from other locations.
また、攻撃者が他の場所からメッセージを投稿するためにアドレス帳を収穫し、使用することも可能です。DKIMは、他の場所からメッセージを送信するときに有効な署名を取得できる原点アドレスの範囲を制限することにより、これらの行為を緩和するのに効果的です。
Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author.
電子メールベースの詐欺に関連する悪い行為は、常にではありませんが、詐欺スキームの一部として他のエンティティの特定の起源アドレスを使用してメッセージの送信を伴います。特定の起源のアドレスを使用することは、メッセージが実際に著者によって送信されたことを受信者に納得させるのを助けることにより、詐欺の成功に貢献することがあります。
To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use.
詐欺の成功が特定の起源アドレスの使用によって依存するか、または強化される限り、悪い俳優は、特定の住所を不正使用から保護するために取られた措置を回避するための重要な財政的動機とリソースを持っている可能性があります。
When signatures are verified by or for the recipient, DKIM is effective in defending against the fraudulent use of origin addresses on signed messages. When the published sender signing practices of the origin address indicate that all messages from that address should be signed, DKIM further mitigates against the attempted fraudulent use of the origin address on unsigned messages.
署名が受信者によってまたは受信者のために検証されている場合、DKIMは、署名されたメッセージでの原点アドレスの不正な使用に対して防御するのに効果的です。公開されている送信者のOriginアドレスの署名慣行が、そのアドレスからのすべてのメッセージに署名する必要があることを示している場合、DKIMは、署名されていないメッセージでのOriginアドレスの不正使用の試みに対してさらに軽減します。
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.
メッセージに特定の原点アドレスを使用するもう1つの動機は、一般に「ジョージョブ」と呼ばれる別の人の評判を傷つけることです。たとえば、商業エンティティは、おそらくその競合他社に代わって未承諾のバルクメールを送信することにより、競合他社の評判に害を及ぼすことを望むかもしれません。このため、評判システムは、実際にはかなり信頼できるアイデンティティに基づいている必要があります。
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 Envelope-fromアドレス）に送信することにより、メッセージの間接的な送信です。この場合、電子メールで主張されている特定の身元は、メッセージの実際のターゲットのものであり、メッセージが「返されます」。
DKIM does not, in general, attempt to validate the RFC2821.mailfrom return address on messages, either directly (noting that the mailfrom address is an element of the SMTP protocol, and not the message content on which DKIM operates), or via the optional Return-Path header field. Furthermore, as is noted in Section 4.4 of RFC 2821 [RFC2821], it is common and useful practice for a message's return path not to correspond to the origin address. For these reasons, DKIM is not effective against reflection attacks.
DKIMは、一般に、メッセージのRFC2821.Mailfromの返信アドレスを直接検証しようとしません（MailfromアドレスはSMTPプロトコルの要素であり、DKIMが動作するメッセージコンテンツではないことに注意してください）、またはオプションを介してリターンパスヘッダーフィールド。さらに、RFC 2821 [RFC2821]のセクション4.4に記載されているように、メッセージのリターンパスが原点アドレスに対応しないことは一般的で有用な慣行です。これらの理由から、DKIMは反射攻撃に対して効果的ではありません。
Bad actors can be expected to exploit all of the limitations of message authentication systems. They are also likely to be motivated to degrade the usefulness of message authentication systems in order to hinder their deployment. Both the signature mechanism itself and declarations made regarding use of message signatures (referred to here as Sender Signing Practices or SSP) can be expected to be the target of attacks.
悪いアクターは、メッセージ認証システムのすべての制限を活用することが期待できます。また、展開を妨げるために、メッセージ認証システムの有用性を分解するように動機付けられる可能性があります。署名メカニズム自体と、メッセージ署名の使用に関して行われた宣言（ここでは、送信者署名プラクティスまたはSSPと呼ばれる）は、攻撃のターゲットになると予想されます。
The following is a summary of postulated attacks against DKIM signatures:
以下は、DKIMの署名に対する仮定攻撃の要約です。
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel attack| High | Low |
| Chosen message replay | Low | M/H |
| Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key service| High | Medium |
| Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low |
| Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low |
| signatures | | |
| Cryptographic weaknesses in signature | High | Low |
| generation | | |
| Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium |
| network | | |
| Verification probe attack | Medium | Medium |
| Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+
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などのメッセージ署名テクノロジーは、メッセージに署名するために使用されるプライベートキーの盗難に対して脆弱です。これには、強盗、贈収賄、恐torなどのこの盗難の「帯域外」手段、およびプライベートの場所の周りのネットワークやホストセキュリティの妥協など、そのような盗難の電子手段が含まれます。キーが保存されます。
Keys that are valid for all addresses in a domain typically reside in MTAs that should be located in well-protected sites, such as data centers. Various means should be employed for minimizing access to private keys, such as non-existence of commands for displaying their value, although ultimately memory dumps and the like will probably contain the keys. Due to the unattended nature of MTAs, some countermeasures, such as the use of a pass phrase to "unlock" a key, are not practical to use. Other mechanisms, such as the use of dedicated hardware devices that contain the private key and perform the cryptographic signature operation, would be very effective in denying export of the private key to those without physical access to the device. Such devices would almost certainly make the theft of the key visible, so that appropriate action (revocation of the corresponding public key) can be taken should that happen.
ドメイン内のすべてのアドレスに有効なキーは、通常、データセンターなどのよく保護されたサイトに配置する必要があるMTAに存在します。最終的にはメモリダンプなどには、おそらくキーが含まれますが、その価値を表示するためのコマンドの存在など、プライベートキーへのアクセスを最小限に抑えるためには、さまざまな手段を採用する必要があります。MTAの無人の性質のため、キーのロックを「解除」するためのパスフレーズを使用するなど、いくつかの対策は使用するのが実用的ではありません。秘密キーを含み、暗号化署名操作を実行する専用のハードウェアデバイスの使用など、他のメカニズムは、デバイスに物理的にアクセスできない人への秘密鍵のエクスポートを拒否するのに非常に効果的です。そのようなデバイスは、ほぼ確実にキーの盗難を目に見えるようにするため、適切なアクション（対応する公開鍵の取り消し）を実行できれば、それが起こった場合に実行できます。
There are several circumstances where a domain owner will want to delegate the ability to sign messages for the domain to an individual user or a third party associated with an outsourced activity such as a corporate benefits administrator or a marketing campaign. Since these keys may exist on less well-protected devices than the domain's own MTAs, they will in many cases be more susceptible to compromise.
ドメインの所有者が、ドメインのメッセージを個々のユーザーまたは企業福利厚生管理者やマーケティングキャンペーンなどの外部委託されたアクティビティに関連する第三者に署名する機能を委任する場合があります。これらのキーは、ドメイン独自のMTAよりも十分に保護されていないデバイスに存在する可能性があるため、多くの場合、妥協の影響を受けやすくなります。
In order to mitigate this exposure, keys used to sign such messages can be restricted by the domain owner to be valid for signing messages only on behalf of specific addresses in the domain. This maintains protection for the majority of addresses in the domain.
この露出を緩和するために、そのようなメッセージに署名するために使用されるキーは、ドメインの特定のアドレスに代わってメッセージに署名するために有効であるようにドメイン所有者によって制限される可能性があります。これにより、ドメイン内のアドレスの大部分の保護が維持されます。
A related threat is the exploitation of weaknesses in the delegation process itself. This threat can be mitigated through the use of customary precautions against the theft of private keys and the falsification of public keys in transit. For example, the exposure to theft can be minimized if the delegate generates the keypair to be used, and sends the public key to the domain owner. The exposure to falsification (substitution of a different public key) can be reduced if this transmission is signed by the delegate and verified by the domain owner.
関連する脅威は、委任プロセス自体の弱点の搾取です。この脅威は、プライベートキーの盗難に対する慣習的な予防措置と輸送中の公共鍵の改ざんを通じて緩和することができます。たとえば、デリゲートが使用するキーペイアを生成し、公開鍵をドメイン所有者に送信すると、盗難への露出を最小限に抑えることができます。この伝送が代表者によって署名され、ドメイン所有者によって検証された場合、改ざんへの露出（異なる公開鍵の代替）は減少させることができます。
All popular digital signature algorithms are subject to a variety of side channel attacks. The most well-known of these are timing channels [Kocher96], power analysis [Kocher99], and cache timing analysis [Bernstein04]. Most of these attacks require either physical access to the machine or the ability to run processes directly on the target machine. Defending against these attacks is out of scope for DKIM.
すべての一般的なデジタル署名アルゴリズムは、さまざまなサイドチャネル攻撃の対象となります。これらの中で最もよく知られているのは、タイミングチャネル[kocher96]、パワー分析[kocher99]、およびキャッシュタイミング分析[bernstein04]です。これらの攻撃のほとんどは、マシンへの物理的なアクセスまたはターゲットマシンでプロセスを直接実行する機能を必要とします。これらの攻撃に対する防御は、DKIMにとって範囲外です。
However, remote timing analysis (at least on local area networks) is known to be feasible [Boneh03], particularly in server-type platforms where the attacker can inject traffic that will immediately be subject to the cryptographic operation in question. With enough samples, these techniques can be used to extract private keys even in the face of modest amounts of noise in the timing measurements.
ただし、リモートタイミング分析（少なくともローカルエリアネットワークでは）は、特に攻撃者が問題の暗号化操作の対象となるトラフィックを挿入できるサーバー型プラットフォームで、実行可能であることが知られています[Boneh03]。十分なサンプルを使用すると、これらの手法を使用して、タイミング測定におけるわずかな量のノイズに直面してもプライベートキーを抽出できます。
The three commonly proposed countermeasures against timing analysis are:
タイミング分析に対する一般的に提案されている3つの対策は、次のとおりです。
1. Make the operation run in constant time. This turns out in practice to be rather difficult.
1. 一定の時間で操作を実行します。これは実際にはかなり難しいことがわかります。
2. Make the time independent of the input data. This can be difficult, but see [Boneh03] for more details.
2. 入力データから独立した時間を作成します。これは難しい場合がありますが、詳細については[Boneh03]を参照してください。
3. Use blinding. This is generally considered the best current practice countermeasure, and while not proved generally secure is a countermeasure against known timing attacks. It adds about 2-10% to the cost of the operation and is implemented in many common cryptographic libraries. Unfortunately, Digital Signature Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have standard methods though some defenses may exist.
3. 盲検化を使用します。これは一般に最良の現在の慣行対策と見なされ、一般的に安全であることは証明されていませんが、既知のタイミング攻撃に対する対策です。操作のコストに約2〜10％を追加し、多くの一般的な暗号化ライブラリに実装されています。残念ながら、デジタル署名アルゴリズム（DSA）および楕円曲線DSA（ECDSA）には標準的な方法はありませんが、一部の防御は存在します。
Note that adding random delays to the operation is only a partial countermeasure. Because the noise is generally uniformly distributed, a large enough number of samples can be used to average it out and extract an accurate timing signal.
操作にランダムの遅延を追加することは、部分的な対策であることに注意してください。ノイズは一般に均一に分布しているため、十分な数のサンプルを使用して平均化して正確なタイミング信号を抽出できます。
Chosen message replay refers to the scenario where the attacker creates a message and obtains a signature for it by sending it through an MTA authorized by the originating domain to himself/herself or an accomplice. They then "replay" the signed message by sending it, using different envelope addresses, to a (typically large) number of other recipients.
選択されたメッセージリプレイとは、攻撃者がメッセージを作成し、自分自身または共犯者に起源のドメインによって承認されたMTAを介して送信することにより、署名を取得するシナリオを指します。次に、異なるエンベロープアドレスを使用して、（通常は大規模な）他の受信者に送信することにより、署名されたメッセージを「リプレイ」します。
Due to the requirement to get an attacker-generated message signed, chosen message replay would most commonly be experienced by consumer ISPs or others offering email accounts to clients, particularly where there is little or no accountability to the account holder (the attacker in this case). One approach to solving this problem is for the domain to only sign email for clients that have passed a vetting process to provide traceability to the message originator in the event of abuse. At present, the low cost of email accounts (zero) does not make it practical for any vetting to occur. It remains to be seen whether this will be the model with signed mail as well, or whether a higher level of trust will be required to obtain an email signature.
攻撃者が生成したメッセージを署名するための要件により、選択されたメッセージリプレイは、特にアカウント所有者に説明責任がほとんどないかまったくない場合、クライアントに電子メールアカウントを提供する消費者ISPまたは他の人が最も一般的に経験するでしょう（この場合、攻撃者はこの場合）。この問題を解決するためのアプローチの1つは、審査プロセスに合格したクライアントにドメインのみに電子メールに署名して、虐待の場合にメッセージオリジネーターにトレーサビリティを提供することです。現在、電子メールアカウントの低コスト（ゼロ）は、審査が発生するために実用的ではありません。これが署名済みのメールを備えたモデルになるかどうか、または電子メールの署名を取得するためにより高いレベルの信頼が必要になるかどうかはまだ不明です。
A variation on this attack involves the attacker sending a message with the intent of obtaining a signed reply containing their original message. The reply might come from an innocent user or might be an automatic response such as a "user unknown" bounce message. In some cases, this signed reply message might accomplish the attacker's objectives if replayed. This variation on chosen message replay can be mitigated by limiting the extent to which the original content is quoted in automatic replies, and by the use of complementary mechanisms such as egress content filtering.
この攻撃のバリエーションには、攻撃者が元のメッセージを含む署名済みの返信を取得する意図でメッセージを送信することが含まれます。返信は、無実のユーザーからのものであるか、「ユーザー不明」バウンスメッセージなどの自動応答である可能性があります。場合によっては、この署名された返信メッセージは、再生された場合に攻撃者の目標を達成する可能性があります。選択したメッセージリプレイのこのバリエーションは、自動応答で元のコンテンツが引用されている程度を制限することと、出力コンテンツフィルタリングなどの相補的なメカニズムを使用することにより、軽減できます。
Revocation of the signature or the associated key is a potential countermeasure. However, the rapid pace at which the message might be replayed (especially with an army of "zombie" computers), compared with the time required to detect the attack and implement the revocation, is likely to be problematic. A related problem is the likelihood that domains will use a small number of signing keys for a large number of customers, which is beneficial from a caching standpoint but is likely to result in a great deal of collateral damage (in the form of signature verification failures) should a key be revoked suddenly.
署名または関連キーの取り消しは、潜在的な対策です。ただし、メッセージが再生される可能性のある急速なペース（特に「ゾンビ」コンピューターの軍隊では）は、攻撃を検出して失効を実装するのに必要な時間と比較して、問題がある可能性があります。関連する問題は、ドメインが多数の顧客に少数の署名キーを使用する可能性は、キャッシュの観点からは有益であるが、多くの担保損傷をもたらす可能性が高い（署名検証の障害の形で）キーを突然取り消す必要があります。
Signature revocation addresses the collateral damage problem at the expense of significant scaling requirements. At the extreme, verifiers could be required to check for revocation of each signature verified, which would result in very significant transaction rates. An alternative, "revocation identifiers", has been proposed, which would permit revocation on an intermediate level of granularity, perhaps on a per-account basis. Messages containing these identifiers would result in a query to a revocation database, which might be represented in DNS.
署名の取り消しは、重大なスケーリング要件を犠牲にして、担保損傷の問題に対処します。極端な場合、検証剤は、検証された各署名の取り消しをチェックする必要があります。その結果、非常に重要なトランザクション率が得られます。代替の「取り消し識別子」が提案されています。これにより、おそらく会議ごとに中間レベルの粒度の取り消しが可能になります。これらの識別子を含むメッセージは、DNSで表される可能性のある取り消しデータベースのクエリになります。
Further study is needed to determine if the benefits from revocation (given the potential speed of a replay attack) outweigh the transactional cost of querying a revocation database.
取り消しデータベースを照会するためのトランザクションコストを上回る、取り消しの利点（リプレイ攻撃の潜在速度を考えると）を判断するには、さらなる研究が必要です。
Signed message replay refers to the retransmission of already-signed messages to additional recipients beyond those intended by the author or the original poster of the message. The attacker arranges to receive a message from the victim, and then retransmits it intact but with different envelope addresses. This might be done, for example, to make it look like a legitimate sender of messages is sending a large amount of spam. When reputation services are deployed, this could damage the author's reputation or that of the author's domain.
署名されたメッセージリプレイとは、著者またはメッセージの元のポスターが意図したものを超えて、追加の受信者に既に署名されたメッセージの再送信を指します。攻撃者は、被害者からメッセージを受け取るように手配し、それをそのままに再送信しますが、異なる封筒アドレスを使用します。これは、たとえば、メッセージの正当な送信者が大量のスパムを送信するように見えるようにするために行われる場合があります。評判サービスが展開されると、著者の評判または著者のドメインの評判を損なう可能性があります。
A larger number of domains are potential victims of signed message replay than chosen message replay because the former does not require the ability for the attacker to send messages from the victim domain. However, the capabilities of the attacker are lower. Unless coupled with another attack such as body length limit abuse, it isn't possible for the attacker to use this, for example, for advertising.
前者は、攻撃者が被害者ドメインからメッセージを送信する能力を必要としないため、選択されたメッセージリプレイよりも署名されたメッセージリプレイの潜在的な犠牲者です。ただし、攻撃者の機能は低くなっています。身体の長さなどの別の攻撃と相まって、乱用を制限しない限り、攻撃者はこれを広告に使用することはできません。
Many mailing lists, especially those that do not modify the content of the message and signed header fields and hence do not invalidate the signature, engage in a form of signed message replay. The use of body length limits and other mechanisms to enhance the survivability of messages effectively enhances the ability to do so. The only things that distinguish this case from undesirable forms of signed message replay is the intent of the replayer, which cannot be determined by the network.
多くのメーリングリスト、特にメッセージのコンテンツを変更して署名したヘッダーフィールドを変更しないため、署名を無効にしないで、署名されたメッセージリプレイの形に従事します。メッセージの生存性を高めるための体の長さの制限やその他のメカニズムを使用すると、そうする能力が効果的に向上します。このケースを、署名されたメッセージリプレイの望ましくない形式と区別する唯一のことは、ネットワークでは決定できないリプレイヤーの意図です。
While it takes some computing resources to sign and verify a signature, it takes negligible computing resources to generate an invalid signature. An attacker could therefore construct a "make work" attack against a verifier, by sending a large number of incorrectly-signed messages to a given verifier, perhaps with multiple signatures each. The motivation might be to make it too expensive to verify messages.
署名に署名して検証するには、コンピューティングリソースがいくつかありますが、無効な署名を生成するには無視できるコンピューティングリソースが必要です。したがって、攻撃者は、おそらくそれぞれ複数の署名を使用して、特定の検証者に多数の誤った署名されたメッセージを送信することにより、検証剤に対する「作業」攻撃を作成できます。動機は、メッセージを検証するには高すぎるようにすることかもしれません。
While this attack is feasible, it can be greatly mitigated by the manner in which the verifier operates. For example, it might decide to accept only a certain number of signatures per message, limit the maximum key size it will accept (to prevent outrageously large signatures from causing unneeded work), and verify signatures in a particular order. The verifier could also maintain state representing the current signature verification failure rate and adopt a defensive posture when attacks may be under way.
この攻撃は実行可能ですが、検証剤が動作する方法によって大いに緩和される可能性があります。たとえば、メッセージごとの特定の数の署名のみを受け入れ、受け入れる最大キーサイズを制限することを決定する場合があります。検証者は、現在の署名検証故障率を表す状態を維持し、攻撃が進行中の場合に防御的な姿勢を採用することもできます。
An attacker might also attempt to degrade the availability of an originator's key service, in order to cause that originator's messages to be unverifiable. One way to do this might be to quickly send a large number of messages with signatures that reference a particular key, thereby creating a heavy load on the key server. Other types of DoS attacks on the key server or the network infrastructure serving it are also possible.
攻撃者はまた、オリジネーターのメッセージを検証できないようにするために、オリジネーターの主要サービスの可用性を分解しようとする場合があります。これを行う1つの方法は、特定のキーを参照する署名を含む多数のメッセージをすばやく送信し、それによってキーサーバーに重い負荷を作成することです。キーサーバーまたはそれにサービスを提供するネットワークインフラストラクチャに対する他のタイプのDOS攻撃も可能です。
The best defense against this attack is to provide redundant key servers, preferably on geographically-separate parts of the Internet. Caching also helps a great deal, by decreasing the load on authoritative key servers when there are many simultaneous key requests. The use of a key service protocol that minimizes the transactional cost of key lookups is also beneficial. It is noted that the Domain Name System has all these characteristics.
この攻撃に対する最善の防御は、できればインターネットの地理的に分離された部分で、冗長なキーサーバーを提供することです。キャッシュは、多くの同時キーリクエストがある場合に、権威あるキーサーバーの負荷を減らすことにより、大いに役立ちます。キールックアップのトランザクションコストを最小限に抑えるキーサービスプロトコルの使用も有益です。ドメイン名システムにはこれらすべての特性があることに注意してください。
Canonicalization algorithms represent a tradeoff between the survival of the validity of a message signature and the desire not to allow the message to be altered inappropriately. In the past, canonicalization algorithms have been proposed that would have permitted attackers, in some cases, to alter the meaning of a message.
標準化アルゴリズムは、メッセージの署名の妥当性の生存と、メッセージを不適切に変更したくないという欲求とのトレードオフを表しています。過去には、攻撃者がメッセージの意味を変更することを許可することを許可していたCanonicalization Algorithmsが提案されてきました。
Message signatures that support multiple canonicalization algorithms give the signer the ability to decide the relative importance of signature survivability and immutability of the signed content. If an unexpected vulnerability appears in a canonicalization algorithm in general use, new algorithms can be deployed, although it will be a slow process because the signer can never be sure which algorithm(s) the verifier supports. For this reason, canonicalization algorithms, like cryptographic algorithms, should undergo a wide and careful review process.
複数の標準化アルゴリズムをサポートするメッセージ署名により、署名者は、署名コンテンツの署名の生存性と不変性の相対的な重要性を決定する能力を与えます。一般に使用されている標準化アルゴリズムに予期しない脆弱性が表示される場合、新しいアルゴリズムを展開できますが、署名者は検証者がどのアルゴリズムをサポートするかを確信できないため、遅いプロセスになります。このため、暗号化アルゴリズムのような標準化アルゴリズムは、幅広い慎重なレビュープロセスを受ける必要があります。
A body length limit is an optional indication from the signer of how much content has been signed. The verifier can either ignore the limit, verify the specified portion of the message, or truncate the message to the specified portion and verify it. The motivation for this feature is the behavior of many mailing lists that add a trailer, perhaps identifying the list, at the end of messages.
体の長さの制限は、署名者からの署名者からの署名の兆候からのオプションの兆候です。検証器は、制限を無視するか、メッセージの指定された部分を確認するか、指定された部分にメッセージを切り捨てて確認できます。この機能の動機は、メッセージの最後に、おそらくリストを識別する多くのメーリングリストの動作です。
When body length limits are used, there is the potential for an attacker to add content to the message. It has been shown that this content, although at the end, can cover desirable content, especially in the case of HTML messages.
体の長さの制限を使用すると、攻撃者がメッセージにコンテンツを追加する可能性があります。特にHTMLメッセージの場合、このコンテンツは最終的には望ましいコンテンツをカバーできることが示されています。
If the body length isn't specified, or if the verifier decides to ignore the limit, body length limits are moot. If the verifier or recipient truncates the message at the signed content, there is no opportunity for the attacker to add anything.
体の長さが指定されていない場合、または検証者が制限を無視することを決定した場合、体の長さの制限は論争です。検証者または受信者が署名されたコンテンツでメッセージを切り捨てた場合、攻撃者が何かを追加する機会はありません。
If the verifier observes body length limits when present, there is the potential that an attacker can make undesired content visible to the recipient. The size of the appended content makes little difference, because it can simply be a URL reference pointing to the actual content. Receiving MUAs can mitigate this threat by, at a minimum, identifying the unsigned content in the message.
検証剤が存在するときに体の長さの制限を観察する場合、攻撃者が望ましくないコンテンツを受信者に見える可能性があります。Appledコンテンツのサイズは、実際のコンテンツを指すURL参照であるため、ほとんど違いがありません。MUASを受信すると、メッセージ内の署名されていないコンテンツを少なくとも識別することにより、この脅威を軽減できます。
The benefits obtained by caching of key records opens the possibility that keys that have been revoked may be used for some period of time after their revocation. The best examples of this occur when a holder of a key delegated by the domain administrator must be unexpectedly deauthorized from sending mail on behalf of one or more addresses in the domain.
キーレコードのキャッシングによって得られる利点は、取り消されたキーが取り消し後、しばらく使用される可能性がある可能性を開きます。これの最良の例は、ドメイン管理者によって委任されたキーの所有者が、ドメイン内の1つ以上のアドレスに代わってメールを送信することを予想外に免罪しなければならない場合に発生します。
The caching of key records is normally short-lived, on the order of hours to days. In many cases, this threat can be mitigated simply by setting a short time-to-live (TTL) for keys not under the domain administrator's direct control (assuming, of course, that control of the TTL value may be specified for each record, as it can with DNS). In some cases, such as the recovery following a stolen private key belonging to one of the domain's MTAs, the possibility of theft and the effort required to revoke the key authorization must be considered when choosing a TTL. The chosen TTL must be long enough to mitigate denial-of-service attacks and provide reasonable transaction efficiency, and no longer.
主要な記録のキャッシュは、通常、数時間から日数の順に短命です。多くの場合、この脅威は、ドメイン管理者の直接制御下にないキーに短い時間（TTL）を設定するだけで軽減できます（もちろん、TTL値の制御が各レコードに対して指定される可能性があると仮定します。DNSでできる限り）。場合によっては、ドメインのMTAの1つに属する盗まれた秘密鍵に続いて回復するなど、TTLを選択する際に、盗難の可能性と重要な承認を取り消すために必要な努力を考慮する必要があります。選択されたTTLは、サービス拒否攻撃を緩和し、合理的な取引効率を提供するのに十分な長さでなければなりません。
Rather than by attempting to obtain a private key, an attacker might instead focus efforts on the server used to publish public keys for a domain. As in the key theft case, the motive might be to allow the attacker to sign messages on behalf of the domain. This attack provides the attacker with the additional capability to remove legitimate keys from publication, thereby denying the domain the ability for the signatures on its mail to verify correctly.
攻撃者は、秘密鍵を取得しようとするのではなく、ドメインのパブリックキーを公開するために使用されるサーバーに努力を集中する場合があります。主要な盗難の場合のように、動機は攻撃者がドメインに代わってメッセージに署名できるようにすることかもしれません。この攻撃により、攻撃者は公開から合法的なキーを削除する追加の機能を提供し、それにより、ドメインにメールの署名が正しく検証する能力を否定します。
In order to limit the ability to sign a message to entities authorized by the owner of a signing domain, a relationship must be established between the signing address and the location from which a public key is obtained to verify the message. DKIM does this by publishing either the public key or a reference to it within the DNS hierarchy of the signing domain. The verifier derives the location from which to retrieve the public key from the signing address or domain. The security of the verification process is therefore dependent on the security of the DNS hierarchy for the signing domain.
署名ドメインの所有者によって承認されたエンティティにメッセージを署名する機能を制限するには、署名アドレスとメッセージを確認するために公開キーが取得される場所との関係を確立する必要があります。DKIMは、署名ドメインのDNS階層内で公開キーまたはそれを参照することにより、これを行います。検証器は、署名アドレスまたはドメインから公開キーを取得する場所を導き出します。したがって、検証プロセスのセキュリティは、署名ドメインのDNS階層のセキュリティに依存します。
An attacker might successfully compromise the host that is the primary key server for the signing domain, such as the domain's DNS master server. Another approach might be to compromise a higher-level DNS server and change the delegation of name servers for the signing domain to others under the control of the attacker.
攻撃者は、ドメインのDNSマスターサーバーなど、署名ドメインの主要なキーサーバーであるホストを正常に侵害する可能性があります。別のアプローチは、高レベルのDNSサーバーを妥協し、攻撃者の制御下にある署名ドメインのための名前サーバーの委任を変更することです。
This attack can be mitigated somewhat by independent monitoring to audit the key service. Such auditing of the key service should occur by means of zone transfers rather than queries to the zone's primary server, so that the addition of records to the zone can be detected.
この攻撃は、キーサービスを監査するための独立した監視により、多少軽減できます。このようなキーサービスの監査は、ゾーンのプライマリサーバーへのクエリではなく、ゾーン転送によって発生する必要があり、ゾーンへのレコードの追加を検出できます。
Replies from the key service may also be spoofed by a suitably positioned attacker. For DNS, one such way to do this is "cache poisoning", in which the attacker provides unnecessary (and incorrect) additional information in DNS replies, which is cached.
キーサービスからの返信は、適切に配置された攻撃者によってもたらされる場合があります。DNSの場合、これを行うそのような方法の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の現在の取り込み率は十分に遅く、展開に依存したくない。キャッシュ中毒攻撃の場合、この攻撃によって作成された脆弱性はローカライズされており、期間が限られていますが、比較的長いTTLの記録は攻撃自体を超えて持続する可能性があります。
In this attack, the attacker publishes suitably crafted key records or sends mail with intentionally malformed signatures, in an attempt to confuse the verifier and perhaps disable verification altogether. This attack is really a characteristic of an implementation vulnerability, a buffer overflow or lack of bounds checking, for example, rather than a vulnerability of the signature mechanism itself. This threat is best mitigated by careful implementation and creation of test suites that challenge the verification process.
この攻撃では、攻撃者は、検証剤を混乱させ、おそらく検証を完全に無効にするために、適切に作成されたキーレコードを公開するか、意図的に奇形の署名でメールを送信します。この攻撃は、たとえば、署名メカニズム自体の脆弱性ではなく、実装の脆弱性、バッファーオーバーフロー、または境界チェックの欠如の特徴です。この脅威は、検証プロセスに挑戦する慎重な実装とテストスイートの作成によって最もよく緩和されます。
The cryptographic algorithms used to generate mail signatures, specifically the hash algorithm and digital signature generation and verification operations, may over time be subject to mathematical techniques that degrade their security. At this writing, the SHA-1 hash algorithm is the subject of extensive mathematical analysis that has considerably lowered the time required to create two messages with the same hash value. This trend can be expected to continue.
メールの署名、特にハッシュアルゴリズムとデジタル署名の生成および検証操作を生成するために使用される暗号化アルゴリズムは、時間の経過とともにセキュリティを分解する数学的手法の対象となる場合があります。この記事では、SHA-1ハッシュアルゴリズムは、同じハッシュ値で2つのメッセージを作成するのに必要な時間を大幅に短縮した広範な数学分析の対象です。この傾向は続くと予想されます。
One consequence of a weakness in the hash algorithm is a hash collision attack. Hash collision attacks in message signing systems involve the same person creating two different messages that have the same hash value, where only one of the two messages would normally be signed. The attack is based on the second message inheriting the signature of the first. For DKIM, this means that a sender might create a "good" message and a "bad" message, where some filter at the signing party's site would sign the good message but not the bad message. The attacker gets the good message signed, and then incorporates that signature in the bad message. This scenario is not common, but could happen, for example, at a site that does content analysis on messages before signing them.
ハッシュアルゴリズムの弱点の結果の1つは、ハッシュ衝突攻撃です。メッセージ署名システムのハッシュ衝突攻撃には、同じハッシュ値を持つ2つの異なるメッセージを作成するのと同じ人が含まれます。通常、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.
電子メールの署名者と検証者は、一般的に、署名に使用されるアルゴリズムの交渉が発生することはありません。言い換えれば、署名者は、検証者がどのアルゴリズムをサポートしているか、または検証者がどこにいるか（メール転送のため）を知る方法がありません。このため、メッセージの署名が広く展開されると、アルゴリズムの変更がゆっくりと発生し、レガシーアルゴリズムをかなりの期間サポートする必要があると予想されます。したがって、メッセージ署名に使用されるアルゴリズムは、数年後に予想される暗号化の発展に対して安全である必要があります。
Message signatures only relate to the address-specification portion of an email address, while some MUAs only display (or some recipients only pay attention to) the display name portion of the address. This inconsistency leads to an attack where the attacker uses a From header field such as:
メッセージの署名は、メールアドレスのアドレス指定部分にのみ関連しますが、一部のMUAはアドレスの表示名の部分を表示する（または一部の受信者のみに注意してください）。この矛盾は、攻撃者が次のようなヘッダーフィールドからAを使用する攻撃につながります。
From: "Dudley DoRight" <whiplash@example.org>
In this example, the attacker, whiplash@example.org, can sign the message and still convince some recipients that the message is from Dudley DoRight, who is presumably a trusted individual. Coupled with the use of a throw-away domain or email address, it may be difficult to hold the attacker accountable for using another's display name.
この例では、攻撃者のwhiplash@example.orgはメッセージに署名し、おそらく信頼できる個人であるダドリー・ドーライトからのメッセージがあることを受信者に納得させることができます。スローアウェイドメインまたは電子メールアドレスの使用と相まって、攻撃者に他人のディスプレイ名を使用することで責任を負わせることは難しいかもしれません。
This is an attack that must be dealt with in the recipient's MUA. One approach is to require that the signer's address specification (and not just the display name) be visible to the recipient.
これは、受信者のMUAで対処しなければならない攻撃です。1つのアプローチは、署名者のアドレス仕様（ディスプレイ名だけでなく）が受信者に表示されることを要求することです。
In many cases, MTAs may be configured to accept and sign messages that originate within the topological boundaries of the originator's network (i.e., within a firewall). The increasing use of compromised systems to send email presents a problem for such policies, because the attacker, using a compromised system as a proxy, can generate signed mail at will.
多くの場合、MTAは、オリジネーターのネットワークのトポロジー境界内（つまり、ファイアウォール内）内で発生するメッセージを受け入れて署名するように構成される場合があります。侵害されたシステムの使用が増加して電子メールを送信すると、攻撃者はプロキシとして侵害されたシステムを使用して、自由に署名されたメールを生成できるため、そのようなポリシーに問題が発生します。
Several approaches exist for mitigating this attack. The use of authenticated submission, even within the network boundaries, can be used to limit the addresses for which the attacker may obtain a signature. It may also help locate the compromised system that is the source of the messages more quickly. Content analysis of outbound mail to identify undesirable and malicious content, as well as monitoring of the volume of messages being sent by users, may also prevent arbitrary messages from being signed and sent.
この攻撃を緩和するためのいくつかのアプローチが存在します。ネットワークの境界内であっても、認証された提出の使用を使用して、攻撃者が署名を取得できるアドレスを制限できます。また、メッセージのソースである侵害されたシステムをより迅速に見つけるのに役立ちます。望ましくない悪意のあるコンテンツを識別するアウトバウンドメールのコンテンツ分析、およびユーザーが送信するメッセージの量の監視は、任意のメッセージが署名されて送信されるのを防ぐ場合があります。
As noted above, bad actors (attackers) can sign messages on behalf of domains they control. Since they may also control the key service (e.g., the authoritative DNS name servers for the _domainkey subdomain), it is possible for them to observe public key lookups, and their source, when messages are verified.
上記のように、悪い俳優（攻撃者）は、制御するドメインに代わってメッセージに署名できます。彼らはまた、キーサービス（例：_DomainKeyサブドメインの権威あるDNS名サーバー）を制御する可能性があるため、メッセージが検証されたときに公開キーの検索とそのソースを観察することが可能です。
One such attack, which we will refer to as a "verification probe", is to send a message with a DKIM signature to each of many addresses in a mailing list. The messages need not contain valid signatures, and each instance of the message would typically use a different selector. The attacker could then monitor key service requests and determine which selectors had been accessed, and correspondingly which addressees used DKIM verification. This could be used to target future mailings at recipients who do not use DKIM verification, on the premise that these addressees are more likely to act on the message contents.
「検証プローブ」と呼ばれるこのような攻撃の1つは、メーリングリストの多くのアドレスのそれぞれにDKIM署名を含むメッセージを送信することです。メッセージには有効な署名を含める必要はなく、メッセージの各インスタンスは通常、異なるセレクターを使用します。攻撃者は、キーサービスの要求を監視し、どのセレクターにアクセスしたかを決定することができ、それに応じてどの宛先がDKIM検証を使用したかを決定しました。これは、DKIM検証を使用していない受信者での将来の郵送者をターゲットにするために、これらの宛先がメッセージの内容に基づいて行動する可能性が高いという前提でターゲットにすることができます。
In order to support the ability of a domain to sign for subdomains under its administrative control, DKIM permits the domain of a signature (d= tag) to be any higher-level domain than the signature's address (i= or equivalent). However, since there is no mechanism for determining common administrative control of a subdomain, it is possible for a parent to publish keys that are valid for any domain below them in the DNS hierarchy. In other words, mail from the domain example.anytown.ny.us could be signed using keys published by anytown.ny.us, ny.us, or us, in addition to the domain itself.
DKIMは、ドメインがサブドメインに署名する能力をサポートするために、署名（d = tag）のドメインを署名のアドレス（i =または同等）よりも高レベルのドメインであることを許可します。ただし、サブドメインの一般的な管理制御を決定するメカニズムがないため、親がDNS階層の下にあるドメインに有効なキーを公開することができます。言い換えれば、ドメイン自体に加えて、anytown.ny.us、ny.us、またはusが公開しているキーを使用して、domain 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.
ドメインの操作には、常に高レベルのドメインとの信頼関係が必要です。高レベルのドメインは、すでにサブドメインに対して究極の力を持っています。彼らはドメインの名前サーバー委任を変更したり、完全に権利を奪ったりすることができます。したがって、この方法で高レベルのドメインが意図的にサブドメインを侵害する可能性は低いです。ただし、高レベルのドメインが独自にメールを送信した場合、独自のレベルでキーを公開したい場合があります。高レベルのドメインは、公開するキーの委任に特別な注意を払う必要があり、そのようなキーの誤用によってサブドメインのいずれかが危険にさらされないようにします。
The following is a summary of postulated attacks against signing practices:
以下は、署名慣行に対する仮定攻撃の要約です。
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+
Attackers may attempt to circumvent signing practices of a domain by using a domain name that is close to, but not the same as, the domain with signing practices. For instance, "example.com" might be replaced by "examp1e.com". If the message is not to be signed, DKIM does not require that the domain used actually exist (although other mechanisms may make this a requirement). Services exist to monitor domain registrations to identify potential domain name abuse, but naturally do not identify the use of unregistered domain names.
攻撃者は、署名プラクティスを持つドメインとは近いが同じではないドメイン名を使用して、ドメインの署名慣行を回避しようとする場合があります。たとえば、「Example.com」は「Examp1e.com」に置き換えられる可能性があります。メッセージに署名されない場合、DKIMは使用されるドメインが実際に存在することを要求しません（ただし、他のメカニズムはこれを要件にする可能性があります）。ドメイン登録を監視するためのサービスが存在し、潜在的なドメイン名の悪用を特定しますが、当然、未登録のドメイン名の使用を特定しません。
A related attack is possible when the MUA does not render the domain name in an easily recognizable format. If, for example, a Chinese domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the unfamiliarity of that representation may enable other domains to more easily be mis-recognized as the expected domain.
MUAがドメイン名を簡単に認識できる形式でレンダリングしない場合、関連する攻撃が可能です。たとえば、中国のドメイン名がxn - cjsp26b3obxw7f.comとして「punycode」でレンダリングされている場合、その表現の不慣れさにより、他のドメインが予想されるドメインとしてより簡単に認識される可能性があります。
Users that are unfamiliar with internet naming conventions may also mis-recognize certain names. For example, users may confuse online.example.com with online-example.com, the latter of which may have been registered by an attacker.
インターネットの命名規則に不慣れなユーザーも、特定の名前を誤って認識する場合があります。たとえば、ユーザーはOnline.example.comをオンラインexample.comと混同することがありますが、後者は攻撃者によって登録されている可能性があります。
Internationalized domain names present a special case of the look-alike domain name attack described above. Due to similarities in the appearance of many Unicode characters, domains (particularly those drawing characters from different groups) may be created that are visually indistinguishable from other, possibly high-value domains. This is discussed in detail in Unicode Technical Report 36 [UTR36].
国際化されたドメイン名は、上記の見た目のドメイン名攻撃の特別なケースを提示します。多くのユニコード文字の外観が類似しているため、ドメイン（特に異なるグループからの描画文字）が作成され、他の、場合によっては高価値のドメインと区別できない視覚的に区別できます。これについては、Unicodeテクニカルレポート36 [UTR36]で詳しく説明しています。
Surveillance of domain registration records may point out some of these, but there are many such similarities. As in the look-alike domain attack above, this technique may also be used to circumvent sender signing practices of other domains.
ドメイン登録記録の監視は、これらのいくつかを指摘するかもしれませんが、そのような類似点はたくさんあります。上記の見た目のようなドメイン攻撃と同様に、この手法は、他のドメインの署名慣行に送信者を回避するためにも使用できます。
Just as the publication of public keys by a domain can be impacted by an attacker, so can the publication of Sender Signing Practices (SSP) by a domain. In the case of SSP, the transmission of large amounts of unsigned mail purporting to come from the domain can result in a heavy transaction load requesting the SSP record. More general DoS attacks against the servers providing the SSP records are possible as well. This is of particular concern since the default signing practices are "we don't sign everything", which means that SSP failures result in the verifier's failure to heed more stringent signing practices.
ドメインによるパブリックキーの公開が攻撃者の影響を受ける可能性があるように、ドメインによる送信者署名プラクティス（SSP）の出版物もできます。SSPの場合、ドメインから来ると主張する大量の署名のないメールの送信により、SSPレコードを要求する重いトランザクション負荷が発生する可能性があります。SSPレコードを提供するサーバーに対するより一般的なDOS攻撃も可能です。これは、デフォルトの署名プラクティスが「すべてに署名しない」であるため、特に懸念事項です。つまり、SSPの障害は、より厳しい署名プラクティスに耳を傾けるVerifierの失敗につながることを意味します。
As with defense against DoS attacks for key servers, the best defense against this attack is to provide redundant servers, preferably on geographically-separate parts of the Internet. Caching again helps a great deal, and signing practices should rarely change, so TTL values can be relatively large.
キーサーバーのDOS攻撃に対する防御と同様に、この攻撃に対する最良の防御は、できればインターネットの地理的に分離された部分で冗長なサーバーを提供することです。キャッシュは再び大いに役立ち、署名プラクティスはめったに変わらないので、TTLの値は比較的大きくなる可能性があります。
Although this usage is never seen by most recipients, RFC 2822 [RFC2822] permits the From address to contain multiple address specifications. The lookup of Sender Signing Practices is based on the From address, so if addresses from multiple domains are in the From address, the question arises which signing practices to use. A rule (say, "use the first address") could be specified, but then an attacker could put a throwaway address prior to that of a high-value domain. It is also possible for SSP to look at all addresses, and choose the most restrictive rule. This is an area in need of further study.
この使用法はほとんどの受信者には決して見られませんが、RFC 2822 [RFC2822]により、FROMアドレスが複数のアドレス仕様を含めることができます。送信者署名プラクティスの検索は、FROMアドレスに基づいているため、複数のドメインからのアドレスがFROMアドレスにある場合、どの署名プラクティスを使用するかという疑問が生じます。ルール（「最初のアドレスを使用する」）を指定することができますが、攻撃者は、価値の高いドメインのアドレスの前に、攻撃者のアドレスを投げることができます。また、SSPがすべてのアドレスを見て、最も制限的なルールを選択することも可能です。これは、さらなる研究が必要な分野です。
In a number of situations, including mailing lists, event invitations, and "send this article to a friend" services, the DKIM signature on a message may not come from the originating address domain. For this reason, "third-party" signatures, those attached by the mailing list, invitation service, or news service, frequently need to be regarded as having some validity. Since this effectively makes it possible for any domain to sign any message, a sending domain may publish sender signing practices stating that it does not use such services, and accordingly that verifiers should view such signatures with suspicion.
メーリングリスト、イベントの招待状、「この記事を友人に送る」サービスなどの多くの状況では、メッセージのDKIM署名は、元のアドレスドメインから来ていない場合があります。このため、メーリングリスト、招待サービス、またはニュースサービスで添付されている「サードパーティ」の署名は、頻繁にある程度の妥当性を持っていると見なされる必要があります。これにより、あらゆるドメインがメッセージに署名することが効果的に可能になるため、送信ドメインは、そのようなサービスを使用しないことを示す送信者の署名プラクティスを公開する場合があります。
However, the restrictions placed on a domain by publishing "no third-party" signing practices effectively disallows many existing uses of email. For the majority of domains that are unable to adopt these practices, an attacker may with some degree of success sign messages purporting to come from the domain. For this reason, accreditation and reputation services, as well as locally-maintained whitelists and blacklists, will need to play a significant role in evaluating messages that have been signed by third parties.
ただし、「サードパーティなし」の署名プラクティスを公開することにより、ドメインに課される制限は、既存の多くの電子メールの使用を効果的に許可します。これらのプラクティスを採用できないドメインの大部分では、攻撃者は、ドメインから来ると主張するある程度の成功標識メッセージを持つ場合があります。このため、認定と評判のサービス、および地元でメンテナンスされたホワイトリストとブラックリストは、第三者によって署名されたメッセージの評価に重要な役割を果たす必要があります。
In an analogous manner to the falsification of key service replies described in Section 4.1.12, replies to sender signing practices queries can also be falsified. One such attack would be to weaken the signing practices to make unsigned messages allegedly from a given domain appear less suspicious. Another attack on a victim domain that is not signing messages could attempt to make the domain's messages look more suspicious, in order to interfere with the victim's ability to send mail.
セクション4.1.12で説明されているキーサービスの返信の改ざんに類似して、送信者への署名プラクティスクエリへの返信も偽造することができます。そのような攻撃の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がない場合でも、キャッシュ中毒による脆弱性は局所化されています。
This section describes attacks against other Internet infrastructure that are enabled by deployment of DKIM. A summary of these postulated attacks is as follows:
このセクションでは、DKIMの展開によって有効になっている他のインターネットインフラストラクチャに対する攻撃について説明します。これらの仮定攻撃の概要は次のとおりです。
+--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+
Recently, there has been an increase in denial-of-service attacks involving the transmission of spoofed UDP DNS requests to openly-accessible domain name servers [US-CERT-DNS]. To the extent that the response from the name server is larger than the request, the name server functions as an amplifier for such an attack.
最近、オープンにアクセス可能なドメイン名サーバー[US-Cert-DNS]へのスプーフィングされたUDP DNS要求の送信を含む、サービス拒否攻撃の増加がありました。名前サーバーからの応答が要求よりも大きい限り、名前サーバーはそのような攻撃のアンプとして機能します。
DKIM contributes indirectly to this attack by requiring the publication of fairly large DNS records for distributing public keys. The names of these records are also well known, since the record names can be determined by examining properly-signed messages. This attack does not have an impact on DKIM itself. DKIM, however, is not the only application that uses large DNS records, and a DNS-based solution to this problem will likely be required.
DKIMは、公開キーを配布するためにかなり大きなDNSレコードを公開することを要求することにより、この攻撃に間接的に貢献しています。レコード名は適切に署名されたメッセージを調べることで決定できるため、これらのレコードの名前もよく知られています。この攻撃は、DKIM自体に影響を与えません。ただし、DKIMは、大規模なDNSレコードを使用する唯一のアプリケーションではなく、この問題に対するDNSベースのソリューションが必要になる可能性があります。
This section lists requirements for DKIM not explicitly stated in the above discussion. These requirements include:
このセクションには、上記の議論で明示的に述べられていないDKIMの要件をリストします。これらの要件には以下が含まれます。
The store for key and SSP records must be capable of utilizing multiple geographically-dispersed servers.
キーレコードとSSPレコードのストアは、複数の地理的に分散したサーバーを利用できる必要があります。
Key and SSP records must be cacheable, either by the verifier requesting them or by other infrastructure.
Verifierがそれらを要求するか、他のインフラストラクチャによって、KeyおよびSSPレコードはキャッシュ可能でなければなりません。
The cache time-to-live for key records must be specifiable on a per-record basis.
キーレコードのキャッシュ時間までのキャッシュは、記録ごとに指定する必要があります。
The signature algorithm identifier in the message must be one of the ones listed in a key record for the identified domain.
メッセージ内の署名アルゴリズム識別子は、識別されたドメインのキーレコードにリストされているものの1つでなければなりません。
The algorithm(s) used for message signatures need to be secure against expected cryptographic developments several years in the future.
メッセージ署名に使用されるアルゴリズムは、将来数年間、予想される暗号化の開発に対して安全である必要があります。
This document describes the security threat environment in which DomainKeys Identified Mail (DKIM) is expected to provide some benefit, and it presents a number of attacks relevant to its deployment.
このドキュメントでは、ドメインキーが識別されたメール（DKIM）が何らかの利点を提供すると予想されるセキュリティの脅威環境について説明し、その展開に関連する多くの攻撃を提示します。
[Bernstein04] Bernstein, D., "Cache Timing Attacks on AES", April 2004.
[Bernstein04] Bernstein、D。、「AESのキャッシュタイミング攻撃」、2004年4月。
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are Practical", Proc. 12th USENIX Security Symposium, 2003.
[DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM) Signatures", Work in Progress, August 2006.
[dkim-base] Allman、E。、「Domainkeys Idefied Mail（dkim）署名」、2006年8月の作業。
[DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in Progress, August 2006.
[dkim-ssp] Allman、E。、「Dkim送信者署名慣行」、2006年8月、進行中の作業。
[Kocher96] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, and other Cryptosystems", Advances in Cryptology, pages 104-113, 1996.
[Kocher96] Kocher、P。、「Diffie-Hellman、RSA、およびその他の暗号システムの実装に対するタイミング攻撃」、Cryptologyの進歩、104〜113ページ、1996年。
[Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power Analysis: Leaking Secrets", Crypto '99, pages 388-397, 1999.
[Kocher99] Kocher、P.、Joffe、J。、およびB. Yun、「微分力分析：漏れ秘密」、Crypto '99、ページ388-397、1999。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル -バージョン3」、STD 53、RFC 1939、1996年5月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat Posed by DNS Recursion".
[us-cert-dns] us-cert、「DNS再帰によってもたらされるサービス脅威の継続的な拒否」。
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", UTR 36, July 2005.
[UTR36] Davis、M。and M. Suignard、「Unicode Technical Report＃36：Unicode Security Smignations」、UTR 36、2005年7月。
The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla, Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim mailing list for valuable suggestions and constructive criticism of earlier versions of this document.
著者は、フィリップ・ハラム・ベーカー、エリオット・リア、トニー・フィンチ、デイブ・クロッカー、バリー・レイバ、アルベル・ハスコック、エリック・オールマン、ジョン・カラス、スティーブン・ファレル、ダグ・オーティス、フランク・エラーマン、エリック・レスカルラ、ポール・ホフマン、ヘクター・サントス、このドキュメントの以前のバージョンに対する貴重な提案と建設的な批判について、IETF-DKIMメーリングリストの他の多くの人々。
Author's Address
著者の連絡先
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
Jim Fenton Cisco Systems、Inc。MS SJ-9/2 170 W. Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 408 526 5914
EMail: fenton@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。