RFC7258：Pervasive Monitoring Is an Attack，May 2014
摘要
普遍监控是一种技术攻击，在可能的情况下，应在IETF协议的设计中予以缓解。
关于本备忘录
本备忘录记录了互联网最佳实践。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已由互联网工程指导小组（IESG）批准出版。RFC 5741第2节提供了有关BCP的更多信息。
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7258.
版权声明
版权所有（c）2014 IETF Trust和文件作者。保留所有权利。
本文件受BCP 78和IETF信托基金有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含《信托法律条款》第4.e节中所述的简化BSD许可文本，并且不提供简化BSD协议中所述担保。
1、 普遍监控是对隐私的广泛攻击
普遍性监控（Pervasive Monitoring，PM）是通过侵入式收集协议人工制品（包括应用程序内容或协议元数据，如报文头）进行的广泛（通常是隐蔽的）监控。主动或被动窃听和流量分析（例如，相关性、定时或测量数据包大小），或破坏用于保护协议的加密密钥，也可以作为普遍监控的一部分。PM的特点是不分青红皂白，规模非常大，而不是引入新类型的技术妥协。
IETF社区的技术评估认为，PM是对互联网用户和组织隐私的攻击。IETF团体已表示强烈同意PM是一种攻击，需要通过设计使PM更加昂贵或不可行的协议来尽可能减轻。2013年11月IETF会议[IETF88Lenary]的技术全体会议上讨论了普遍监控，然后通过IETF邮件列表上的广泛交流进行了讨论。本文件记录了IETF团体的共识，并确立了PM的技术性质。
这里使用的术语“攻击”在技术意义上与普通英语用法有所不同。在常见的英语用法中，攻击是对手实施的一种攻击行为，旨在将对手的意志强加给被攻击的一方。此处使用的术语是指未经通信方同意而破坏通信方意图的行为。攻击可能会改变通信的内容，记录通信的内容或外部特征，或通过与其他通信事件的关联，泄露双方不打算透露的信息。它还可能具有类似地颠覆传播者意图的其他效果。[RFC4949]包含“攻击”一词的更完整定义。我们在这里也使用单数形式的术语，尽管PM实际上可能由多方面的协同攻击组成。
特别是，术语“攻击”，从技术上讲，并不意味着行为者发动攻击的动机。PM的动机可能包括非针对性的国家监控，商业企业出于合法但不利于隐私的目的，以及犯罪分子的非法行为。无论动机如何，都可以使用相同的技术来实现PM。因此，我们无法在防御最邪恶的行为者的同时，允许其他行为者进行监控，无论有些人认为他们有多仁慈，因为攻击者所需的行动与其他攻击无法区分。因此，PM的动机与IETF协议中如何减轻PM无关。
2、 IETF将致力于缓解普遍监控
“缓解”是一个技术术语，并不意味着完全阻止或挫败攻击的能力。缓解PM的协议不会阻止攻击，但可以显著改变威胁。（请参阅RFC 4949第24页上的图表，了解“攻击”和“威胁”这两个词是如何关联的。）这可以显著增加攻击的成本，迫使隐蔽的东西变成公开的，或者使攻击更有可能被检测到，可能在以后。
IETF标准已经提供了保护互联网通信的机制，并且有在协议设计中应用这些机制的指南[RFC3552]。但这些标准通常不涉及PM、协议元数据的保密性、对抗流量分析或数据最小化。在所有情况下，仍有一些隐私相关信息不可避免地被协议披露。随着技术的进步，曾经只有资金雄厚的行为者才能使用的技术变得更加普及。因此，缓解PM是一种针对各种类似攻击的保护措施。
因此，重新审视我们标准的安全和隐私财产是及时的。IETF将致力于减轻PM的技术方面，就像我们对协议漏洞所做的那样。随着缓解和攻击技术的发展，IETF协议缓解PM的方式将随着时间的推移而改变，因此这里不再描述。
制定IETF规范的人员需要能够描述他们是如何考虑PM的，并且如果攻击与要发布的工作相关，则能够证明相关设计决策的合理性。这并不意味着IETF文档中需要新的“普遍监控注意事项”部分。这意味着，如果被问及，“普遍监控是否与这项工作相关？如果是，是如何考虑的？”
特别是，体系结构决策（包括重用哪些现有技术）可能会严重影响协议对PM的脆弱性。因此，制定IETF规范的人员在做出体系结构决策时需要考虑减轻PM。对体系结构决策进行充分、早期的审查，包括是否可以对PM进行适当的缓解，这一点很重要。在过程后期重新考虑这些架构决策是非常昂贵的。
虽然PM是一种攻击，但可能符合PM定义的其他形式的监视可能是有益的，而不是任何攻击的一部分，例如，网络管理功能监视数据包或流，反垃圾邮件机制需要查看邮件消息内容。某些监控甚至可以作为PM缓解措施的一部分，例如，证书透明度[RFC6962]涉及以可以检测某些PM攻击技术的方式监控公钥基础设施。然而，监控机制显然有可能被滥用于PM，因此在协议设计中需要仔细考虑这种紧张关系。使网络无法管理以缓解PM不是一个可接受的结果，但忽视PM将违背此处记录的共识。随着时间的推移，当考虑到这种紧张局势的实际情况时，将出现适当的平衡。
最后，IETF作为一个标准开发组织，不控制我们规范的实现或部署（尽管IETF参与者确实开发了许多实现），也不标准化协议栈的所有层。此外，缓解普遍监控的非技术（例如，法律和政治）方面不在IETF的范围内。如果要全面解决PM问题，更广泛的互联网社区将需要向前迈进。
总结：当前的能力允许一些参与者以前所未有的规模监控互联网上的内容和元数据。这种无处不在的监控是对互联网隐私的攻击。IETF将努力制定规范，以减轻普遍监控攻击。
3、 进程笔记
过去，此类架构声明（如[RFC1984]和[RFC2804]）已作为互联网工程指导小组（IESG）和互联网架构委员会（IAB）的联合产品发布。然而，自这些文件发布以来，IETF和IAB已将其发布“流”分开，如[RFC4844]和[RFC5741]所述。本文件是在IESG和IAB讨论后发起的，但作为IETF流共识文件发布，以确保其正确反映整个IETF社区的共识。
4、 安全注意事项
本文档完全涉及隐私。有关安全和隐私威胁之间关系的更多信息，请参见[RFC6973]。[RFC6973]第5.1.1节专门将监视作为一种综合安全隐私威胁。
5、 参考资料
[IETF88Plenary]IETF, "IETF 88 Plenary Meeting Materials", November 2013, <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. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013. [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.
