Network Working Group
Request for Comments: 5016
分類: 情報提供

M. Thomas
Cisco Systems
2007年10月

English

DKIM SPP についての要件
(Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol)

このメモの位置づけ

このメモは、インターネットコミュニティに情報を提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布には制限はありません。

要旨

DKIM(DomainKeys Identified Mail)は、ドメインが扱うメッセージについての責任を言明するための暗号技術的メカニズムを提供します。関連するメカニズムは、運用管理者が彼らの DKIM 署名業務について、様々な言明を発行できるようにします。本書は、このメカニズムについて、満たされなければならない(MUST)ものと、強く必要(SHOULD)なものを区別しながら要件を規定します。


目次

1. はじめに
2. 定義および要件用語
3. SSP 問題シナリオ
      3.1. 問題シナリオ 1: すべてのメールが DKIM で署名されるのか?
      3.2. 問題シナリオ 2: 不正なドメイン名の利用
4. SSP の配備についての考慮事項
      4.1. 配備についての考慮事項 1: アウトソースされた署名
      4.2. 配備についての考慮事項 2: サブドメインも対象
      4.3. 配備についての考慮事項 3: 再送された当初のメール
      4.4. 配備についての考慮事項 4: 署名機能の段階的配備
      4.5. 配備についての考慮事項 5: 性能とキャッシュ機能
      4.6. 配備についての考慮事項 6: 「業務」についての人間による可読性
      4.7. 配備についての考慮事項 7: 拡張可能性
      4.8. 配備についての考慮事項 8: セキュリティ
5. 要件
      5.1. 発見法についての要件
      5.2. SSP トランスポート要件
      5.3. 業務と期待の要件
      5.4. 拡張可能性と上位互換性の要件
6. SSP セキュリティについての要件
7. セキュリティに関する考慮事項
8. 謝辞
9. 参考文献
      9.1. 規範的参考文献

 

1.  はじめに English

DKIM(DomainKeys Identified Mail)[RFC4871] は、e メール用のメッセージレベルの署名・検証メカニズムを規定しています。DKIM 署名されたメッセージ自体は、有用ですが、メッセージが有効な当事者署名(すなわち、[RFC2822].From アドレスの代わり)をもたない場合、曖昧さがあります。: e メールについては、 「これは、期待されるべきものであるか否か?」は、特に困難な問題です。なぜならば、ドメインの業務を送信することについて、事前の知識としての期待が無いからです。この曖昧さは、オプションとしての認証を許容する e メールのようなシステムについて不可避な「bid down 攻撃」を放つために使われる可能性があります。: 受信者が知らない場合、「有効な署名の欠如は、他の情報無しには例外的である」と想定してはいけません。それゆえ、攻撃者は、その曖昧さを利用することができ、単に署名しません。プロトコルが、あるドメインについて、その DKIM 署名業務を発行するように開発される可能性がある場合、メッセージ検証器は、それが署名されていない e メールを受信するとき、考慮する可能性があります。

本書は、SSP(Sender Signing Practices)を発行できるようにメカニズムについての要件を規定します。本書は、2 つの主要な章から成ります。: ひとつめは、「SSP は、基本問題の周囲にある配備の論点にも対応することが意図された」という問題を記述する問題と配備シナリオの章であり、ふたつめの章は、それらのシナリオに起因する要件です。

 

2.  定義および要件用語 English

本書中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" および "OPTIONAL" というキーワードは、RFC 2119 [RFC2119] 中に記述されているように解釈されるべきものです。

3.  SSP 問題シナリオ English

電子メールの世界は、配備について、多くの考慮事項を伴う敵意がある場所です。この章では、「どこで DKIM 署名/検証は、行われるか?」と、「どのように新しいプロトコルは、DKIM 署名されたメールの今日的意味(relevance)を明確化するために役立つ可能性があるか?」について、予期される用法のシナリオを概説します。

3.1.  問題シナリオ 1: すべてのメールが DKIM で署名されるのか? English

ドメインから出ていくメールを監査し、DKIM 署名機能を正規の出ていくメールのすべてについて配備した後、ドメインは、「DKIM 署名を完了した」と言えます。すなわち、そのドメインは、(その能力の最善をつくして)「そのドメインから来たように見せかけているすべての正規のメールは、有効な DKIM 署名を含むこと」を確認しました。

このような一般的な事例において、受信者は、「どの『業務』が、所与のドメインについてか?」を知りません。それゆえ、その受信者は、「すべてのメールについて、所与のドメインから署名されることが期待される必要があるか否か?」を知らない不利な状況にあります。この知識ギャップは、卑近に攻略可能な「bid-down 攻撃」をもたらします。この攻撃では、攻撃者は、めったに署名されていないメールを送信しません。; なぜならば、その受信者は、その署名されていないドメインの「業務」を知らないので、有効な署名の欠如について、もはや厳しくメッセージを扱えないからです。

有効な当事者署名が見つからないとき、受信者が、その当事者ドメインの「業務」と「期待」について、問い合わせることができるようにする情報サービスは、このギャップを埋める際に有用である可能性があります。受信者は、この情報を、様々な程度の先入観をもって、このような疑わしいメールを扱うために使う可能性があります。

「近い将来、メールの制限されていない利用パターン(例: ユーザが、メーリングリストのメンバである可能性がある場合、等)は、時々、転送中の悪意が無い署名失敗をわずらう傾向にあること」に注意してください。おそらく、総トラフィックの大きな比率は占めませんが、この種の破損(breakage)は、そのような利用パターンについての顕著な関心事である可能性があります。このシナリオは、送信者が、「個々のメッセージは、無傷で到来するか否か?」に関する「期待」を設定できない場合を規定します。

たとえ期待が無いときでも、受信者は、「そのドメインの『業務』は、すべてのメールに署名し、署名されていない、あるいは、損傷した転送中のメールに対して、そのフィルタを歪める」という知識を利用する可能性があります。この情報は、2値の正否で使われると期待されてはいけません。代わりに、フィルタリングシステムに他のものがある中のデータポイントとして期待される必要があります。

下記のやりとりは、問題シナリオ 1 を表現しています。

  1. [RFC2822].From ドメインとして Alice をもつメールは、ドメイン Bob 宛に Alice からの DKIM 当事者署名無しに、あるいは、 Alice からの壊れた DKIM 当事者署名と共に送られます。
     
  2. ドメイン Bob は、「それは、予期された事態か否か?」を知りたがります。
     
  3. ドメイン Alice は、「すべての出ていくメールに署名する」という情報を提供しますが、「それが無傷の当事者署名と共に到来するか否か?」について、何も期待しません。
     
  4. ドメイン Bob は、メッセージを何らかの疑念をもって、この情報を試験するために、そのフィルタを歪めるために使う可能性があります 。

3.2.  問題シナリオ 2: 不正なドメイン名の利用 English

価値あるドメインからのトランザクションとしてのメールによって象徴される類のメールは、現在、phishing 攻撃の標的です。特に、多くの phishing 詐欺は、そのコンテンツの多くに細工して、疑わないユーザを騙し(spoofing)て、取扱に注意を要する(sensitive)情報を明かすようにしてしまうことに加えて、[RFC2822]. From アドレス も偽装します。このメールを送っているドメイン保持者は、その能力が「彼らのドメイン名と共に送られたメールは、常に、『そのドメイン保持者は、その転送に同意したこと』の証明と共に到着する必要がある」という拡充された保証を与えること望みます。すなわち、そのメッセージは、上記に定義したように、有効な当事者署名を含む必要があります。

受信者の観点から、「ドメインは、そのメールのすべてに署名するのみならず、そのドメインからの有効な当事者署名の受領を重視していること」を知っていることは、有用です。それゆえ、受信者は、「その送信しているドメインは、そのすべてのメールに署名すること」を知っており、「その署名するドメインは、ある観点からは特に注意を要するドメインからのメールと見なし、当事者署名が壊れていたり、あるいは無かったりする可能性があるので、その受信者に、より慎重になることを依頼していること」を知っています。送信者の「期待」を知っている受信者は、特別な作法で発行されている「業務」を確認せずにメッセージを処理することを選択する可能性があります。有効な署名の拡充された保証を記述する能力は、「送信者は、加工する中間のもの(例:メーリングリスト等)を通過するメールは、隔離されるか、あるいは、削除される傾向があると予期する必要があること」を意味することに注意してください。; それゆえ、このシナリオは、問題シナリオ 1 よりも狭いです。

参考情報:
受信するフィルタは、シナリオ 1 よりもはるかに厳しいシナリオ 2 を扱うために選択する可能性があります。; シナリオ 1 が妙に見える場合、シナリオ 2 は、何かがとてもおかしいように見えます。

  1. [RFC2822].From ドメイン Alice をもつメールは、ドメイン Bob 宛に、当事者 DKIM 署名無しで、あるいは、ドメイン Alice からの壊れた当事者 DKIM 署名と共に送られます。

  2. ドメイン Bob は、「それは、予期された状況か否か?」を知りたがります。
     
  3. ドメイン Alice は、「すべての出ていくメールに署名し、さらに、『それは、無傷な当事者署名と共に到来する必要がある 』と『期待』し、『その受信者は、そうではない』 と『期待』する場合、はるかに用心する必要がある」という情報を提供します。
     
  4. ドメイン Bob は、この情報を、そのフィルタがそのメッセージを、大いに疑念をもって試験するように歪めるために使う可能性があります。

 

4.  SSP の配備についての考慮事項 English

我々が受信者宛に情報を提供することを SSP に望んでいることに関して、上記に挙げられた問題がある場合、それ自体は、解決されるべき問題と関連しないが、その SSP が提供する情報サービスを実装/配備する実際のメカニクスと関連する数多くのシナリオがあります。

4.1.  配備についての考慮事項 1: アウトソースされた署名 English

多くのドメインは、自身でメールインフラストラクチャを運用していないか、あるいは、第三者にアウトソースしている部分である可能性があります。ドメイン保持者にとっては、他の主体に対して、そのドメイン保持者についての署名をする能力を代理させる能力をもつことが渇望されます。ひとつの明白な利用シナリオは、「小さなドメインのドメイン保持者」であり、(メールが)出ていく ISP 用に、そのドメイン保持者の代わって、彼らのすべてのメールに署名する能力をもつ必要があります。他の利用シナリオには、マーケティングキャンペーンのためにアウトソースされた大量のメールと共に、保険(insurance benefit)等のような、様々なビジネスの職能のアウトソーシングが含まれます。

4.2.  配備についての考慮事項 2: サブドメインも対象 English

SSP クライアントは、問題シナリオ中に提示したように、情報を提供するために、入ってくるメールストリームについて、lookup を行います。その [RFC2822].From の最初のアドレスのドメイン部分は、発行された情報を fetch するための基礎を形成します。発行された情報の発見を回避する卑近な攻撃は、単に、発行された情報をもたない、その親ドメインのサブドメインを使うことによって放たれる可能性があります。この攻撃は、サブドメイン攻撃と呼ばれます。: すなわち、ドメインは、それが制御する所与の DNS ラベル についてのポリシー発行することを望むのみならず、そのラベルのすべてのサブドメインを防護することも望みます。この特徴が一致しない場合、攻撃者は、その SSP の情報サービスによって対象とされていなかった(おそらく)架空のサブドメインを作る必要があるのみです。それゆえ、SSP にとっては、所与のドメインのみならず、そのドメインのすべてのサブドメインも対象にすることが有利となるでしょう。

4.3.  配備についての考慮事項 3: 再送された当初のメール English

今日の e メールの世界では、再送されるメールは、多くのシナリオにおいて、よくあることです。例えば、ドメイン Alice は、「Bob のメーリングリスト宛のすべてのメッセージに署名する」という発行された「業務」と共に DKIM 署名されたメッセージを送ります。善良なネット市民である Bob は、問題となっているメッセージの責任を負う役割を果たすことを望むので、彼は、そのメッセージに(おそらく、その送信者のアドレスに応答して)DKIM 署名します。

「このシナリオは、 『Alice の署名は、存続している Bob のメーリングリストか否か?』とは完全に直交するものであること」に注意してください。: Bob は、めったに、その最終的な受信者の便益についての説明責任の連鎖における彼の部分を言明することを望みません。この「業務」について、促進されることは、有用です。なぜならば、これは、「誰が、そのメッセージを扱うか?」について、より正確な視点を与えるからです。これには、「DKIM 当事者署名を破る再送者は、潜在的に、実際に存続した署名するドメインの受信者の意見に基づいて、その受信者によって言明される可能性がある」という副次的な効用もあります。

4.4.  配備についての考慮事項 4: 署名機能の段階的配備 English

実際問題として、ユーザ人口の複雑性、ドメインに代わって送信するアウトソースされたベンダー等が与えられた場合、ドメインが 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 は、より寛容な「業務」を発行する可能性があります。)

4.5.  配備についての考慮事項 5: 性能とキャッシング English

e メールサービスは、潜在的に any-any なメッシュ接続を提供します。:要求されるのは、「MX レコードの発行」と、「メールを受信するための SMTP listener」がすべてです。それゆえ、SSP の利用は、2 つの主なシナリオになる傾向があります。その第 1 は、定常的に相互に連絡しあっている大きな well-known ドメインです。この場合、レコードのキャッシュ機能は、性能のためには、レコードの不存在のキャッシュ機能(すなわち、ネガティブキャッシュ機能)を含むことが肝要です。

ふたつめの主なシナリオは、あるドメインがメールを、はるかに少ない量のドメインと交換するときです。このシナリオは、虚構のドメインの場合のように、まったく普通のベクトルと、(残念ながら)反社会的理由のためにメールを送信する者についてベクトルの両方である可能性があります。この場合、我々は、「SSP querier の負荷となるメッセージ交換が、少ないこと」を望みます。なぜならば、その lookup の多くは、有用な回答をしないからです。同様に、アップストリームのキャッシュ機能も、ここにもつことは、(例えば、小さなドメイン上のメーリングリスト破裂器(exploder)が、その小さなドメインについて root や代替サーバに戻る問い合わせの激増をもたらさないように)有利です。

4.6.  配備についての考慮事項 6: 「業務」についての人間による可読性 English

SSP レコードは、主に、自動的に使われる傾向がありますが、近い将来、それらも、手作業で精査される傾向があります。業務が人間の検査係(inspector)についても直感的な様式で記述されることは、すばらしいことです。

4.7.  配備についての考慮事項 7: 拡張可能性 English

本書は、DKIM 署名業務をとりまく要件のみに適しますが、他のプロトコルに拡張できることは、そのプロトコルのために有用です。

4.8.  配備についての考慮事項 8: セキュリティ English

SSP は、敵意あるオープンなインターネット環境における配備に耐えるものでなければなりません。これらは、DoS 攻撃(サービス妨害攻撃)を含み、特に、そのプロトコルに不可避な増幅を通じて、自身をてことする DoS 攻撃を含みます。さらに、有用なプロトコルが、その情報サービスによって提供される強い発信元認証無しに構築される可能性がありますが、強い発信元認証へのパスは、そのプロトコル、もしくは、下位層のプロトコルによって提供される必要があります。

 

5.  要件 English

この章では、SSP の要件を定めます。大部分の要件文書と同様に、これらの要件は、候補となるプロトコルが提供しなければならない最低限の(MINIMUM)要件を規定します。「SSP は、すべての要件を満たさなければならないこと」にも注意する必要があります。

5.1.  発見法についての要件 English

受信者は、送信者の DKIM 業務についての情報を取得するための手段を必要とします。これは、「どこに、その情報は、あるか?」と、「それは、何を含むか?」を発見するための手段を要求します。

1. 

著者は、[RFC2822].From フィールドに規定されているように、メッセージの最初の送信者です。SSP の情報は、その著者のドメイン名と関連づけられ、そのドメイン名の下位に発行されます。


2. 

その利用コストを制限するために、SSP の情報を提供するあらゆる問い合わせサービスは、通常の運用的条件のもとで、決定論的(deterministic)な少数のメッセージ交換内で最終的な(definitive)応答を提供しなければなりません(MUST)

参考情報:
これは、(すべての意図や目的について)ループを作り出してしまう可能性があるもの、あるいは、さらなる遅延や負荷をもたらす可能性がある、あらゆるものについて禁止します。; また、「決定論的」は、「どれだけ多くの交換か?」を規定しませんが、その期待は、「少数」です。

参照: 配備についての考慮事項 4.2 および 4.5

 

3. 

SSP の発行メカニズムは、同一の場所に配置される異なるプロトコルについて、同種の複数の resource レコードをもたらさないように規定されなければなりません(MUST)

参考情報:
一例は、卑近な DNS leaf 内の同種の複数の resource レコードです。それゆえ、固有となるように定義された leaf 名、もしくは、固有となるように定義された resource レコード種別は、あいまいな参照機能を確認します。

参照: 配備についての考慮事項 4.2

 

4.  SSP 取得は、所与のドメインのみならず、そのすべてのサブドメインについても、対象範囲とする必要があります(SHOULD)。「この要件に対する広く受容されている解決策の実現可能性について、いくつかの合理的な疑いがあること」が認識されています。そのワーキンググループが解決策について、概ねのコンセンサスに達しない場合、それは、そのプロトコル仕様において、関連する「セキュリティに関する考慮事項」 を文書化しなければなりません(MUST)

参照: 配備についての考慮事項 4.2 および 4.5

 

5.2.  SSP トランスポート要件 English

発行と問い合わせのメカニズムは、インターネットに基づくメッセージ交換(exchange)として動作します。この下位層のサービスについて、複数の要件があります。:

1.  その交換は、既にそのトランスポート層の広範な配備をもつ必要があります(SHOULD)(特に、真のトランスポート層(例:TCP, UDP)上にある場合 )。

         参照: 配備についての考慮事項 4.5 および 4.7

 

2. 

待ち時間と、巻き込まれるメッセージの数の観点から、その問い合わせ/応答は、(再転送、あるいは、他の例外的条件を数えずに)3 回のメッセージ交換より)少なくなければなりません(MUST)

         参照: 配備についての考慮事項 4.5

 

3.  そのインフラストラクチャが(DNS のように)キャッシュ機能を提供しない場合、取得したレコードは、開始社(initiator)に自身のキャッシュを維持管理する能力を提供しなければなりません(MUST)。しかし、既存のキャッシュ機能のインフラストラクチャは、強く求められます。

参照: 配備についての考慮事項 4.5

 

4.  複数の地理的・トポロジ的に離れたサーバについては、高い利用可能性がサポートされなければなりません(MUST)

参照: 配備についての考慮事項 4.5 および 4.7

 

5.3.  「業務」と「期待」の要件 English

定義の章に述べたように、「業務」は、それが送信する e メールメッセージ中の外部から検証可能なふるまいの [RFC2822]. From ドメイン保持者による言明(statement)です。一例として、「業務」は、すべての e メールメッセージが、その [RFC2822]. From アドレスに呼応する DKIM 署名を含むように定義される可能性があります。「送信者が送るもの」と、「受信者が試験するもの」の間で、差し替えられる可能性があるので、「期待」は、「何を、その [RFC2822]. From ドメインは、受信者における、その「業務」の存続可能性の、ありがちな最終結果と見なすか?」を伝えるために、「業務」を組み合わせます。(例: 「その [RFC2822]. From アドレスについて有効な DKIM が、そのドメインから送信されたとき、存在する」という「業務」や、「すべての受信者s 『トポロジ的に隣接するか否か?』について存在し、有効であり続ける」という「期待」)

1.  SSP は、DKIM の文脈において、[RFC2822]. From アドレスのドメイン部分について「業務」と「期待」の言明を行えなければなりません(MUST)。SSP は、今回は、DKIM のために他のアドレスについて言明しません。

参照: 問題シナリオ 1 および 2, 3.1 および 3.2

 

2.  SSP は、その [RFC2822]. From と DKIM i= tag 中のアイデンティティ間の簡明(concise)な結びつき、もしくは、それが署名中に無い場合、そのデフォルトを提供しなければなりません(MUST)。すなわち、SSP は、「何が、当事者署名の資格となるか?」の意味論を詳細に規定しなければなりません(MUST)

参照: 問題シナリオ 1 および 2, 3.1 および 3.2

 

3.  SSP は、「そのドメインの署名行為は、『DKIM 署名完了』である」という業務を発行できなければなりません(MUST)。すなわち、すべてのメッセージは、有効な当事者署名と共に転送されました。

参照: 問題シナリオ 1, 3.1

 

4.  SSP は、「検証可能な当事者 DKIM 署名は、メッセージの受領において期待される必要がある」という期待を発行できなければなりません(MUST)

参照: 問題シナリオ 2, 3.2

 

5. 

業務と期待は、できる限り描写的な記述子(descriptor)を使って、SSP 構文中に存在しなければなりません(MUST)。例えば、p=? は、p=unknown として、より良く応答されます。

参照: 配備についての考慮事項 4.6

 

6.  DKIM は、セレクタを保管するために DNS を使うので、常に、ドメイン保持者が、その _domainkey サブドメインのすべて、もしくは、一部を、そのドメイン保持者の選択によって、関係者宛に代理させるための能力があります。すなわち、そのドメイン保持者は、_domainkey.example.com についての NS レコードを、その名前空間全体を管理する e メール provider 宛に代理するために設定する可能性があります。さらに第三者を制限するために、その名前空間をサブドメインに 適するようにするドメイン保持者について能力も、あります。例えば、ドメイン保持者は、domainkey.benefits.example.com のみを、その第三者が、その benefits.example.com サブドメイン中に有効な署名を作り出すことのみができるようにを制限するために、第三者宛に代理できます。最後に、ドメイン保持者は、CNAME's を個々の leaf ノードを代理させる使う可能性さえ、あります。上記の考慮事項をふまえて、SSP は、今のところ、関係する主体が、あるドメインの代わりに署名できるようにするための異なる手段を発明する必要はありません。

参照: 配備についての考慮事項 4.4

 

 7.  「業務」と「期待」は、その受信者のローカルポリシーに対して追加される要素として利用されるように署名するドメインからの情報サービスとして存在しなければなりません(MUST)。特に、「業務」もしくは「期待」は、その受信者について、いかなる処理(disposition)のスタンスをも強制してはなりません(MUST NOT)

参照: 問題シナリオ 1 および 2, 3.1 および 3.2

 

8.  「SSP が、その ドメイン保持者の代わりに署名してはならない(MUST NOT)あらゆる/すべての第三者の「業務」を発行する」という要件は、ありません。これは、範囲外と見なされる必要があります。

参考情報:
これは、要するに、「そのプロトコル自体は、ブラックリストのリポジトリであることと関わる必要はない」と言っています。

参照: 問題シナリオ 1 および 2, 3.1 および 3.2

 

9.  有効な当事者署名が見つかった場合、SSP が巻き込まれることを要求されてはなりません(MUST NOT)

参照: 配備についての考慮事項 4.2

 

10. SSP は、メッセージ中に非当事者署名の存在を論難する(impugn)メカニズムを提供してはなりません(MUST NOT)。この要件の当然の結果(corollary)は、「そのプロトコルは、当事者署名者の業務を、第三者署名者の業務とリンクしてはならない(MUST NOT)」ということです。

参考情報:
この要件の主な信頼(thrust)は、「業務は、発行者が制御できるものについてのみ発行される必要があること」であり、「何が、究極的に、その受信者のそのローカルポリシーであるか?」に拘泥してはいけません。

参照: 配備についての考慮事項 4.3

 

5.4.  拡張性と上位互換性の要件 English

1.  SSP は、今のところ、e メールについての DKIM 以外の、いかなるプロトコルにも拡張してはなりません(MUST NOT)。SSP は、DKIM 以外のプロトコルについて、拡張可能である必要があります(SHOULD)

参照: 配備についての考慮事項 4.7

 

2.  SSP は、新しい「業務」や「期待」を、既存の発見法/トランスポート/「業務」中に、下位互換性ある様式で追加できなければなりません(MUST)

参照: 配備についての考慮事項 4.7

 

 

6.  SSP セキュリティについての要件 English

1. 

価値あるドメインについて、SSP は、潜在的に、価値ある DoS 攻撃の標的です。(特に、SSP のレコードの入手不能性は、署名されていないメッセージを、あまり怪しいものではなくす可能性があるので。)

2. 

SSP は、「高度に増幅された攻撃」もしくは「make-work 攻撃」を可能にしてはなりません(MUST NOT)。特に、巻き込まれる作用とメッセージ交換は、一定の順序でなければなりません(MUST)

参照: 配備についての考慮事項 4.8

 

3. 

SSP は、ドメイン保持者のために、受信者が自動的に、大きな確度で、そのドメイン保持者からのものであることを判定できるように、SSP のデータを提供する能力をもたなければなりません(MUST)。SSP は、配備し易さとのトレードオフを考慮して、確度が劣る手段を提供する可能性があります。

参照: 配備についての考慮事項 4.8

 

 

7.  セキュリティに関する考慮事項 English

本書は、新しいプロトコルについて、要件を規定し、セキュリティ関連要件は、上記のように規定されています。 「新しいプロトコルは、DNS を SSP 情報の発行のための基盤として使うこと」が予測されるので、[RFC4686] 中に記述された脅威のすべてではないにせよ、大部分は、適用可能です。

 

8.  謝辞 English

Dave Crocker と Jim Fenton は、本書のレビューを十分にしてくださいました。有用なラストコールレビューをしてくださった Vijay Gurbani と David Harrington にも感謝します。


9.  参考文献

9.1.  規範的参考文献

[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.