Internet Engineering Task Force (IETF)                        S. Farrell
Request for Comments: 7258                        Trinity College Dublin
BCP: 188                                                   H. Tschofenig
Category: Best Current Practice                                 ARM Ltd.
ISSN: 2070-1721                                                 May 2014
        

Pervasive Monitoring Is an Attack

広範囲にわたる監視は攻撃です

Abstract

概要

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

広範囲にわたる監視は、可能であればIETFプロトコルの設計で軽減する必要がある技術的な攻撃です。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7258.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7258で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

1. Pervasive Monitoring Is a Widespread Attack on Privacy

1. 広範囲にわたる監視はプライバシーに対する広範な攻撃です

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

Pervasive Monitoring（PM）は、アプリケーションコンテンツやヘッダーなどのプロトコルメタデータを含むプロトコルアーティファクトの侵入的な収集による広範囲にわたる（そして多くの場合は秘密の）監視です。アクティブまたはパッシブな盗聴とトラフィック分析（相関、タイミング、パケットサイズの測定など）、またはプロトコルのセキュリティ保護に使用される暗号化キーの破壊も、広範囲にわたる監視の一部として使用できます。 PMは、新しいタイプの技術的妥協を導入するのではなく、無差別で非常に大規模であることによって特徴付けられます。

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM.

IETFコミュニティの技術評価では、PMはインターネットユーザーおよび組織のプライバシーに対する攻撃であるとされています。 IETFコミュニティは、PMを大幅に高価または実行不可能にするプロトコルの設計により、PMは可能な場合は軽減する必要がある攻撃であるという強い合意を表明しています。 2013年11月のIETF会議の技術プレナリー[IETF88Plenary]で、そしてIETFメーリングリストでの広範な交流を通じて、広範にわたる監視について議論されました。このドキュメントは、IETFコミュニティのコンセンサスを記録し、PMの技術的性質を確立します。

The term "attack" is used here in a technical sense that differs somewhat from common English usage. In common English usage, an attack is an aggressive action perpetrated by an opponent, intended to enforce the opponent's will on the attacked party. The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator. [RFC4949] contains a more complete definition for the term "attack". We also use the term in the singular here, even though PM in reality may consist of a multifaceted set of coordinated attacks.

ここでは、「攻撃」という用語は、一般的な英語の使用法とは多少異なる技術的な意味で使用されています。一般的な英語の使用法では、攻撃とは、攻撃者に対して攻撃者の意志を強制することを目的とした、攻撃者が行う攻撃的な行為です。ここでの用語は、当事者間の合意なしに当事者間のコミュニケーションの意図を覆す行為を指すために使用されます。攻撃は、通信の内容を変更したり、通信の内容や外部特性を記録したり、他の通信イベントとの相関を介して、当事者が明らかにするつもりでなかった情報を明らかにしたりします。また、同様にコミュニケーターの意図を覆す他の効果があるかもしれません。 [RFC4949]には、「攻撃」という用語のより完全な定義が含まれています。 PMは実際には多面的な調整された攻撃のセットで構成されている場合もありますが、ここでは単数形でもこの用語を使用します。

In particular, the term "attack", used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols.

特に、技術的に使用される「攻撃」という用語は、攻撃者が攻撃を仕掛ける動機について何も意味しません。 PMの動機は、対象を絞った国民国家監視から、営利企業による合法的でプライバシーに配慮のない目的、犯罪者による違法行為までさまざまです。 PMを達成するための同じ手法は、動機に関係なく使用できます。したがって、攻撃者が必要とするアクションは他の攻撃と区別がつかないため、他のアクターによる監視を許可しながら、最も悪質なアクターを防御することはできません。したがって、PMの動機は、PMがIETFプロトコルでどのように軽減されるかには関係ありません。

2. The IETF Will Work to Mitigate Pervasive Monitoring

2. IETFは広範囲にわたる監視を軽減するように機能します

"Mitigation" is a technical term that does not imply an ability to completely prevent or thwart an attack. Protocols that mitigate PM will not prevent the attack but can significantly change the threat. (See the diagram on page 24 of RFC 4949 for how the terms "attack" and "threat" are related.) This can significantly increase the cost of attacking, force what was covert to be overt, or make the attack more likely to be detected, possibly later.

「緩和」とは、攻撃を完全に防止または阻止する能力を意味しない技術用語です。 PMを軽減するプロトコルは攻撃を防止しませんが、脅威を大幅に変更する可能性があります。 （「攻撃」と「脅威」という用語の関係については、RFC 4949の24ページの図を参照してください。）これにより、攻撃のコストが大幅に増加したり、隠されていたものを強制したり、攻撃の可能性を高めたりできます。おそらく後で検出されました。

IETF standards already provide mechanisms to protect Internet communications and there are guidelines [RFC3552] for applying these in protocol design. But those standards generally do not address PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation. In all cases, there will remain some privacy-relevant information that is inevitably disclosed by protocols. As technology advances, techniques that were once only available to extremely well-funded actors become more widely accessible. Mitigating PM is therefore a protection against a wide range of similar attacks.

IETF標準はすでにインターネット通信を保護するメカニズムを提供しており、これらをプロトコル設計に適用するためのガイドライン[RFC3552]があります。しかし、これらの標準は通常、PM、プロトコルメタデータの機密性、トラフィック分析への対抗、またはデータの最小化には対応していません。すべての場合において、プロトコルによって必然的に開示されるいくつかのプライバシー関連情報が残ります。技術の進歩に伴い、非常に資金のある俳優がかつてしか利用できなかった技術がより広く利用できるようになります。したがって、PMを軽減することは、同様の広範囲の攻撃に対する保護です。

It is therefore timely to revisit the security and privacy properties of our standards. The IETF will work to mitigate the technical aspects of PM, just as we do for protocol vulnerabilities in general. The ways in which IETF protocols mitigate PM will change over time as mitigation and attack techniques evolve and so are not described here.

したがって、私たちの標準のセキュリティとプライバシーの特性を再検討するのはタイムリーです。 IETFは、一般的なプロトコルの脆弱性の場合と同じように、PMの技術的な側面を軽減するように機能します。 IETFプロトコルがPMを緩和する方法は、緩和と攻撃の技術が進化するにつれて変化するため、ここでは説明しません。

Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?"

開発中のIETF仕様は、PMをどのように検討したかを説明できる必要があり、攻撃が公開される作業に関連している場合は、関連する設計決定を正当化できる必要があります。これは、IETFのドキュメントに新しい「広範な監視に関する考慮事項」セクションが必要であることを意味しません。これは、質問された場合、「この作業に広範に及ぶ監視は関連しているか、もしそうであれば、どのように考慮されているか」という質問に対する適切な回答が必要であることを意味します。

In particular, architectural decisions, including which existing technology is reused, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making architectural decisions. Getting adequate, early review of architectural decisions including whether appropriate mitigation of PM can be made is important. Revisiting these architectural decisions late in the process is very costly.

特に、どの既存のテクノロジーを再利用するかなどのアーキテクチャ上の決定は、PMに対するプロトコルの脆弱性に大きな影響を与える可能性があります。したがって、IETF仕様を開発している人は、アーキテクチャ上の決定を行うときにPMを軽減することを検討する必要があります。 PMの適切な緩和を行うことができるかどうかなど、アーキテクチャに関する決定を適切かつ早期にレビューすることが重要です。プロセスの後半でこれらのアーキテクチャに関する決定を再検討することは非常にコストがかかります。

While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered.

PMは攻撃ですが、PMの定義に適合する可能性のある他の形式の監視は有益であり、攻撃の一部ではない可能性があります。たとえば、ネットワーク管理機能はパケットまたはフローを監視し、スパム対策メカニズムはメールメッセージの内容を確認する必要があります。たとえば、証明書の透過性[RFC6962]は、いくつかのPM攻撃手法を検出できる方法で公開鍵インフラストラクチャを監視することを含みます。ただし、モニタリングメカニズムがPMで悪用される可能性があることは明らかであるため、プロトコル設計ではこの緊張を慎重に検討する必要があります。 PMを軽減するためにネットワークを管理不能にすることは許容できる結果ではありませんが、PMを無視すると、ここに記載されているコンセンサスに反することになります。この緊張の実際の例が考慮されるにつれて、適切なバランスが時間とともに明らかになります。

Finally, the IETF, as a standards development organisation, does not control the implementation or deployment of our specifications (though IETF participants do develop many implementations), nor does the IETF standardise all layers of the protocol stack. Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF. The broader Internet community will need to step forward to tackle PM, if it is to be fully addressed.

最後に、IETFは、標準開発組織として、仕様の実装または展開を制御しません（ただし、IETFの参加者は多くの実装を開発します）。また、IETFはプロトコルスタックのすべての層を標準化しません。さらに、広範囲にわたる監視を緩和する非技術的（たとえば、法的および政治的）側面は、IETFの範囲外です。より広範囲のインターネットコミュニティは、PMに完全に取り組むには、PMに取り組むために一歩前進する必要があります。

To summarise: current capabilities permit some actors to monitor content and metadata across the Internet at a scale never before seen. This pervasive monitoring is an attack on Internet privacy. The IETF will strive to produce specifications that mitigate pervasive monitoring attacks.

要約すると、現在の機能により、一部のアクターはこれまでにない規模でインターネット全体のコンテンツとメタデータを監視できます。この広範囲にわたる監視は、インターネットのプライバシーに対する攻撃です。 IETFは、広範囲にわたる監視攻撃を軽減する仕様の作成に努めます。

3. Process Note

3. プロセスノート

In the past, architectural statements of this sort, e.g., [RFC1984] and [RFC2804], have been published as joint products of the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB). However, since those documents were published, the IETF and IAB have separated their publication "streams" as described in [RFC4844] and [RFC5741]. This document was initiated after discussions in both the IESG and IAB, but is published as an IETF-stream consensus document, in order to ensure that it properly reflects the consensus of the IETF community as a whole.

過去には、この種のアーキテクチャに関する声明（[RFC1984]や[RFC2804]など）は、インターネットエンジニアリングステアリンググループ（IESG）とインターネットアーキテクチャボード（IAB）の共同製品として公開されていました。ただし、これらのドキュメントが公開されて以来、IETFとIABは[RFC4844]と[RFC5741]で説明されているように、それらの公開「ストリーム」を分離しています。このドキュメントは、IESGとIABの両方での議論の後に開始されましたが、IETFコミュニティ全体のコンセンサスを適切に反映するために、IETFストリームのコンセンサスドキュメントとして公開されています。

4. Security Considerations

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

This document is entirely about privacy. More information about the relationship between security and privacy threats can be found in [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses surveillance as a combined security-privacy threat.

このドキュメントは完全にプライバシーについてです。セキュリティとプライバシーの脅威の関係についての詳細は、[RFC6973]にあります。 [RFC6973]のセクション5.1.1は、監視をセキュリティとプライバシーの複合脅威として具体的に扱っています。

5. Acknowledgements

5. 謝辞

We would like to thank the participants of the IETF 88 technical plenary for their feedback. Thanks in particular to the following for useful suggestions or comments: Jari Arkko, Fred Baker, Marc Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Phillip Hallam-Baker, Ted Hardie, Sam Hartmann, Paul Hoffman, Bjoern Hoehrmann, Russ Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan Winter, and Lloyd Wood. Additionally, we would like to thank all those who contributed suggestions on how to improve Internet security and privacy or who commented on this on various IETF mailing lists, such as the ietf@ietf.org and the perpass@ietf.org lists.

IETF 88テクニカルプレナリーの参加者のフィードバックに感謝します。役立つ提案やコメントを寄せてくださった次の方々に特に感謝します。JariArkko、Fred Baker、Marc Blanchet、Tim Bray、Scott Brim、Randy Bush、Brian Carpenter、Benoit Claise、Alissa Cooper、Dave Crocker、Spencer Dawkins、Avri Doria、Wesley Eddy 、エイドリアン・ファレル、ジョセフ・ロレンゾ・ホール、フィリップ・ハラム・ベイカー、テッド・ハーディー、サム・ハートマン、ポール・ホフマン、ビョルン・ホールマン、ラス・ハスリー、ジョエル・ジャグリ、スティーブン・ケント、エリオット・リア、バリー・レイバ、テッド・レモン、サブラマニアン・ムーネサミー、エリック・ノードマーク、ピートレズニック、ピーターセントアンドレ、アンドリューサリバン、ショーンターナー、ニコラスウィーバー、ステファンウィンター、ロイドウッド。さらに、インターネットのセキュリティとプライバシーを改善する方法について提案を提供したり、ietf @ ietf.orgやperpass@ietf.orgリストなどのさまざまなIETFメーリングリストでこれについてコメントしたすべての人に感謝します。

6. Informative References

6. 参考引用

[IETF88Plenary] IETF, "IETF 88 Plenary Meeting Materials", November 2013, <http://www.ietf.org/proceedings/88/>.

[IETF88Plenary] IETF、「IETF 88総会資料」、2013年11月、<http://www.ietf.org/proceedings/88/>。

[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.

[RFC1984] IAB、IESG、Carpenter、B。、およびF. Baker、「IABおよびIESG Statement on Cryptographic Technology and the Internet」、RFC 1984、1996年8月。

[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.

[RFC2804] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、2000年5月。

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。

[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.

[RFC4844] Daigle、L. and Internet Architecture Board、「The RFC Series and RFC Editor」、RFC 4844、2007年7月。

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.

[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。

[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.

[RFC5741] Daigle、L.、Kolkman、O。、およびIAB、「RFC Streams、Headers、およびBoilerplates」、RFC 5741、2009年12月。

[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013.

[RFC6962]ローリーB.、ラングレーA.、およびE.キャスパー、「Certificate Transparency」、RFC 6962、2013年6月。

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.

[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、7月2013。

Authors' Addresses

著者のアドレス

Stephen Farrell Trinity College Dublin Dublin 2 Ireland

スティーブンファレルトリニティカレッジダブリンダブリン2アイルランド

   Phone: +353-1-896-2354
   EMail: stephen.farrell@cs.tcd.ie
        

Hannes Tschofenig ARM Ltd. 6060 Hall in Tirol Austria

Hannes Tschofenig ARM Ltd. 6060 Hall in Tirolオーストリア

   EMail: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at