|
ネットワーク WG Request for Comments： 4686 分類： 情報提供 |
J. Fenton Cisco Systems, Inc. 2006年9月 |
このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The Internet Society (2006).
本書は、 署名に基づくメール認証が対応することを意図されたインターネットメールについて(特に、 DKIMについて)いくつかの脅威分析を提供します。 これは、悪役(攻撃者)の性格と場所、 「彼らに何ができるか？」および「何を彼らは、 攻撃を通じて達成することを意図するか？」を検討するものです。
DKIM (DomainKeys Identified Mail)プロトコルは、 IETF DKIM WGによって規定されつつあります。 DKIMプロトコルは、eメールのメッセージに暗号技術的に署名し、 署名するドメインが所与のeメールアドレスの利用についての責任を主張できるようにするメカニズムを規定します。 メッセージ受信者は、適切な公開鍵を取得するために、直接、 署名者のドメインに問い合わせることによって、その署名を検証でき、 それによって、「そのメッセージは、 署名するドメインについてのプライベート鍵を保持する主体によって、 証明(attest)されたこと」を確認できます。 本書は、DKIM WGによって進行中の2つの作業(DKIM署名仕様 [DKIM-BASE] およびDKIM SSP (Sender Signing Practices) [DKIM-SSP])に関連する脅威に対応します。
ひとたび証明する(attesting)主体が確立されると、その受信者は、 ローカルに維持管理されたホワイトリスト、 共有された評判(reputation)サービス、かつ／または、 第三者による認定(accreditation)のような、 追加的な情報の文脈でメッセージを評価する可能性があります。 これらのメカニズムについての記述は、 IETF DKIM WGの活動の範囲外です。 署名を適用することによって、善玉は、 その受信者による優先的な扱いを受けることを期待して、 検証器がそのメッセージについての積極的な評判を関連づけることができるようにします。
この努力は、 メッセージの守秘性に関連する脅威に対応することを意図されたものではありませんし、 長期保存署名を提供することを意図されたものでもありません。
AU (Administrative Unit)は、 卑近な運用管理のもとにあるeメールのメッセージのパスの部分です。 その発信者と受信者は、典型的には、 彼らのeメールを送受信するAUと、それぞれに、 彼らのメッセージの署名と検証を行うために信頼関係を築きます。
発信元アドレスは、 メールメッセージ上のアドレス(典型的には、 RFC 2822 From: アドレス)です。 これは、そのメッセージの言い立てた張本人(author)に関連づけられ、 受信者のMUA (Mail User Agent)によって、 そのメッセージの発信元として表示されます。
下図は、 DKIMについての典型的な用法のフローチャートを表しています。：
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[インターネット]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
DKIMは、RFC 2822 [RFC2822] に規定されているメッセージのcontent(ボディおよび選択されたヘッダーフィールド)全体を操作します。 メッセージのSMTP (RFC 2821 [RFC2821] に規定されている)経由の転送と、 envelope-fromとenvelope-toのアドレス、 およびHELOドメインのような要素は、DKIM検証とは関連しません。 これは、検証器としてふるまうMUAが使う可能性があるPOP [RFC1939] やIMAP [RFC3501] のような、 SMTP以外のプロトコル経由のメッセージの検証を許可するために行われた意図的な判断です。
上図において表現されているSSP (Sender Signing Practices) Queryは、 その検証器がメッセージに署名するための彼らの業務を判定するために、 その言い立てた張本人のドメインに問い合わせることができる手段です。 これは、かえって、 彼らのメッセージの評価に影響を与える可能性があります。 例えば、メッセージが何ら妥当な署名無しに到着し、かつ、 その言い立てた張本人のドメインが「すべてのメッセージに署名する」と広告する場合、 その検証器は、そのメッセージを、 署名が必ずしも予期されなかった場合とは違うように扱う可能性があります。
本書の残りの部分では、 DKIMが対応することが期待される可能性がある問題と、DKIMが、 そのようにする際に成功する可能性がある程度を記述します。 これらは、潜在的な悪役、彼らの能力とネットワークにおける場所、 および、 彼らが行うことを望む可能性がある悪い行いの観点から記述されます。
これには、DKIMメッセージ署名についてと、 署名されていないメッセージの扱いにおいて支援するためのSSPの利用についての想定されている攻撃についての記述が伴います。 導かれる要件のリストも提供され、 DKIMの設計やレビューのプロセスを導くことが意図されています。
DKIMについての攻撃を扱う節は、各々、 各区分において想定される攻撃を、 それらの予期される影響と確率と共に要約する表で始まります。 下記の定義は、 その攻撃を点数化するための粗削りなクライテリアとして使われました。：
高：ドメイン全体もしくは複数のドメインからのメッセージの検証に影響を与える
中：特定のユーザ、MTA (Mail Transfer Agent)からのメッセージの検証、かつ／または、限られた期間に影響を与える
低：分離された個々のメッセージのみの検証に影響を与える
高：すべてのeメール・ユーザは、この攻撃を頻繁に予期するはずである
中：eメール・ユーザは、この攻撃をときどき予期するはずである(少数のユーザについて頻繁)
低：攻撃は、希、かつ／または、とても低頻度であることが予期される
DKIMによって対応される問題空間は、動機、 洗練および能力の観点から広範な攻撃者によって特徴づけられます。
範囲内の最低層にいるのは、「おそらく、単に、 (多くの商業的に入手可能なツールのひとつを使って)受信者が受信することを望まないようなeメールを送信する可能性がある悪役」です。 これらのツールは、典型的には、 そのメッセージの発信元アドレスを偽ることができるようにしてしまい、 また、将来、メッセージ署名も生成できる可能性があります。
次の層にいるのは、「何が、 望まれないeメールの『プロフェッショナル』送信者と見なされるか？」です。 これらの攻撃者は、場合によっては、 送信する宛先アドレスを収集するために、 (MTA (Mail Transfer Agent)、 メッセージを送信するために侵されたコンピュータ(「ゾンビ」)の登録されたドメインやネットワークを含む)特定のインフラストラクチャを配備します。 これらの送信者は、しばしば、商業企業として操作し、 第三者に代わってメッセージを送信ます。
最も洗練され、 かつ経済的に動機づけられたメッセージの送信者は、 eメールに基づく詐欺スキームからのように、 実質的な経済的便益を受ける立場の者です。 これらの攻撃者は、 上記のメカニズムのすべてを採用することが予期される可能性があり、 さらに、DNSキャッシュ毒盛り(poisoning)攻撃やIPルーティング攻撃を含むインターネット・インフラストラクチャ自体を攻撃する可能性があります。
一般に、上記の悪役は、 下記の事項にアクセスできることが予期される必要があります。：
また、 少なくとも下記の事項のいくつかを行う能力が予期される必要があります。：
上記のように、ある種の悪役は、彼らの活動について、 実質的・経済的な動機をもつ可能性があり、それゆえ、 彼らの位置によっては、 より高い能力をもつことを予期される必要があります。 これらは、下記の事項を含みます。：
これらのメカニズムの最初の2つのいずれかは、 その攻撃が有用である場合、 その悪役が張本人と受信者の間における中間者(man-in-the-middle)として機能することを許可するために使われる可能性があります。
悪役、もしくは、彼らのプロキシは、 インターネット中のあらゆるところに配置される可能性があります。 ある種の攻撃は、以降の節において記述されているように、主に、 主張された発信者のAU内、かつ／または、 それら以上の能力をもつ受信者のドメインにおいて、可能です。 悪役は、複数の場所(「散在する(distributed)悪役」)から演じることによって、 共謀する(collude)可能性もあります。
「『ゾンビ』や他のプロキシの利用を利用する外部に位置する悪役は、 主張されている発信者の、もしくは、 受信者のAU内に位置する一定の能力を得る可能性があること」は、 注目される必要があります。 これは、たとえAU内でも、 メッセージの認証された送信のような適切なセキュリティ手段の重要性を強調します。
DKIMは、主に、 主張されている発信者および受信者のAUの外部に位置する悪役に注力します。 これらのAUは、頻繁に、 発信者および受信者に隣接したネットワークの防護された部分に対応します。 「認証されたメッセージの送信に要求される信頼関係が存在せず、 実践的となるように適切に規模拡大しない」のは、 この領域においてです。 逆に、これらのAU内においては、より配備しやすく、 DKIMよりも使われやすい「認証されたメッセージ送信」のような他のメカニズムがあります。
外部の悪役は、通常、eメールの「誰でも、 誰とでも(any to any)」な性格を攻略することを試みています。 この性格は、大部分の受信者MTAを、 そのローカル・ドメイン宛に配信するために、 あらゆるところからのメッセージを受けつけるように動機づけます。 彼らは、署名無しのメッセージ、不正な署名をもつメッセージ、 あるいは、 追跡可能性がほとんど無いドメインから正しい署名をもつメッセージを生成する可能性があります。 それらは、メーリングリスト、あいさつ状、あるいは、 他者に代わって正規にメッセージを送信(もしくは再送)する他のエージェントのふりをする可能性もあります。
悪党(rogue)、もしくは、認可されていないユーザ、もしくは、 マルウェアに感染したコンピュータの形態をとる悪役は、 メッセージの発信元アドレスに対応するAU中に存在する可能性があります。 この領域において、メッセージの送信は、一般に、 メッセージへの署名の前に発生するので、DKIMは、 これらの悪役に対して、直接的には効果的ではありません。 これらの悪役に対する防衛は、ファイアウォールの正しい利用や、 その張本人を本人認証するように設定されたMSA (Message Submission Agent)のような他の手段に依存します。
そのAUが隣接していない場合(例：外部のインターネット越しに支店間でやり取りする会社)、 DKIMの署名は、正規に外部から発信されたメッセージと、 ローカルドメイン中のアドレスを偽装する試みを区別するために使えます。
悪役は、 そのメッセージ受信者のAU中にも存在する可能性があります。 これらの悪役は、 そのユニット内に存在する信頼関係を攻略することを試みる可能性があります。 メッセージは、典型的には、そのAUの境界において、 DKIM検証を経るのみなので、DKIMは、この領域において、 送信されたメッセージに対しては効果的ではありません。
例えば、その悪役は、 検証の結果を示すヘッダーフィールドを偽装することを試みる可能性があります。 このヘッダーフィールドは、通常、その検証器によって追加されます。 これは、それが検証することを試みていたメッセージ上の偽装されたヘッダーフィールドも検出します。 これは、「そのメッセージは、 うまく認証されたこと」を偽って示すために使われる可能性があります。
発信者の事例におけるように、これらの悪役は、 そのAU内のメッセージの送信を制御することによって取り扱われる可能性があります。 なぜならば、DKIMは、受信者のAU内のどこでも、検証が発生することを許容し、 これらの脅威は、MDA (Mail Delivery Agent)において、あるいは、 受信者のMUA自体上におけるように)検証(機能)を受信者に近づけることによって最小化される可能性もあるからです。
試みられている最も基本的な悪い行いのひとつは、 言い立てた発信元ドメインによって送信されたことを意図しなかったメッセージの配信です。 上述のように、これらのメッセージは、その受信者によって、 ほとんど望まれないとはされない可能性、あるいは、 信用(confidence)スキームもしくはマルウェアについての配布ベクトルの一部である可能性があります。
この種の悪い行いは、 実際の張本人のアイデンティティを不明瞭にしてしまうことを目的とするメッセージの送信を含みます。 場合によっては、実際の送信者は、悪役である可能性があり、あるいは、 他の場合において、その悪役の支配下にある第三者である可能性があります。 (例：侵されたコンピュータ)
特に、「そのドメインのオーナーが、 すべてのメッセージに署名すること」を示すSSPと組み合わされたとき、 DKIMは、悪役によって支配されていないアドレスの濫用を軽減する際に効果的である可能性があります。 DKIMは、 悪役によって支配されているアドレスの利用に対して効果的ではありません。 換言すれば、妥当なDKIM署名の存在は、「その署名者は、 悪役ではないこと」を保証しません。 これは、その署名者の説明責任も、保証しません。 なぜならば、DKIMは、署名者を個々に識別することを試みるのではなく、 彼らが支配するドメインを識別するものであるからです。 運用承認(accreditation)や評判システムと、 ローカルに維持管理されるホワイトリストやブラックリストが、 DKIM検証されたアドレスの説明可能性、かつ／または、 署名されたメッセージが渇望される確率を拡充するため使われる可能性があります。
2番目に主要な悪い行いは、 eメール中の特定のアイデンティティの言明(assertion)を含みます。
「特定のアイデンティティを含む悪い行いには、しばしば、 おそらく有効性は劣るものの、 受信者を誤誘導する『同様に見えるアイデンティティ』によって達成できるものがあること」に注意してください。 例えば、その悪役が"examp1e.com"というドメイン(注：pとeの間は、 「いち」)を制御できる場合、彼らは、 何人かの受信者に「admin＠examp1e.comからのメッセージは、本当に、 admin＠example.comからである」と納得させることができる可能性があります。 国際化ドメイン名を使う同種の攻撃は、想定されてきました。 ここでは、よくある字面における文字の相違を見つけることが、 とても困難である可能性があります。 同様に、example2.comが悪役によって制御される場合、その悪役は、 bigbank.example2.comからのメッセージに署名でき、これは、 何人かの受信者を誤誘導する可能性もあります。 「これらのドメインが悪役によって支配される」程度に応じて、DKIMは、 ユーザを識別する際に支援するために、評判システム、かつ／または、 accreditationシステムの機能をサポートできるものの、DKIMは、 これらの攻撃に対して効果的ではありません。
DKIMは、「このようなメッセージは、実際に、 署名される」という期待があるときのみ、 特定のアイデンティティの利用に対して効果的です。 これを確立するための主要な手段は、 SSP (Sender Signing Practices)の利用であり、これは、 IETF DKIM WGによって規定される予定です。
特定の発信元アドレスを言明することについての理由のひとつは、 面識があるように見えること、あるいは、 以前にやり取りをしたことがあるように見えることによって、 受信者が信頼する可能性があり、受信者に、 特定のeメールメッセージを読んで、 これに基づいてふるまうことを奨励することです。 この戦術は、 感染したホストのアドレス帳中のアドレス宛に自身をメールするeメールで広まるマルウェアによって使われてきました。 しかし、この場合、張本人のアドレスは、現実的でない可能性があるので、 DKIMは、この行為に対して防衛する際に効果的ではありません。
アドレス帳について、攻撃者によって、収集されて、 他のところからメッセージを送信するために使われる可能性もあります。 DKIMは、そのメッセージを他の場所から送信するとき、 有効な署名を取得できる発信元アドレスの範囲を制限することによって、 これらの行いを軽減する際に効果的である可能性があります。
eメールによる詐欺に関連する悪い行いは、しばしば(ただし、 いつもではありませんが)、その詐欺スキームの一部として、 他の主体の特定の発信元アドレスを使うメッセージの転送を含みます。 特定の発信元アドレスの利用は、しばしば、 その受信者を「そのメッセージは、実際に、 言い立てた張本人によって送信された」と納得させることを支援することによって、 その詐欺の成功に貢献してしまいます。
「その詐欺が依拠する成功率」あるいは「特定の発信元アドレスの利用によって拡充されている程度」に応じて、 その悪役は、 特定のアドレスを認可されていない利用から防護するために行われた、 あらゆる手段を回避する顕著な経済的動機と資源をもつ可能性があります。
署名が受信者によって検証されるとき、DKIMは、 署名されたメッセージ上の発信元アドレスの詐欺的な利用に対して防衛する際に効果的です。 発行されている発信元アドレスのSSPが「そのアドレスからのすべてのメッセージは、 署名される必要があること」を示すとき、DKIMは、さらに、 試みられた署名されていないメッセージ上の発信元アドレスの詐欺的な利用を軽減します。
メッセージ中の特定の発信元アドレスを使うことについて別の動機は、 他者の評判を害することであり、卑近に「joe-job」と呼ばれています。 例えば、商業主体は、競争相手の評判を、おそらく、その競争相手に代わって、 spam (UBE)を送信することによって、加害することを望む可能性があります。 「業務において、評判(reputation)システムは、 客観的に信頼できるアイデンティティに基づいていなければならないこと」は、 この理由によります。
何らかの悪役によって、卑近に使われている戦術は、 意図的にメッセージの宛先を誤って、 それが「バウンス(bounce)される」ようにする、あるいは、 そのメッセージ上のreturnアドレス(RFC 2821 envelopeのfromアドレス)宛への送信によるメッセージの間接的な転送です。 この場合、そのeメール中に記されている特定のアイデンティティは、 そのメッセージが「返される」メッセージの実際の標的のものです。
一般に、DKIMは、直接(「その密造されたアドレスは、 SMTPプロトコルの要素であり、 DKIMが操作するメッセージコンテンツではないこと」に注意しながら)か、 あるいは、オプションとしてのReturn-Pathヘッダーフィールドによるか、 のいずれかで、メッセージ上のRFC2821.mailfrom returnアドレスを検証することを試みません。 さらに、RFC 2821 [RFC2821] の4.4節に記されているように、起点のアドレスに応答しないことは、 メッセージのreturnパスについて、卑近かつ有用な実践です。 これらの理由によって、DKIMは、 反射(reflection)攻撃に対しては効果的ではありません。
悪役は、 すべてのメッセージ認証システムの制約を攻略することが予期される可能性があります。 また、彼らは、それらの配備を妨げるために、 そのメッセージ認証システムの有用性を低下させる動機をもつ傾向があります。 署名メカニズム自体と、 メッセージ署名(ここではSSPもしくはSender Signing Practicesと呼ばれる)の利用に関して行われる宣言(declaration)の両方は、 攻撃の標的となることが予期される可能性があります。
下表は、DKIM 署名に対して想定されている攻撃の要約です。：
| 攻撃名 | 影響 | 確率 |
|---|---|---|
| ドメインについてのプライベート鍵の盗用 | 高 | 低 |
| 代表するプライベート鍵の盗用 | 中 | 中 |
| サイドチャネル攻撃によるプライベート鍵の回復 | 高 | 低 |
| 選択されたメッセージ再生 | 低 | 中/高 |
| 署名されたメッセージ再生 | 低 | 高 |
| 検証器に対するサービス妨害攻撃 | 高 | 中 |
| 鍵サービスに対するサービス妨害攻撃 | 高 | 中 |
| Canonicalizationの濫用 | 低 | 中 |
| ボディ長制限の濫用 | 中 | 中 |
| 失効された鍵の利用 | 中 | 低 |
| 鍵サーバの侵害 | 高 | 低 |
| 鍵サービスreplyの偽装 | 中 | 中 |
| 密造された鍵レコードかつ／または署名の発行 | 高 | 低 |
| 署名生成における暗号技術的弱点 | 高 | 低 |
| 表示名の濫用 | 中 | 高 |
| 発信者のネットワーク内の侵されたシステム | 高 | 中 |
| 検証探査攻撃 | 中 | 中 |
| 上位ドメインによる鍵発行 | 高 | 低 |
DKIMのようなメッセージ署名技術は、 メッセージに署名するために使われたプライベート鍵の盗用に対して脆弱です。 これは、この盗用について、burglary、bribery、 extortion等のような「帯域外」の手段を含むと共に、 このような盗用については、 (プライベート鍵が保存されている場所の周辺のネットワークやホストのセキュリティ侵害のような)電子的な手段も含みます。
ドメイン中のすべてのアドレスについて妥当な鍵は、典型的には、 データセンタのように、 良く防護されたサイトに位置する必要があるMTAにあります。 プライベート鍵へのアクセスを最小化するために、究極的には、 メモリダンプなどは、おそらく、その鍵を含んでいますが、 それらの値を表示するためのコマンドの不存在のような様々な手段が、 採用される必要があります。 MTAの意図しなかった性格に起因して、いくつかの対策は、 (鍵を「ロック解除」するためのパスフレーズの利用のように)実践的ではありません。 プライベート鍵を含み、 暗号技術的な署名操作を行う専用のハードウェア・デバイスの利用のような他のメカニズムは、 そのデバイスに物理的にアクセスする権限が無い者に対するプライベート鍵のエクスポートを拒絶する際に、とても効果的です。 このようなデバイスは、それが起きた場合、 適切な行動(対応する公開鍵の失効)がとれるように、 ほぼ確実に鍵の盗用を認識可能とします。
ドメインのオーナーが、そのドメインについて、 個々のユーザもしくは第三者に対して、 企業の福利厚生の運用管理者もしくはマーケッティングのキャンペーンのようなアウトソースされた活動と関連するメッセージに署名する能力を低下させることを望むような、 いくつかの状況があります。 これらの鍵は、そのドメイン自体のMTAではなく、 あまりよく防護されていないデバイス上に存在する可能性があるので、 それらは、多くの場合、侵されることが、より疑われます。
この露出を軽減するための、 このようなメッセージに署名するために使われる鍵は、 そのドメインのオーナーによって、 ドメイン中の特定のアドレスの代わりのみ、 メッセージ署名が有効となるように制限される可能性があります。 これは、そのドメイン中のアドレスの大多数のための防護を維持管理します。
関連する脅威は、その代表するプロセス自体の中の弱点の攻略です。 この脅威は、プライベート鍵の盗用と、 転送中の公開鍵の偽装に対するcustomary precautionsの利用を通じて軽減される可能性があります。 例えば、盗用される露出は、 そのdelegateが使われる予定の鍵ペアを生成する場合、 最小化される可能性があり、 その公開鍵をそのドメインのオーナー宛に送信します。 偽造(異なる公開鍵の送信)のための露出は、この転送が、 その代表によって署名され、 そのドメインのオーナーによって検証される場合、 低減される可能性があります。
すべての有名なデジタル署名アルゴリズムは、 様々なサイドチャネル攻撃の対象となります。 これらのうち、最も良く知られているものは、 タイミングチャネル [Kocher96]、 電力解析 [Kocher99]、 キャッシュ・タイミング解析 [Bernstein04] です。 これらの攻撃の大部分は、そのマシンに対する物理的アクセスか、あるいは、 プロセスを直接、その標的マシン上で走らせる能力のいずれかを要します。 これらの攻撃に対する防衛は、DKIMにとって、範囲外です。
しかし、リモートタイミング解析は、(少なくとも、LAN上では、)特に、 その攻撃者が、 すぐに問題となっている暗号技術的操作の対象となるトラフィックを注入できる場合、 サーバ型のプラットフォームにおいて実行可能であること知られています。 [Boneh03] 十分なサンプルがあれば、 これらのテクニックは、そのタイミング計測において、 多くはないノイズに直面した際に、 プライベート鍵を取り出すためにさえ使われる可能性があります。
タイミング解析に対して、提案されている3つの卑近な対策は、次のとおり。：
「この操作にとって、乱雑な遅延の追加は、 部分的な対策に過ぎないこと」に注意してください。 そのノイズは、一般に、一律に分布しているので、 十分な数のサンプルが、平均化し、 正確なタイミング信号を取り出すために使われる可能性があります。
選択されたメッセージの再生は、攻撃者がメッセージを作成し、 それを発信元のドメインによって自身もしくは共犯者(accomplice)宛に認可されたMTAを通じて送信することによって、 それについての署名を入手するようなシナリオを言います。 攻撃者は、次に、異なるenvelopeアドレスを使って、(典型的には、 多数の)他の受信者宛に、それを送信することによって、 その署名されたメッセージを「再生」します。
攻撃者が生成したメッセージが署名されるようにする要件に起因して、 選択されたメッセージ再生は、最も卑近には、顧客ISP、もしくは、 eメール・アカウントをクライアントに提示する他者によって、試行されます。 (特に、そのアカウントの保持者(この場合における攻撃者)に対する説明責任が、 ほとんど無い場合、あるいは、まったくない場合。) この問題を解決するためのひとつアプローチは、「濫用が発生した際に、 そのドメインが、 メッセージの発信者の追跡可能性を提供するための診断の過程を経たクライアントについてのeメールのみに署名すること」です。 現在、eメール・アカウントの低コスト(無償)は、 いかなる診察(vetting)についても、 発生することを実践的なものとはしません。 「これは、 署名されたメールについてのモデルでもあるか否か？」あるいは「より高いレベルの信頼(trust)が、 eメール署名を得るために要求されているか否か？」を見守ることになります。
この攻撃についての変形(variation)は、 それらの原本のメッセージを含む署名されたreplyを入手する意図でメッセージを送信する攻撃者を含みます。 その返答は、悪意の無いユーザから来る可能性があり、あるいは、 「ユーザunknown」bounceメッセージのような自動的な応答である可能性があります。 場合によっては、この署名されたreplyメッセージは、再生された場合、 その攻撃者の目的を達成する可能性があります。 この「選択されたメッセージの再生」についての変形については、 原本のコンテンツが自動的replyにおいて引用されている程度の制限、および、 出方向のコンテンツフィルタリングのような相補的(complementary)メカニズムの利用によって、 軽減される可能性があります。
署名の失効、もしくは、関連づけられた鍵の失効は、潜在的な対策です。 しかし、そのメッセージが再生される可能性がある速いペースは、(特に、 「ゾンビ(zombie)」コンピュータの軍隊と共にあるとき)攻撃を検知し、 失効させるために要する時間と比べて、問題を引き起こしがちです。 関連する問題のひとつは、 「ドメインが、 多数の顧客についての少数の署名用の鍵を使うこと」の確率です。 これは、キャッシングの観点からは、有効ですが、万一、鍵が突然、 失効された場合、 大量の同時多発被害を(署名検証の失敗の形態で)もたらす傾向があります。
署名失効は、顕著な規模拡大(scaling)要件への支出の際に、 同時多発被害の問題に対応します。 究極的には、検証器は、 検証された各署名の失効についてチェックすることが要求される可能性があります。 これは、とても顕著なトランザクション頻度をもたらします。 代替案として、「失効識別子」が提案されてきました。 これは、中程度の粒度で(おそらく、 これらの識別子を含むアカウント単位で)失効を許容します。 メッセージは、 DNS中に表現される可能性がある失効データベースに対する問い合わせに帰結します。
「(一定の再生攻撃の潜在的な速度のもとで)失効からの便益は、 失効データベースに問い合わせるトランザクションのコストを上回るか否か？」を判定するために、 さらなる調査が必要とされます。
署名されたメッセージ再生とは、 「既に署名されたメッセージの張本人もしくはそのメッセージの当初の送信者によって意図された者以外の追加的な受信者宛の転送」を言います。 攻撃者は、メッセージをその被害者から受信するように調整し、次に、 そのまま再転送します。 (ただし、異なるenvelopeアドレスをもちます。) これは、例えば、「メッセージの正規の送信者が、 大量のspamを送信している」ように見えるようにするために行われる可能性があります。 評判サービスが配備されているとき、これは、その張本人の評判、もしくは、 その張本人のドメインの評判に被害を与える可能性があります。
多数のドメインは、選択されたメッセージ再生よりも、 署名されたメッセージ再生の潜在的な被害者です。 なぜならば、前者は、攻撃者に、 被害者のドメインからメッセージを送信する能力を要しないからです。 しかし、その攻撃者の能力は、より低くなります。 ボディ長制限の濫用のような別の攻撃と組み合わされない限り、 その攻撃者にとって、例えば、これを広告用に使うことは、不可能です。
多くのメーリングリスト(特に、 そのメッセージや署名されたヘッダーフィールドのコンテンツを改変しないもの、 かつ、それゆえ、その署名を無効にしないもの)は、 署名されたメッセージ再生の形態に加担します。 メッセージの存続性を伸ばすためのボディ長制限や他のメカニズムの利用は、 そのように行う能力を効果的に拡充します。 この場合を、 望まれない形態の署名されたメッセージ再生から区別する唯一の事項は、 そのネットワークによっては判定できない、その再生者の意図です。
署名し、検証するためには、いくらかの計算資源を要しますが、これは、 不正な署名を生成するために、かなりの(negligible)計算資源を要します。 攻撃者は、それゆえ、「不急不要(make work)」攻撃を検証器に対して、 大量の不正に署名されたメッセージを(おそらく各々、 複数の署名をもつ)所与の検証器宛にを送信することによって、 行う可能性があります。 その動機は、 メッセージを検証することを割が合わないものとすることである可能性があります。
この攻撃は、実行可能ですが、検証器を運用する作法によって、 大いに軽減される可能性があります。 例えば、これは、メッセージあたり特定数の署名のみを受容するために判定し、 (乱暴なまでに大きな署名が不要な作用をもたらすことを防ぐために)受容する最大の鍵の大きさを制限する署名を特定の順に検証する可能性があります。 その検証器は、攻撃が進行中である可能性があるとき、 現在の署名検証の失敗率を反映して保守的な想定を採用する状態を維持管理する可能性もあります。
攻撃者は、その発信者のメッセージを検証不能にするために、 発信者の鍵サービスの能力を低下させることを試みる可能性もあります。 これを行うためのひとつの方法は、 特定の鍵を参照する署名をもつ大量のメッセージを機敏に送信することであり、 それによって、その鍵サーバ上に重い負荷をかける可能性があります。 鍵サーバ、もしくは、 それを提供するネットワーク・インフラストラクチャ上の他の種類のDoS攻撃も、 可能です。
この攻撃に対する最善の防護は、できれば、 インターネットの地理的に離れた部分に冗長な(redundant)鍵サーバを提供することです。 キャッシングも、 信じるべき(authoritative)鍵サーバ上の負荷を減少させることによって、 同時に多くの鍵リクエストがあるとき、大いに役に立ちます。 鍵lookupのトランザクションのコストを最小化する鍵サービスプロトコルの利用も、 有益です。 「DNS (Domain Name System)は、 これらすべての特徴をもつこと」が注記されます。
Canonicalizationアルゴリズムは、メッセージ署名の妥当性の存続と、 そのメッセージが不適切に変更されることを許可しない渇望の間にトレードオフ(二律背反)をもたらします。 かつて、場合によって、 攻撃者がメッセージの意味を改変することを許容してしまうようなcanonicalizationアルゴリズムが、提案されていました。
複数のcanonicalizationアルゴリズムをサポートするメッセージ署名は、 その署名者に署名の存続性の相対的重要性と、 その署名されたコンテンツの不変性(immutability)を判断する能力を与えます。 予期されなかった脆弱性が、 一般用途のcanonicalizationアルゴリズム中に現れる場合、その署名者は、 「どのアルゴリズムを、その検証器は、サポートしているか？」について、 決して確信をもてないので、遅いプロセスにはなりますが、 新しいアルゴリズムが配備される可能性があります。 この理由によって、canonicalizationアルゴリズムは、 (暗号アルゴリズムのように)広範かつ慎重なレビュープロセスを経る必要があります。
ボディ長制限は、 「どれくらい多くの内容が署名されたか？」についての署名者からのオプションとしての表示法のひとつです。 その検証器には、「その制限を無視する」か、 「そのメッセージの仕様とされている部分を検証する」か、あるいは、 「そのメッセージを規定された部分に短縮し、それを検証する」か、 のいずれかの可能性があります。 この機能についての動機は、トレーラー(おそらく、 そのリストを識別するもの)をメッセージの最後に追加する多くのメーリングリストのふるまいです。
ボディ長制限が使われているとき、攻撃者には、 コンテンツをそのメッセージに追加する潜在的可能性があります。 「このコンテンツは、最後にありながら、特にHTMLメッセージの場合、 望まれるコンテンツを覆うことができること」が示されてきました。
そのボディ長が規定されていない場合、あるいは、 その検証器がその制限を無視することを判断する場合、ボディ長制限は、 実際は無意味(moot)です。 その検証器もしくは受信者が、そのメッセージを、 署名されたコンテンツにおいて切り詰める場合、 その攻撃者が何かを加える機会はありません。
その検証器がボディ長の制限(があるとき、それ)を観察する場合、 「攻撃者は、 望まれないコンテンツを受信者に対して可視化できる」という潜在性があります。 その追加されたコンテンツの大きさは、大差ありません。 なぜならば、これは、単に、 実際のコンテンツを指すURL参照である可能性があるからです。 受信するMUAは、この脅威を、少なくとも、 そのメッセージ中の署名されていないコンテンツを識別することによって軽減できます。
鍵レコードのキャッシングによって得られた便益は、「失効された鍵は、 それらの失効後の一定期間、使われる可能性があること」の可能性を開きます。 この最善の例は、そのドメインの運用管理者によって代表される鍵の保持者が、 予期せず、ドメイン中のひとつ、もしくは、 複数のアドレスに代わってメールを送信する認可を取り消さなければならないとき、 発生します。
鍵レコードのキャッシングは、通常、短命であり、 数時間から数日間の範囲になります。 多くの場合、この脅威は、単に、 そのドメイン運用管理者の直接管理下にない鍵について、 (当然ながら、「TTL値の制御は、DNSと共にできる限り、 各レコードについて規定される可能性がある」と想定して)短いTTL (time-to-live)を設定することによって軽減される可能性があります。 場合によっては、 そのドメインのMTAのひとつに属する盗まれたプライベート鍵に従った回復のように、 盗用の可能性と、その鍵の認可を失効させるために要求される労力は、 TTLを選択するとき、考慮されなければなりません。 選択されたTTLは、 サービス妨害攻撃を軽減するために十分に長くなければならず、 合理的なトランザクションの効率を提供しなければなりませんが、 もはや提供できません。
攻撃者は、プライベート鍵の入手を試みることによるよりも、代わりに、 ドメインについての公開鍵を発行するために使われるサーバに注力する可能性があります。 鍵の盗用の事例におけるように、その動機は、 攻撃者がそのドメインの代わりに、 メッセージに署名できるようにすることである可能性があります。 この攻撃は、攻撃者に正規の鍵を発行から除去する追加的な能力を提供し、 これによって、 そのメール上の署名について正しく検証するドメインの能力を否定します。
署名するドメインのオーナーによって認可された主体宛のメッセージに署名する能力を制限するために、 関係は、その署名するアドレスと、 そのメッセージを検証するための公開鍵の入手元の場所との間に確立されなければなりません。 DKIMは、その公開鍵か、あるいは、署名するドメインのDNS階層中の、 それに対する参照のいずれかを発行することによって、これを行います。 その検証器は、 署名するアドレスもしくはドメインからの公開鍵が取得される場所を導きます。 それゆえ、検証プロセスのセキュリティは、 署名するドメインについてのDNS階層のセキュリティに依存します。
攻撃者は、(そのドメインのDNS masterサーバのように)署名を行うドメインのための主要な鍵サーバであるホストを、 うまく侵してしまう可能性があります。 別のアプローチは、上位のDNSサーバを侵し、 その署名するドメインについてのネームサーバの代表を、 攻撃者の制御下の他のものに変更することである可能性があります。
この攻撃は、鍵サービスを監査するための独立した監視によって、ある程度、 軽減される可能性があります。 このような鍵サービスの監査は、 そのゾーンへのレコードの追加が検知できるように、 そのゾーンのプライマリ・サーバへの問い合わせではなく、 ゾーン転送の手段によって行われる必要があります。
鍵サービスからの応答も、 適切に想定された攻撃者によって偽装される可能性があります。 DNSについて、これを行うための方法のひとつは、 「キャッシュ毒盛り」であり、ここでは、攻撃者は、DNS replyにおいて、 キャッシュされる不要(かつ不正な)追加的な情報を提供します。
DNSSEC [RFC4033] は、 この脅威を軽減するために選好される手段ですが、 現在のDNSSECについての配備の進捗は、十分に遅いので、その配備について、 依存性をもつようにすることを好まない者もいるでしょう。 キャッシュ毒盛り(poisoning)攻撃の場合、 この攻撃によってつくられる状況は、 比較的長いTTLをもつレコードは、 この攻撃自体以外にも存在する可能性がありますが、ローカライズされ、 かつ、持続期間(duration)を制限されています。
この攻撃において、攻撃者は、検証器を混乱させ、 おそらく検証をすべて不能にする試みにおいて、 適切に作成された鍵レコードを発行するか、あるいは、 意図的に密造された署名をもつメールを送信します。 この攻撃は、実際に、例えば、署名メカニズム自体の脆弱性というよりも、 実装上の脆弱性(バッファ・オーバーフローあるいは範囲チェックの欠如)の特徴です。 この脅威は、注意深い実装と、 検証プロセスを試行するテスト・スィートの開発によって、最も軽減されます。
メール署名を生成するため(具体的には、ハッシュアルゴリズム、 デジタル署名生成および検証操作)に使われる暗号アルゴリズムは、常に、 それらのセキュリティを劣化させる数学的テクニックの対象となる可能性があります。 この執筆時点において、SHA-1ハッシュ・アルゴリズムは、 extensive数学的分析の対象であり、これは、 同一のハッシュ値をもつ2つのメッセージを作成するために要する時間を、 かなり短縮してきました。 この趨勢(trend)が続くことは、予想できます。
ハッシュ・アルゴリズムにある弱点のひとつの帰結は、ハッシュ衝突攻撃です。 メッセージ署名システムにおけるハッシュ衝突攻撃は、同一人物を含めて、 同一のハッシュ値をもつ2つの異なるメッセージを作り出し、ここでは、 通常、2つのメッセージの一方のみが署名されます。 その攻撃は、最初の署名に由来する2番目のメッセージに基づきます。 DKIMについて、これは、「送信者は、 『良い』メッセージと『「悪い』メッセージを作成する可能性があること」を意味します。 ここで、署名する主体のサイトにあるフィルタには、 「良い」メッセージに署名しても、 「悪い」メッセージには署名しないものがあります。 その攻撃者は、「良い」署名されたメッセージを得て、次に、 その署名を「悪い」メッセージ中に組み込みます。 このシナリオは、卑近ではありませんが、例えば、メッセージについて、 それらに署名する前に一定の分析を行うサイトにおいて発生する可能性があります。
現在、知られているSHA-1に対する攻撃では、 この攻撃を放つのは極めて困難ですが、攻撃法が改良され、計算能力が、 より卑近に利用可能になるに従って、このような攻撃は、 達成可能となる可能性があります。
そのメッセージ署名システムは、 複数の署名アルゴリズムやハッシュ・アルゴリズムをサポートするように設計されなければならず、 また、署名するドメインは、 「どのアルゴリズムをメッセージに署名するために使うか？」を規定できなければなりません。 アルゴリズムの選択は、「攻撃者は、署名を、 そのドメインが許可しようと望んでいるよりも弱いアルゴリズムを使って作成できないこと」を確保するために、 その署名自体の中にみならず、 鍵レコード中にも発行されなければなりません。
eメールの署名者と検証器は、一般に、 直接にはやりとり(communicate)しないので、 署名用に使われるアルゴリズムの交渉は、起こりえません。 換言すれば、署名者は、「どのアルゴリズムを検証器が、 サポートしているか？」あるいは「(メール転送に起因して)どこに、 その検証器があるか？」を知るすべをもちません。 この理由によって、「ひとたびメッセージ署名が、広く配備されると、 アルゴリズム変更は、ゆっくり起こること」が期待され、 古い(legacy)アルゴリズムは、相当な期間、サポートされる必要があります。 それゆえ、メッセージ署名のために使われるアルゴリズムは、今後、 数年間に予期される暗号技術的な進展に対してセキュアである必要があります。
メッセージ署名は、 eメール・アドレスのアドレス仕様の部分にのみ関連する一方、MUAには、 そのアドレスの表示名部分のみを表示するものがあります。 (あるいは、受信者には、その部分のみに注意をはらう者がいます。) この不整合は、 攻撃者が下記のようなFromヘッダーフィールドを使う攻撃をもたらします。：
From: "Dudley DoRight" <whiplash＠example.org>
この例において、攻撃者(whiplash@example.org)は、なおも、 そのメッセージに署名でき、「そのメッセージは、 信頼される人物であると想定できるDudley DoRightからのものである」と、 何人かの受信者を納得させます。 throw-awayドメイン、もしくは、eメールアドレスの利用と組み合わされると、 その攻撃者を「別の表示名を使うこと」について説明可能に保つことは、 困難である可能性があります。
これは、受信者のMUAにおいて扱われなければならない攻撃です。 ひとつのアプローチは、 「署名者のアドレス仕様(かつ単なる表示名ではないもの)が、 受信者に対して認識可能になるようにすること」を要求することです。
多くの場合、MTAは、 発信者のネットワークのトポロジ的境界内(すなわち、 ファイアウォール内)に起点をもつメッセージを受容し、 署名をするように設定される可能性があります。 eメールを送信するために侵されたシステムの増加しつつある利用は、 このようなポリシーについて問題をもたらします。 なぜならば、攻撃者は、 (侵されたシステムをプロキシとして使って)署名されたメールを思いのままに生成できるからです。
いくつかのアプローチが、この攻撃を軽減するために存在します。 (ネットワーク境界の内側でさえ)認証された送信の利用は、 その攻撃者が署名を入手する可能性があるアドレスを制限するために使われる可能性があります。 これは、そのメッセージの起点となっている侵されたシステムを、 より迅速に同定するために役立つ可能性もあります。 望まない、かつ、 悪意あるコンテンツを識別するための出ていくメールのコンテンツ分析は、 ユーザによって送信されるメッセージの量の監視と共に、 任意のメッセージが署名・送信されることを防ぐ可能性もあります。
上記のように、悪役(攻撃者)は、 彼らが支配(control)するドメインに代わってメッセージに署名できます。 彼らは、 その鍵サービス(例：そのドメイン鍵のサブドメイン用の信じるべき(authoritative) DNSネームサーバ)も制御する可能性もあるので、 メッセージが検証されたとき、彼らは、公開鍵のlookupと、 その源泉を観察することが可能です。
我々が「検証探査(verification probe)」と呼ぶそのような攻撃のひとつは、 DKIM署名をもつメッセージをメーリングリスト中の多くのアドレスの各々宛に送信することです。 そのメッセージは、妥当な署名を含む必要はなく、各メッセージの事例は、 典型的には、異なるselectorを使います。 そして、その攻撃者は、鍵サービスのリクエストを監視でき、 「どのセレクタが、アクセスされたか？」を判断でき、 これに対応して「どのアドレスが、DKIM検証を使ったか？」を判断できます。 これは、「これらのアドレスは、 そのメッセージコンテンツ上で役割をもつ可能性が高い」という前提でDKIM検証(verification)を使わない受信者における将来のメール処理を標的とするために使われる可能性があります。
ドメインの運用管理的コントロールのもとで、 サブドメインについて署名する能力をサポートするために、DKIMは、 署名のドメイン(d=tag)がその署名のアドレス(i=もしくは同等)より上位の、 いかなるドメインとなることも許可します。 しかし、サブドメインの共通の運用管理的コントロールを判定するためのメカニズムは無いので、 親がDNS階層におけるそれらの下のあらゆるドメインについて妥当な鍵を発行することが可能です。 換言すれば、ドメインexample.anytown.ny.usからのメールは、 そのドメイン自体に加えて、anytown.ny.us, ny.usもしくはusによって発行された鍵を使って署名される可能性があります。
ドメインの運営は、常に、上位ドメインとの信頼関係を要求します。 上位ドメインは、既に、それらのサブドメインに対して、 究極のパワーをもっています。： 彼らは、そのドメインについて、 ネームサーバの代表(delegation)を変更すること、あるいは、 それを完全に剥奪(disenfranchise)できます。 したがって、「上位ドメインが意図的に、 この作法でサブドメインを侵すこと」は、ありそうにありません。 しかし、上位ドメインが彼らの代わりにメールを送る場合、上位ドメインは、 鍵を彼ら自身のレベルで発行することを望む可能性があります。 高位のドメインは、「彼らのいかなるサブドメインも、 このような鍵の濫用にいって侵されていないこと」を確保するために、 彼らが発行する鍵の代理の際には、特別な注意を払わねばなりません。
下表は、署名業務に対して想定される攻撃の要約です。：
| 攻撃名 | 影響 | 確率(Likelihood) |
|---|---|---|
| 同様に見えるドメイン名 | 高 | 高 |
| 国際化ドメイン名の濫用 | 高 | 高 |
| 署名業務に対するサービス妨害攻撃 | 中 | 中 |
| 複数のFromアドレスの利用 | 低 | 中 |
| 第三者署名の濫用 | 中 | 高 |
| SSP replyの偽装 | 中 | 中 |
攻撃者は、よく似たドメイン名を使うことによって、 ドメインの署名業務を回避することを試みる可能性がありますが、 署名業務をもつドメインと同様ではありません。 (例："example.com"は、 "examp1e.com"によって置き換えられる可能性があります。) そのメッセージが署名されていない場合、(他のメカニズムは、 これを要件とする可能性がありますが、) DKIMは、 「使われているドメインが実際に存在すること」を要求しません。 潜在的なドメイン名の濫用を識別するためにドメイン登録を監視するサービスが存在しますが、 そのままでは、登録されていないドメイン名の利用を識別しません。
関連した攻撃は、 そのMUAがそのドメイン名を容易に理解可能なフォーマットで与えないとき、 可能です。 例えば、 中国のドメイン名がxn--cjsp26b3obxw7f.comのように"punycode"でレンダされた場合、 その表現の見慣れなさ(unfamiliarity)は、 他のドメインが期待されたドメインとして、 より容易に誤解させることができるようにする可能性があります。
インターネットにおけるドメイン名の慣行に馴染みのないユーザも、 ある(certain)名前を誤認する可能性があります。 例えば、ユーザは、 online.example.comとonline-example.comを混同する可能性があり、 後者は、攻撃者によって登録されてきました。
国際化ドメイン名は、 上記の「同様に見える(look-alike)ドメイン名攻撃」の特別な事例をもたらします。 多くのUnicodeキャラクタの外観における類似性に起因して、ドメイン(特に、 異なるグループから文字列を導き出すドメイン)が作られる可能性があり、 それは、外見からは他と判別不能です。 (おそらく、高い値のドメイン)これは、 Unicode Technical Report 36 [UTR36] において詳細に検討されています。
ドメイン登録レコードについての調査は、 このようなことのいくつかを指摘する可能性がありますが、 多くのそのような類似性があります。 上記の同様に見えるドメイン攻撃におけるように、このテクニックは、 他のドメインのSSPを回避するために使われる可能性もあります。
ちょうど「ドメインによる公開鍵の発行が攻撃者によって影響を受ける可能性がある」ように、 ドメインによるSSP (Sender Signing Practices)の発行も、 影響を受ける可能性があります。 SSPの場合、 そのドメインから来たと主張する大量の署名されていないメールの転送は、 そのSSPレコードを要求する重いトランザクション負荷をもたらす可能性があります。 そのSSPレコードを提供しているサーバに対して、 より一般的なDoS攻撃も、可能です。 これは、特別な関心事です。 なぜならば、そのデフォルト署名業務は、「我々は、 すべてには署名しない」であり、これは、 「SSPの失敗は、よりSSPに用心する検証器の失敗をもたらすこと」を意味するからです。
鍵サーバについてのDoS攻撃に対する防衛と同様に、 この攻撃に対する最善の防衛は、 冗長な(redundant)サーバを提供することであり、できれば、 インターネットの地理的に離れた箇所において提供することです。 キャッシングは、ここでも大いに役立ち、署名業務は、 ほとんど変更されない必要があり、それゆえ、TTL 値は、比較的、 大きい可能性があります。
この用法は、大部分の受信者には決して見られませんが、 RFC 2822 [RFC2822] は、 Fromアドレスが複数のアドレス仕様を含むことを許容しています。 SSPのlookupは、そのFromアドレスに基づいているので、 複数のドメインからのアドレスがそのFromアドレス中にある場合、 「どの署名業務を使うか？」の問題が浮上します。 ルール (例：「最初のアドレスを使う」)が規定される可能性がありますが、 そのとき、攻撃者は、 高い値のドメインのアドレスの前に使い捨ての(throwaway)アドレスを置く可能性があります。 SSPについては、 すべてのアドレスを見るための最も制約的なルールを選択することも、 可能です。 これは、さらなる調査が必要とされる領域です。
(メーリングリスト、 イベント開催案内および「この文章を友達に送って」というサービスを含む)多くの状況において、 メッセージ上のDKIM署名は、 その発信元アドレスのドメインから来ない可能性があります。 この理由によって、(メーリングリスト、 招待状サービスもしくはニュースサービスになされる)「第三者」署名は、 しばしば、何らかの有効性をもつと見なされる必要があります。 これは、効果的に、あらゆるドメインが、 あらゆるメッセージに署名できるようにするので、送信するドメインは、 「これは、このようなサービスを使いません」と記述されたSSPを発行する可能性があります。 したがって、その検証器は、このような署名を懐疑的に見る必要があります。
しかし、 「非第三者」署名業務を発行することによってドメインにおかれた制約は、 効果的に、eメールの多くの既存の利用法を不許可とします。 これらの実践を採用することができないドメインの大多数について、 攻撃者は、(一定の成功確率で)そのドメインから来たというメッセージに署名する可能性があります。 この理由によって、accreditationサービスや評判サービスは、 ローカルに維持管理されたホワイトリストおよびブラックリストと共に、 第三者によって署名されたメッセージを評価する際に、 顕著な役割を果たす必要があります。
4.1.12節に記述した鍵サービスreplyの偽装と類似する作法でSSP queryに対するreplyは、偽造される可能性もあります。 このような攻撃のひとつは、 あるドメインから言い立てられた署名されていないメッセージが、 あまり怪しく見えないようにするために、その署名業務を弱めることです。 メッセージに署名していない被害ドメイン上の別の攻撃では、 被害者のメールを送信する能力に干渉するために、ドメインのメッセージを、 より怪しく見えるようにすることを試みる可能性があります。
鍵サービスreplyの偽装についてと同様に、DNSSECは、 この攻撃を軽減するために選好される手段です。 たとえDNSSECが無くても、 キャッシュ毒盛り(poisoning)に起因する脆弱性は、 局地化(localize)されます。
この節は、 DKIMの配備によって可能とされる他のインターネット・インフラストラクチャに対する攻撃について記述します。 これらの想定される攻撃の要約は、下表のとおりです。：
| 攻撃名 | 影響 | 確率(Likelihood) |
|---|---|---|
| DNS経由のパケット増幅(amplification)攻撃 | N/A | 中 |
最近、偽装されたUDP DNSリクエストのオープンにアクセス可能なドメインネームサーバ宛の転送を含むサービス妨害攻撃 [US-CERT-DNS] が増加し続けてきました。 「ネームサーバからの応答(response)が、 そのリクエストよりも大きくなる」に従って、そのネームサーバ機能は、 そのような攻撃についての増幅器となります。
DKIMは、間接的に、公開鍵を配布するために、 かなり大きなDNSレコードの発行を要求することによって、 この攻撃に貢献してしまいます。 これらのレコードの名前も、「well known」です。 なぜならば、そのrecord namesは、 正しく署名されたメッセージを試験することによって決定される可能性があるからです。 この攻撃は、DKIM自体に影響を与えません。 しかし、DKIMは、 大きなDNSレコードを使う唯一のアプリケーションではありませんし、 この問題については、DNSに基づく解決策が要求される傾向があります。
この節では、 上記の検討において明記されていないDKIMについての要件を掲げます。 これらの要件は、次の事項を含みます。：
本書は、セキュリティの脅威環境について記述しており、この中で、 DKIM (Domainkeys Identified Mail)には、何らかの便益を提供することと、 その配備に関連する数多くの攻撃を示すことが期待されています。
| [Bernstein04] |
Bernstein, D., "Cache Timing Attacks on 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", 作業中, 2006年8月. |
| [DKIM-SSP] |
Allman, E., "DKIM Sender Signing Practices", 作業中, 2006年8月. |
| [Kocher96] |
Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, and other Cryptosystems", Advances in Cryptology, pages 104-113, 1996年. |
| [Kocher99] |
Kocher, P., Joffe, J., and B. Yun, "Differential Power Analysis: Leaking Secrets", Crypto '99, pages 388-397, 1999年. |
| [RFC1939] |
Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, 1996年5月. |
| [RFC2821] |
Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2001年4月. |
| [RFC2822] |
Resnick, P., "Internet Message Format", RFC 2822, 2001年4月. |
| [RFC3501] |
Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, 2003年3月. |
| [RFC4033] |
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033 (English), 2005年3月. |
| [US-CERT-DNS] |
US-CERT, "The Continuing Denial of Service Threat Posed by DNS Recursion".(PDF) |
| [UTR36] |
Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", UTR 36, 2005年7月. |
著者は、本書の初期の版について、 価値ある示唆や建設的な批判をしてくださった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およびietf-dkim メーリングリスト上の無数の他の方々に感謝しています。
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
電話：+1 408 526 5914
EMail：fenton＠cisco.com
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
EMail：miyakawa＠ipa.go.jp
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.
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.
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.
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).