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
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
普适监控（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会议的技术全体会议[IETF88全体会议]上讨论了普遍监控，然后通过广泛交换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的动机与IETF协议中PM的缓解方式无关。
"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
虽然PM是一种攻击，但符合PM定义的其他形式的监控可能是有益的，而不是任何攻击的一部分，例如，网络管理功能监控数据包或流以及反垃圾邮件
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缓解措施的一部分，例如，证书透明[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问题，更广泛的互联网社区需要站出来解决它。
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将努力制定规范，以缓解普遍的监控攻击。
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社区的共识。
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节专门将监视视为一种综合安全隐私威胁。
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技术全体会议的与会者的反馈。特别感谢以下人士提供有用的建议或意见：贾里·阿尔科、弗雷德·贝克、马克·布兰切特、蒂姆·布雷、斯科特·布里姆、兰迪·布什、布赖恩·卡彭特、贝诺特·克莱斯、艾莉莎·库珀、戴夫·克罗克、斯宾塞·道金斯、艾弗里·多里亚、卫斯理·艾迪、阿德里安·法雷尔、约瑟夫·洛伦佐·霍尔、菲利普·哈勒姆·贝克、泰德·哈迪、萨姆·哈特曼、保罗·霍夫曼、，比约恩·霍尔曼、罗斯·霍斯利、乔尔·贾格利、斯蒂芬·肯特、艾略特·李尔、巴里·莱巴、特德·莱蒙、苏布拉曼尼亚·穆内萨米、埃里克·诺德马克、皮特·雷斯尼克、彼得·圣安德烈、安德鲁·沙利文、肖恩·特纳、尼古拉斯·韦弗、斯特凡·温特和劳埃德·伍德。此外，我们还要感谢所有就如何改善互联网安全和隐私提出建议或在各种IETF邮件列表（如ietf@ietf.org和perpass@ietf.org名单。
[IETF88Plenary] IETF, "IETF 88 Plenary Meeting Materials", November 2013, <http://www.ietf.org/proceedings/88/>.
[IETF88全体会议]IETF，“IETF88全体会议材料”，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关于加密技术和互联网的声明”，RFC 1984，1996年8月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804]IAB和IESG，“IETF关于窃听的政策”，RFC28042000年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.和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC5741]Daigle，L.，Kolkman，O.，和IAB，“RFC流，标题和样板”，RFC 57412009年12月。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013.
[RFC6962]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，RFC 69622013年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 69732013年7月。
Authors' Addresses
作者地址
Stephen Farrell Trinity College Dublin Dublin 2 Ireland
斯蒂芬·法雷尔三一学院都柏林爱尔兰都柏林2
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
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大厅
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at