|
Network Working Group Request for Comments： 5016 分類： 情報提供 |
M. Thomas Cisco Systems 2007年10月 |
このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
DKIM(DomainKeys Identified Mail)は、 ドメインが扱うメッセージについての責任を言明するための暗号技術的メカニズムを提供します。 関連するメカニズムは、運用管理者が彼らのDKIM署名業務について、 様々な言明を発行できるようにします。 本書は、このメカニズムについて、 満たされなければならない(MUST)ものと、 強く必要(SHOULD)なものを区別しながら要件を規定します。
DKIM (DomainKeys Identified Mail) [RFC4871] は、 eメール用のメッセージレベルの署名・検証メカニズムを規定しています。 DKIM署名されたメッセージ自体は、有用ですが、 メッセージが有効な当事者署名(すなわち、 [RFC2822] .Fromアドレスの代わり)をもたない場合、曖昧さがあります。： eメールについては、 「これは、期待されるべきものであるか否か？」は、特に困難な問題です。 なぜならば、ドメインの業務を送信することについて、 事前の知識としての期待が無いからです。 この曖昧さは、 オプションとしての認証を許容するeメールのようなシステムについて不可避な「bid down攻撃」を放つために使われる可能性があります。： 受信者が知らない場合、「有効な署名の欠如は、 他の情報無しには例外的である」と想定してはいけません。 それゆえ、攻撃者は、その曖昧さを利用することができ、単に署名しません。 プロトコルが、あるドメインについて、 そのDKIM署名業務を発行するように開発される可能性がある場合、 メッセージ検証器は、それが署名されていないeメールを受信するとき、 考慮する可能性があります。
本書は、SSP (Sender Signing Practices)を発行できるようにメカニズムについての要件を規定します。 本書は、2つの主要な章から成ります。： ひとつめは、「SSPは、 基本問題の周囲にある配備の論点にも対応することが意図された」という問題を記述する問題と配備シナリオの章であり、 ふたつめの章は、それらのシナリオに起因する要件です。
本書中の"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"というキーワードは、 RFC 2119 [RFC2119] 中に記述されているように解釈されるべきものです。
電子メールの世界は、配備について、 多くの考慮事項を伴う敵意がある場所です。 この章では、「どこでDKIM署名／検証は、行われるか？」と、 「どのように新しいプロトコルは、 DKIM署名されたメールの今日的意味(relevance)を明確化するために役立つ可能性があるか？」について、 予期される用法のシナリオを概説します。
ドメインから出ていくメールを監査し、 DKIM署名機能を正規の出ていくメールのすべてについて配備した後、 ドメインは、「DKIM署名を完了した」と言えます。 すなわち、そのドメインは、 (その能力の最善をつくして)「そのドメインから来たように見せかけているすべての正規のメールは、 有効なDKIM署名を含むこと」を確認しました。
このような一般的な事例において、受信者は、「どの『業務』が、 所与のドメインについてか？」を知りません。 それゆえ、その受信者は、「すべてのメールについて、 所与のドメインから署名されることが期待される必要があるか否か？」を知らない不利な状況にあります。 この知識ギャップは、卑近に攻略可能な「bid-down攻撃」をもたらします。 この攻撃では、攻撃者は、めったに署名されていないメールを送信しません。； なぜならば、その受信者は、 その署名されていないドメインの「業務」を知らないので、 有効な署名の欠如について、もはや厳しくメッセージを扱えないからです。
有効な当事者署名が見つからないとき、受信者が、 その当事者ドメインの「業務」と「期待」について、 問い合わせることができるようにする情報サービスは、 このギャップを埋める際に有用である可能性があります。 受信者は、この情報を、様々な程度の先入観をもって、 このような疑わしいメールを扱うために使う可能性があります。
「近い将来、メールの制限されていない利用パターン(例：ユーザが、 メーリングリストのメンバである可能性がある場合、等)は、時々、 転送中の悪意が無い署名失敗をわずらう傾向にあること」に注意してください。 おそらく、総トラフィックの大きな比率は占めませんが、 この種の破損(breakage)は、 そのような利用パターンについての顕著な関心事である可能性があります。 このシナリオは、送信者が、「個々のメッセージは、 無傷で到来するか否か？」に関する「期待」を設定できない場合を規定します。
たとえ期待が無いときでも、受信者は、「そのドメインの『業務』は、 すべてのメールに署名し、署名されていない、あるいは、 損傷した転送中のメールに対して、 そのフィルタを歪める」という知識を利用する可能性があります。 この情報は、2値の正否で使われると期待されてはいけません。 代わりに、フィルタリングシステムに他のものがある中のデータポイントとして期待される必要があります。
下記のやりとりは、問題シナリオ1を表現しています。
価値あるドメインからのトランザクションとしてのメールによって象徴される類のメールは、 現在、phishing攻撃の標的です。 特に、多くのphishing詐欺は、そのコンテンツの多くに細工して、 疑わないユーザを騙し(spoofing)て、 取扱に注意を要する(sensitive)情報を明かすようにしてしまうことに加えて、 [RFC2822] .Fromアドレスも偽装します。 このメールを送っているドメイン保持者は、 その能力が「彼らのドメイン名と共に送られたメールは、常に、 『そのドメイン保持者は、 その転送に同意したこと』の証明と共に到着する必要がある」という拡充された保証を与えること望みます。 すなわち、そのメッセージは、上記に定義したように、 有効な当事者署名を含む必要があります。
受信者の観点から、「ドメインは、そのメールのすべてに署名するのみならず、 そのドメインからの有効な当事者署名の受領を重視していること」を知っていることは、 有用です。 それゆえ、受信者は、「その送信しているドメインは、 そのすべてのメールに署名すること」を知っており、 「その署名するドメインは、 ある観点からは特に注意を要するドメインからのメールと見なし、 当事者署名が壊れていたり、あるいは無かったりする可能性があるので、 その受信者に、より慎重になることを依頼していること」を知っています。 送信者の「期待」を知っている受信者は、 特別な作法で発行されている「業務」を確認せずにメッセージを処理することを選択する可能性があります。 有効な署名の拡充された保証を記述する能力は、「送信者は、 加工する中間のもの(例：メーリングリスト等)を通過するメールは、 隔離されるか、あるいは、 削除される傾向があると予期する必要があること」を意味することに注意してください。； それゆえ、このシナリオは、問題シナリオ1よりも狭いです。
参考情報：
受信するフィルタは、
シナリオ1よりもはるかに厳しいシナリオ2を扱うために選択する可能性があります。；
シナリオ1が妙に見える場合、シナリオ2は、
何かがとてもおかしいように見えます。
我々が受信者宛に情報を提供することをSSPに望んでいることに関して、 上記に挙げられた問題がある場合、それ自体は、 解決されるべき問題と関連しないが、 そのSSPが提供する情報サービスを実装／配備する実際のメカニクスと関連する数多くのシナリオがあります。
多くのドメインは、自身でメールインフラストラクチャを運用していないか、 あるいは、第三者にアウトソースしている部分である可能性があります。 ドメイン保持者にとっては、他の主体に対して、 そのドメイン保持者についての署名をする能力を代理させる能力をもつことが渇望されます。 ひとつの明白な利用シナリオは、 「小さなドメインのドメイン保持者」であり、 (メールが)出ていくISP用に、そのドメイン保持者の代わって、 彼らのすべてのメールに署名する能力をもつ必要があります。 他の利用シナリオには、 マーケティングキャンペーンのためにアウトソースされた大量のメールと共に、 保険(insurance benefit)等のような、 様々なビジネスの職能のアウトソーシングが含まれます。
SSPクライアントは、問題シナリオ中に提示したように、 情報を提供するために、入ってくるメールストリームについて、 lookupを行います。 その [RFC2822] .Fromの最初のアドレスのドメイン部分は、 発行された情報をfetchするための基礎を形成します。 発行された情報の発見を回避する卑近な攻撃は、単に、 発行された情報をもたない、 その親ドメインのサブドメインを使うことによって放たれる可能性があります。 この攻撃は、サブドメイン攻撃と呼ばれます。： すなわち、ドメインは、 それが制御する所与のDNSラベル についてのポリシー発行することを望むのみならず、 そのラベルのすべてのサブドメインを防護することも望みます。 この特徴が一致しない場合、攻撃者は、 そのSSPの情報サービスによって対象とされていなかった(おそらく)架空のサブドメインを作る必要があるのみです。 それゆえ、SSPにとっては、所与のドメインのみならず、 そのドメインのすべてのサブドメインも対象にすることが有利となるでしょう。
今日のeメールの世界では、再送されるメールは、多くのシナリオにおいて、 よくあることです。 例えば、ドメインAliceは、 「Bobのメーリングリスト宛のすべてのメッセージに署名する」という発行された「業務」と共にDKIM署名されたメッセージを送ります。 善良なネット市民であるBobは、 問題となっているメッセージの責任を負う役割を果たすことを望むので、 彼は、そのメッセージに(おそらく、 その送信者のアドレスに応答して)DKIM署名します。
「このシナリオは、『Aliceの署名は、 存続しているBobのメーリングリストか否か？』とは完全に直交するものであること」に注意してください。： Bobは、めったに、 その最終的な受信者の便益についての説明責任の連鎖における彼の部分を言明することを望みません。 この「業務」について、促進されることは、有用です。 なぜならば、これは、「誰が、そのメッセージを扱うか？」について、 より正確な視点を与えるからです。 これには、「DKIM当事者署名を破る再送者は、潜在的に、 実際に存続した署名するドメインの受信者の意見に基づいて、 その受信者によって言明される可能性がある」という副次的な効用もあります。
実際問題として、ユーザ人口の複雑性、 ドメインに代わって送信するアウトソースされたベンダー等が与えられた場合、 ドメインがDKIM署名完了「業務」を発行できるようにDKIM署名を実施することは、 困難である可能性があります。 これは、その価値あるメールの攻略に解放したままにし、 (問題シナリオ2におけるように)発行された「業務」も最小限の共通の分母に区分されなりません。 ドメイン保持者が、 より制約的な「業務」の記述をもつ「期待」のリストを発行できるようにすることが渇望されます。
NB：この考慮は、 基本的なDKIM署名メカニズムによって提供されるメカニズムに合致すると見なされてきました。； これが論点であったとは、めったに文書化されてきませんでした。
例えば、bigbank.example.comは、「statements@bigbank.example.comは、 常に署名される」と言う用意ができている可能性がありますが、例えば、 ドメインの残りは、用意ができていません。 別の状況は、「所与のドメイン中のいくつかのアドレスlocal partの業務は、他のlocal partの業務と同様ではない」という状況です。 statements@bigbank.example.comが、 とても強い「業務」を発行することを望むトランザクション的な種のeメールである同じ例を使うと、 メーリングリスト等を通過する可能性がある残りのユーザ人口のlocal partと共に混ぜられて、 これについては、あまり強くない記述が適切です。
「DKIMは、 既に(サブドメインの利用を通じて)この種の区別をサポートできる」というべきです。 すなわち、強い「業務」を発行するためには、 それらの事例を異なるサブドメインに分離する必要があるのみです。 (例：accounts.bigbank.example.comは、制約された「業務」を発行し、 一方、corporateusers.bigbank.example.comは、 より寛容な「業務」を発行する可能性があります。)
eメールサービスは、潜在的にany-anyなメッシュ接続を提供します。： 要求されるのは、「MXレコードの発行」と、 「メールを受信するためのSMTP listener」がすべてです。 それゆえ、SSPの利用は、2つの主なシナリオになる傾向があります。 その第1は、定常的に相互に連絡しあっている大きなwell-knownドメインです。 この場合、レコードのキャッシュ機能は、性能のためには、 レコードの不存在のキャッシュ機能(すなわち、 ネガティブキャッシュ機能)を含むことが肝要です。
ふたつめの主なシナリオは、あるドメインがメールを、 はるかに少ない量のドメインと交換するときです。 このシナリオは、虚構のドメインの場合のように、まったく普通のベクトルと、 (残念ながら)反社会的理由のためにメールを送信する者についてベクトルの両方である可能性があります。 この場合、我々は、「SSP querierの負荷となるメッセージ交換が、 少ないこと」を望みます。 なぜならば、そのlookupの多くは、有用な回答をしないからです。 同様に、アップストリームのキャッシュ機能も、ここにもつことは、 (例えば、小さなドメイン上のメーリングリスト破裂器(exploder)が、 その小さなドメインについてrootや代替サーバに戻る問い合わせの激増をもたらさないように)有利です。
SSPレコードは、主に、自動的に使われる傾向がありますが、近い将来、 それらも、手作業で精査される傾向があります。 業務が人間の検査係(inspector)についても直感的な様式で記述されることは、 すばらしいことです。
本書は、DKIM署名業務をとりまく要件のみに適しますが、 他のプロトコルに拡張できることは、そのプロトコルのために有用です。
SSPは、 敵意あるオープンなインターネット環境における配備に耐えるものでなければなりません。 これらは、DoS攻撃(サービス妨害攻撃)を含み、特に、 そのプロトコルに不可避な増幅を通じて、 自身をてことするDoS攻撃を含みます。 さらに、有用なプロトコルが、 その情報サービスによって提供される強い発信元認証無しに構築される可能性がありますが、 強い発信元認証へのパスは、そのプロトコル、もしくは、 下位層のプロトコルによって提供される必要があります。
この章では、SSPの要件を定めます。 大部分の要件文書と同様に、これらの要件は、 候補となるプロトコルが提供しなければならない最低限の(MINIMUM)要件を規定します。 「SSPは、 すべての要件を満たさなければならないこと」にも注意する必要があります。
受信者は、 送信者のDKIM業務についての情報を取得するための手段を必要とします。 これは、「どこに、その情報は、あるか？」と、「それは、 何を含むか？」を発見するための手段を要求します。
発行と問い合わせのメカニズムは、 インターネットに基づくメッセージ交換(exchange)として動作します。 この下位層のサービスについて、複数の要件があります。：
定義の章に述べたように、「業務」は、 それが送信するeメールメッセージ中の外部から検証可能なふるまいの [RFC2822] .Fromドメイン保持者による言明(statement)です。 一例として、「業務」は、すべてのeメールメッセージが、 その [RFC2822] .Fromアドレスに呼応するDKIM署名を含むように定義される可能性があります。 「送信者が送るもの」と、「受信者が試験するもの」の間で、 差し替えられる可能性があるので、「期待」は、「何を、その [RFC2822] .Fromドメインは、受信者における、その「業務」の存続可能性の、 ありがちな最終結果と見なすか？」を伝えるために、 「業務」を組み合わせます。 (例：「その [RFC2822] .Fromアドレスについて有効なDKIMが、そのドメインから送信されたとき、 存在する」という「業務」や、 「すべての受信者『トポロジ的に隣接するか否か？』について存在し、 有効であり続ける」という「期待」)
本書は、新しいプロトコルについて、要件を規定し、 セキュリティ関連要件は、上記のように規定されています。 「新しいプロトコルは、 DNSをSSP情報の発行のための基盤として使うこと」が予測されるので、 [RFC4686] 中に記述された脅威のすべてではないにせよ、大部分は、適用可能です。
Dave CrockerとJim Fentonは、 本書のレビューを十分にしてくださいました。 有用なラストコールレビューをしてくださったVijay GurbaniとDavid Harringtonにも感謝します。
| [RFC2119] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
| [RFC2822] |
Resnick, P., Ed., "Internet Message Format", RFC 2822, 2001年4月. |
| [RFC4686] |
Fenton, J., 「DKIMの動機となった脅威分析 (Analysis of Threats Motivating DomainKeys Identified Mail (DKIM))」, RFC 4686, 2006年9月. |
| [RFC4871] |
Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J.,
and M. Thomas, 「DKIM署名 (DomainKeys Identified Mail (DKIM) Signatures)」, RFC 4871, 2007年5月. |
Michael Thomas
Cisco Systems
606 Sanchez St
San Francisco, California 94114
USA
電話： +1-408-525-5386
Fax： +1-408-525-5386
EMail： mat＠cisco.com
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
Email： miyakawa＠ipa.go.jp
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALLWARRANTIES, 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.