[要約] RFC 6590は、メールの乱用報告から潜在的に敏感なデータを削除するためのガイドラインです。その目的は、プライバシー保護とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Falk, Ed.
Request for Comments: 6590 Return Path
Category: Standards Track M. Kucherawy, Ed.
ISSN: 2070-1721 Cloudmark
April 2012
Redaction of Potentially Sensitive Data from Mail Abuse Reports
メール乱用レポートからの機密データの秘匿化
Abstract
概要
Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively.
電子メールメッセージには、多くの場合、規制または社会規範のいずれかに従って、プライベートまたは機密と見なされる可能性がある情報が含まれています。そのようなメッセージが他のエンティティと共有することを目的としたレポートの件名になると、レポートジェネレータはメッセージの機密部分を編集または削除することを望む場合があります。このメモは効果的にそうするための一つの方法を提案します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc6590.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6590で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Key Words .......................................................3
3. Recommended Practice ............................................3
4. Transformation Mechanisms .......................................4
5. Security Considerations .........................................5
5.1. General ....................................................5
5.2. Digest Collisions ..........................................5
5.3. Information Not Redacted ...................................5
6. Privacy Considerations ..........................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Appendix A. Example ................................................7
Appendix B. Acknowledgements .......................................8
The Abuse Reporting Format [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye toward automating both the generation and consumption of those reports.
乱用報告フォーマット[ARF]は、メッセージングインフラストラクチャで乱用のレポートを送信するためのメッセージフォーマットを定義し、これらのレポートの生成と消費の両方の自動化を目指しています。
For privacy considerations, it might be the policy of a report generator to anonymize, or obscure, portions of the report that might identify an end user who caused the report to be generated. This has come to be known in feedback loop parlance as "redaction". Precisely how this is done is unspecified in [ARF], as it will generally be a matter of local policy. That specification does admonish generators against being too overzealous with this practice, as obscuring too much data makes the report non-actionable.
プライバシーを考慮して、レポートの生成を引き起こしたエンドユーザーを特定する可能性があるのは、レポートの一部を匿名化または不明瞭にすることです。これは、フィードバックループ用語では「修正」として知られるようになりました。これがどのように行われるかは正確には[ARF]で規定されていません。これは一般的にローカルポリシーの問題になるためです。その仕様は、あまりにも多くのデータを覆い隠すとレポートが実行不能になるため、ジェネレーターがこの慣習に熱狂しすぎないように警告します。
Previous redaction practices, such as replacing local-parts of addresses with a uniform string like "xxxxxxxx", frustrated any kind of prioritizing or grouping of reports. This memo presents a practice for conducting redaction in a manner that allows a report receiver to detect that two reports were caused by the same end user, without revealing the identity of that user. That is, the report receiver can use the redacted string, such as an obscured email address, to determine that two such unredacted strings were identical; the reports originally contained the same address.
アドレスのローカル部分を「xxxxxxxx」のような統一された文字列に置き換えるなど、以前の秘匿化のプラクティスは、あらゆる種類のレポートの優先順位付けまたはグループ化に不満を感じていました。このメモは、レポートの受信者が2つのレポートが同じエンドユーザーによって引き起こされたことを、そのユーザーの身元を明かさずに検出できるように、編集を実行する方法を示しています。つまり、レポートの受信者は、隠された電子メールアドレスなどの編集された文字列を使用して、そのような2つの編集されていない文字列が同一であると判断できます。レポートには元々同じアドレスが含まれていました。
Generally, it is assumed that the recipient-identifying fields of a message, when copied into a report, are to be obscured to protect the identity of the end user who submitted the complaint about the message. However, it is also presumed that other data will be left intact, and those data could be correlated against log files or other resources to determine the intended recipient of the original message.
一般に、メッセージの受信者を識別するフィールドは、レポートにコピーされるときに、メッセージに関する苦情を提出したエンドユーザーの身元を保護するために隠蔽されると想定されています。ただし、他のデータはそのまま残され、それらのデータをログファイルや他のリソースと関連付けて、元のメッセージの目的の受信者を特定することもできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
When redacting of reports is desired, in order to enable a report receiver to correlate reports that might refer to a common but anonymous source, the report generator SHOULD use the following practice:
レポートの編集が必要な場合、レポートレシーバーが共通の匿名ソースを参照する可能性のあるレポートを関連付けることができるように、レポートジェネレーターは次の方法を使用する必要があります（SHOULD）。
1. Select a transformation mechanism (see Section 4) that is consistent (i.e., the same input string produces the same output each time) and reasonably collision-resistant (i.e., two different inputs are unlikely to produce the same output).
1. 一貫性があり（つまり、同じ入力文字列が毎回同じ出力を生成する）、衝突への耐性が高い（つまり、2つの異なる入力が同じ出力を生成する可能性は低い）変換メカニズムを選択します（セクション4を参照）。
2. Identify string(s) (such as local-parts of email addresses) in a message that need to be redacted. Call these strings the "private data".
2. 編集する必要があるメッセージ内の文字列（メールアドレスのローカル部分など）を特定します。これらの文字列を「プライベートデータ」と呼びます。
3. For each piece of private data, apply the selected transformation mechanism.
3. 個人データごとに、選択した変換メカニズムを適用します。
4. If the output of the transformation can contain bytes that are not printable ASCII, or if the output can include characters not appropriate to replace the private data directly, encode the output with the base64 algorithm as defined in Section 4 of [BASE64], or some similar translation, to form a valid replacement in the original context. For example, replacing a local-part in an email address with transformation output containing an "@" character (ASCII 0x40) or a space character (ASCII 0x20) is not permitted by the specification for local-part [SMTP], so the transformation output needs to be encoded as described.
4. 変換の出力に、印刷可能なASCIIではないバイトが含まれる場合、またはプライベートデータを直接置き換えるのに適さない文字が出力に含まれる場合は、[BASE64]のセクション4で定義されているbase64アルゴリズムまたは元のコンテキストで有効な置換を形成するための同様の翻訳。たとえば、メールアドレスのローカル部分を「@」文字（ASCII 0x40）またはスペース文字（ASCII 0x20）を含む変換出力で置き換えることは、ローカル部分[SMTP]の仕様で許可されていないため、変換説明どおりに出力をエンコードする必要があります。
5. Replace each instance of private data with the corresponding (possibly encoded) transformation when generating the report. Note that the replaced text could also be in a context that has constraints, such as length limits that need to be observed.
5. レポートを生成するときに、プライベートデータの各インスタンスを対応する（エンコードされている可能性がある）変換に置き換えます。置き換えられたテキストは、長さの制限など、遵守する必要がある制約があるコンテキストにある可能性があることに注意してください。
This has the effect of obscuring the data (in a potentially irreversible way) while still allowing the report recipient to observe that numerous reports are about one particular end user. Such detection enables the receiver to prioritize its reactions based on problems that appear to be focused on specific end users that may be under attack.
これは、データを覆い隠し（元に戻せない可能性のある方法で）、その一方で、レポートの受信者が多数のレポートが特定のエンドユーザーに関するものであることを確認できるようにします。このような検出により、受信者は、攻撃を受けている可能性のある特定のエンドユーザーに集中しているように見える問題に基づいて、その反応に優先順位を付けることができます。
This memo does not specify a particular transformation mechanism as a requirement. The interoperability that this memo seeks to provide is enabled by the consistency of the transformation.
このメモは、特定の変換メカニズムを要件として指定していません。このメモが提供しようとする相互運用性は、変換の一貫性によって可能になります。
Dealing with the issue of the security of the transformation (i.e., frustrating attempts to reverse the transformation) is a matter of local policy. A continuum of possible transformations exists, from trivial ones such as rot13, CRC32, and base64, through strong cryptographic encodings such as the Hashed Message Authentication Code [HMAC] and even full encryption, or private transformations such as mapping an email address to an internal customer number. An operator wishing to perform report redaction needs to select a consistent transformation that obscures the private data and is resilient to attempts to extract the original data to the extent required by local policy, keeping in mind that the environment in which the transformation is operating is not a highly secure one. See Section 5.3 for further details of this issue.
変革の安全性の問題（つまり、変革を元に戻すための苛立たしい試み）に対処することは、ローカルポリシーの問題です。 rot13、CRC32、base64などの自明な変換から、ハッシュメッセージ認証コード[HMAC]などの強力な暗号化エンコーディング、さらには完全な暗号化、または電子メールアドレスを内部にマッピングするなどのプライベート変換を通じて、可能な変換の連続が存在します。顧客番号。レポートの墨消しを実行するオペレーターは、プライベートデータを覆い隠し、ローカルポリシーで必要な範囲まで元のデータを抽出しようとする耐性がある一貫した変換を選択する必要があります。安全性の高いもの。この問題の詳細については、セクション5.3を参照してください。
An implementation MAY choose any transformation that has a reasonably low likelihood of collision.
実装は、衝突の可能性がかなり低い変換を選択してもよい（MAY）。
General security issues with respect to these reports are found in [ARF].
これらのレポートに関する一般的なセキュリティ問題は[ARF]にあります。
Message digest collisions are a well-understood issue. Their application here involves a report receiver improperly concluding that two pieces of redacted information were originally the same when in fact they are not. This can lead to a denial of service, where the inadvertently improper application of complaint data causes unjustified corrective action. Such cases are sufficiently unlikely as to be of little concern.
メッセージダイジェストの衝突はよく理解されている問題です。ここでのアプリケーションには、編集された2つの情報が元々同じであるにもかかわらず実際は同じではないと誤って結論づけるレポートレシーバーが含まれます。これにより、サービス拒否が発生する可能性があり、不注意による不適切な苦情データの適用により、不当な是正措置が行われます。このような場合は、ほとんど問題になることはほとんどありません。
Although the identity of the user causing a report to be generated can be obscured using this mechanism, other properties of a message (such as the Message-ID field) that are not redacted could be used to recover the original data by locating them in the message logs of the originating system or via other data correlation techniques. It is incumbent on the report generator to anticipate and redact or otherwise obscure such data, or accept that such recovery is possible even from the very simplest kinds of feedback.
このメカニズムを使用すると、レポートの生成を引き起こしているユーザーのIDを隠すことができますが、編集されていないメッセージの他のプロパティ（Message-IDフィールドなど）を使用して、元のデータを元のシステムのメッセージログ、または他のデータ相関手法。そのようなデータを予測して編集または不明瞭にすること、または非常に単純な種類のフィードバックからでもそのような回復が可能であることを受け入れることは、レポートジェネレーターの義務です。
It is for this reason that the normative portions of this memo do not include stronger assertions about cryptography used in the transformation. Given the ultimate recoverability of the redacted information, the cryptographic strength of the transformation is not a critical security measure.
このため、このメモの規範的な部分には、変換で使用される暗号化についてのより強力な主張が含まれていません。編集された情報の最終的な回復可能性を考えると、変換の暗号強度は重要なセキュリティ対策ではありません。
The process of redacting a feedback report satisfies a privacy requirement established by local policy, and is not meant to provide strong security properties.
フィードバックレポートを編集するプロセスは、ローカルポリシーによって確立されたプライバシー要件を満たし、強力なセキュリティプロパティを提供するためのものではありません。
[FBL-BCP] and Section 8 of [ARF] discuss topics related to establishment of bilateral agreements between report producers and consumers. The issues raised here are also things to be considered when establishing such agreements.
[FBL-BCP]および[ARF]のセクション8では、レポートの作成者と消費者の間の二国間協定の確立に関連するトピックについて説明します。ここで提起される問題は、そのような合意を確立する際に考慮すべきことでもあります。
While the method of redaction described in this document may reduce the likelihood of some types of private data from leaking between ADministrative Management Domains (ADMDs), it is extremely unlikely that report generation software could ever be created to recognize all of the different ways that private information could be expressed through human written language. If further protections are required, implementers may wish to consider establishing some sort of out-of-band arrangements between the relevant entities, to contain private data as much as possible.
このドキュメントで説明されている墨消しの方法により、管理用管理ドメイン（ADMD）間で一部のタイプのプライベートデータが漏洩する可能性が低くなる可能性がありますが、レポート生成ソフトウェアを作成して、プライベートデータのさまざまな方法をすべて認識することはほとんどありません。情報は人間の書き言葉で表現できます。さらなる保護が必要な場合、実装者は、関係するエンティティ間に何らかの種類の帯域外配置を確立して、プライベートデータをできるだけ含めることを検討できます。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能な形式」、RFC 5965、2010年8月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[FBL-BCP] Falk, J., Ed., "Complaint Feedback Loop Operational Recommendations", RFC 6449, November 2011.
[FBL-BCP] Falk、J.、Ed。、「Complaint Feedback Loop Operational Recommendations」、RFC 6449、2011年11月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
Assume the following input message:
次の入力メッセージを想定します。
From: alice@example.com
To: bob@example.net
Subject: Make money fast!
Message-ID: <123456789@mailer.example.com>
Date: Thu, 17 Nov 2011 22:19:40 -0500
Want to make a lot of money really fast? Check it out!
http://www.example.com/scam/0xd0d0cafe
On receipt, bob@example.net reports this message as abusive through whatever mechanism his mailbox provider has established. This causes an [ARF] message to be generated. However, example.net wishes to obscure Bob's email address lest it be relayed to the offending agent, which could lead to more trouble for Bob.
受信すると、bob @ example.netは、メールボックスプロバイダーが確立したメカニズムを介して、このメッセージを不正であると報告します。これにより、[ARF]メッセージが生成されます。ただし、example.netはボブのメールアドレスを不明瞭にしたいと考えています。ボブの問題がさらに増える可能性があるため、問題のエージェントにリレーされることはありません。
Thus, example.net plans to redact the local-part of the recipient address in the To: field. Local policy and security requirements suggest that the algorithm known as "H" (a hash of a key concatenated with the data to be obscured) using SHA1 is adequate. It has thus selected a redaction key of "potatoes", and the private data in this case is the string "bob". The concatenation of "potatoesbob" is digested with SHA1 and then base64-encoded to the string "rZ8cqXWGiKHzhz1MsFRGTysHia4=".
したがって、example.netは、宛先フィールドの受信者アドレスのローカル部分を編集することを計画しています。ローカルポリシーとセキュリティ要件は、SHA1を使用した「H」（隠蔽されるデータと連結されたキーのハッシュ）として知られるアルゴリズムが適切であることを示唆しています。したがって、「ジャガイモ」の墨消しキーが選択され、この場合のプライベートデータは文字列「bob」です。 "potatoesbob"の連結はSHA1でダイジェストされ、base64でエンコードされて文字列 "rZ8cqXWGiKHzhz1MsFRGTysHia4 ="にエンコードされます。
Therefore, when constructing the ARF message in response to Bob's complaint, the following form of the received message is used in the third part of the ARF report:
したがって、ボブの苦情に応じてARFメッセージを作成する場合、受信したメッセージの次の形式がARFレポートの3番目の部分で使用されます。
From: alice@example.com
To: rZ8cqXWGiKHzhz1MsFRGTysHia4=@example.net
Subject: Make money fast!
Message-ID: <123456789@mailer.example.com>
Date: Thu, 17 Nov 2011 22:19:40 -0500
Want to make a lot of money really fast? Check it out!
http://www.example.com/scam/0xd0d0cafe
Note, however, that it is possible that the redacted information can be recovered by agents at example.com searching their logs for the original envelope associated with the message, by correlating with the Message-ID contents, which were not redacted here. It is expected that feedback loops generating such reports involve senders that have been vetted against such information leakage.
ただし、編集された情報は、example.comのエージェントが、ここで編集されなかったメッセージIDの内容と関連付けることにより、メッセージに関連付けられた元のエンベロープのログを検索することで復元できる可能性があることに注意してください。このようなレポートを生成するフィードバックループには、このような情報漏えいを厳しくチェックされた送信者が関与することが予想されます。
Much of the text in this document was initially moved from other MARF working group documents, with contributions from Monica Chew, Tim Draegen, Michael Adkins, and other members of the Messaging Anti-Abuse Working Group. Additional feedback was provided by John Levine, S. Moonesamy, Alessandro Vesely, and Mykyta Yevstifeyev.
このドキュメントのテキストの多くは、他のMARFワーキンググループドキュメントから移動されたもので、モニカチュー、ティムドレーゲン、マイケルアドキンス、およびメッセージング反乱用ワーキンググループの他のメンバーからの寄稿も含まれています。追加のフィードバックは、John Levine、S。Moonesamy、Alessandro Vesely、およびMykyta Yevstifeyevから提供されました。
Authors' Addresses
著者のアドレス
J.D. Falk (editor) Return Path 100 Mathilda Place, Suite 100 Sunnyvale, CA 94086 US
J.D.フォーク（編集者）Return Path 100 Mathilda Place、Suite 100 Sunnyvale、CA 94086 US
EMail: ietf@cybernothing.org
URI: http://www.returnpath.net/
M. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
M.クチェラウィ（編集者）Cloudmark 128 King St.、2nd Floor San Francisco、CA 94107 US
EMail: msk@cloudmark.com