Internet Engineering Task Force (IETF) T. Hardie
Request for Comments: 8165 May 2017
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Hardie
Request for Comments: 8165 May 2017
Category: Informational
ISSN: 2070-1721
Design Considerations for Metadata Insertion
元数据插入的设计注意事项
Abstract
摘要
The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.
IAB发布了RFC 7624，以回应几起互联网通信普遍受到攻击的事件。本文档考虑了将元数据与加密流关联的协议设计的含义。特别是，它断言，仅通过主机上的显式操作共享元数据的设计比中间盒插入元数据的设计更可取。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8165.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8165.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Design Pattern ..................................................2
4. Advice ..........................................................3
5. Deployment Considerations .......................................4
6. IANA Considerations .............................................5
7. Security Considerations .........................................5
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
Acknowledgements ...................................................7
Author's Address ...................................................7
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Design Pattern ..................................................2
4. Advice ..........................................................3
5. Deployment Considerations .......................................4
6. IANA Considerations .............................................5
7. Security Considerations .........................................5
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
Acknowledgements ...................................................7
Author's Address ...................................................7
To minimize the risks associated with pervasive surveillance, it is necessary for the Internet technical community to address the vulnerabilities exploited in the attacks documented in [RFC7258] and the threats described in [RFC7624]. The goal of this document is to address a common design pattern that emerges from the increase in encryption: explicit association of metadata that would previously have been inferred from the plaintext protocol.
为了最大限度地降低与普遍监视相关的风险，互联网技术界有必要解决[RFC7258]中记录的攻击中利用的漏洞和[RFC7624]中描述的威胁。本文档的目标是解决加密增加后出现的一种常见设计模式：元数据的显式关联，这种关联以前是从明文协议推断出来的。
This document makes extensive use of standard security and privacy terminology; see [RFC4949] and [RFC6973]. Readers should be familiar with the terms defined in [RFC6973], including "Eavesdropper", "Observer", "Initiator", "Intermediary", "Recipient", "Attack" (in a privacy context), "Correlation", "Fingerprint", "Traffic Analysis", and "Identifiability" (and related terms). Readers should also be familiar with terms that are specific to the attacks discussed in [RFC7624], including "Pervasive Attack", "Passive Pervasive Attack", "Active Pervasive Attack", "Observation", "Inference", and "Collaborator".
本文件广泛使用标准安全和隐私术语；参见[RFC4949]和[RFC6973]。读者应熟悉[RFC6973]中定义的术语，包括“窃听者”、“观察者”、“发起人”、“中间人”、“接收者”、“攻击”（在隐私上下文中）、“相关性”、“指纹”、“流量分析”和“可识别性”（以及相关术语）。读者还应熟悉[RFC7624]中讨论的特定于攻击的术语，包括“普遍攻击”、“被动普遍攻击”、“主动普遍攻击”、“观察”、“推理”和“合作者”。
One of the core mitigations for the loss of confidentiality in the presence of pervasive surveillance is data minimization, which limits the amount of data disclosed to those elements absolutely required to complete the relevant protocol exchange. When data minimization is in effect, some information that was previously available may be removed from specific protocol exchanges. The information may be removed explicitly (for example, by a browser suppressing cookies
在普遍监视的情况下，减少机密性损失的核心措施之一是数据最小化，这限制了向完成相关协议交换绝对需要的元素披露的数据量。当数据最小化生效时，可以从特定协议交换中删除以前可用的一些信息。可以明确删除该信息（例如，通过浏览器）
during private modes) or by other means. As noted in [RFC7624], some topologies that aggregate or alter the network path also act to reduce the ease with which metadata is available to eavesdroppers.
在专用模式下）或通过其他方式。如[RFC7624]中所述，一些聚合或改变网络路径的拓扑也会降低元数据对窃听者的可用性。
In some cases, other actors within a protocol context will continue to have access to the information that has been thus withdrawn from specific protocol exchanges. If those actors attach the information as metadata to those protocol exchanges, the confidentiality effect of data minimization is lost.
在某些情况下，议定书范围内的其他行为者将继续获得因此从特定议定书交换中撤回的信息。如果这些参与者将信息作为元数据附加到这些协议交换中，则数据最小化的保密效果将丢失。
Restoring information is particularly tempting at systems not primarily deployed to increase confidentiality. A proxy providing compression, for example, may wish to restore the identity of the requesting party; similarly, a VPN system used to provide channel security may believe that the origin IP should be restored. Actors considering restoring metadata may believe that they understand the relevant privacy considerations or believe that, because the primary purpose of the service was not privacy-related, none exist. Examples of this design pattern include [RFC7239] and [RFC7871].
在并非主要用于提高机密性的系统上，恢复信息尤其诱人。例如，提供压缩的代理可能希望恢复请求方的身份；类似地，用于提供通道安全性的VPN系统可能认为应该恢复源IP。考虑恢复元数据的参与者可能认为他们了解相关的隐私考虑，或者认为，由于服务的主要目的与隐私无关，因此不存在任何服务。此设计模式的示例包括[RFC7239]和[RFC7871]。
Avoid inserting metadata to restore information that would otherwise be unavailable to later participants in a protocol exchange. It contributes to the overall loss of confidentiality for the Internet and trust in the Internet as a medium. Do not add metadata to flows at intermediary devices unless a positive affirmation of approval for restoration has been received from the actor whose data will be added.
避免插入元数据以恢复协议交换中的后续参与者无法使用的信息。它导致了对互联网的整体保密性和对互联网作为媒介的信任的丧失。除非已从将添加数据的参与者处收到恢复批准的肯定确认，否则不要将元数据添加到中间设备的流中。
Instead, design the protocol so that the actor can add such metadata themselves so that it flows end to end, rather than requiring the action of other parties. In addition to improving privacy, this approach ensures consistent availability between the communicating parties, no matter what path is taken. (Note that this document does not attempt to describe how an actor sets policies on providing this metadata, as the range of systems that might be implied is very broad).
相反，应该设计协议，以便参与者可以自己添加此类元数据，从而使其端到端地流动，而不需要其他方的操作。除了改善隐私外，这种方法还确保了通信双方之间的一致可用性，无论采用何种路径。（请注意，本文档并不试图描述参与者如何设置提供此元数据的策略，因为可能隐含的系统范围非常广泛）。
As an example, RFC 7871 describes a method that had already been deployed and notes that it is unlikely that a clean-slate design would result in this mechanism. If a clean-slate design were built to follow the advice in this document, that design would likely not use a core element of RFC 7871: rather than adding metadata at a proxy, it would provide facilities for end systems to add it to their initial queries. In the case of RFC 7871, the relevant metadata is relatively easy for an end system to derive, as Session Traversal Utilities for NAT (STUN) [RFC5389] provides a method for learning the
例如，RFC 7871描述了一种已经部署的方法，并指出，干净的设计不太可能产生这种机制。如果按照本文档中的建议构建一个全新的设计，那么该设计很可能不会使用RFC 7871的核心元素：它不会在代理上添加元数据，而是为终端系统提供将其添加到初始查询的工具。在RFC 7871的情况下，由于NAT（STUN）[RFC5389]的会话遍历实用程序提供了一种学习元数据的方法，因此终端系统相对容易导出相关元数据
reflexive transport address from which a client subnet could be derived. This would allow clients to populate this data themselves, thus affirming their consent and providing data at a granularity with which they were comfortable. As in RFC 7871, the addition of this data would require confirmation that the upstream DNS resolver understands what to do with it, but the same negotiation mechanism, an Extension Mechanisms for DNS (EDNS(0)) option [RFC6891], could be used. Because of this negotiation, there would be a new variability in responses that would change the caching behavior for data supplied by participating servers. This is not a major change from the current design, however, as the same considerations set out in Sections 7.3.2 and 7.5 of RFC 7871 would apply to client-supplied subnets as well as to proxy-supplied subnets.
可以从中派生客户端子网的自反传输地址。这将允许客户自己填充这些数据，从而确认他们的同意，并以他们满意的粒度提供数据。与在RFC 7871中一样，添加此数据需要确认上游DNS解析程序了解如何处理它，但可以使用相同的协商机制，DNS扩展机制（EDNS（0））选项[RFC6891]。由于这种协商，响应将出现新的变化，这将改变参与服务器提供的数据的缓存行为。然而，这不是当前设计的主要变化，因为RFC 7871第7.3.2节和第7.5节中规定的相同注意事项将适用于客户提供的子网以及代理提供的子网。
From a protocol perspective, in other words, this approach would be a minor change from RFC 7871, would be as fully featured, and would provide better privacy properties than the on-path update mechanism RFC 7871 provides. The next section examines why, despite this, deployment considerations have sometimes trumped cleaner designs.
换言之，从协议的角度来看，该方法与RFC 7871相比只是一个小改动，功能齐全，并提供比路径更新机制RFC 7871更好的隐私属性。下一节将探讨为什么尽管如此，部署考虑有时胜过更干净的设计。
There are a few common tensions associated with the deployment of systems that restore metadata. The first is the trade-off in speed of deployment for different actors. The Forwarded HTTP Extension in [RFC7239] provides an example of this. When used with a proxy, it restores information related to the original requesting party, thus allowing a responding server to tailor responses according to the original party's region, network, or other characteristics associated with the identity. It would, of course, be possible for the originating client to add this data itself, after using STUN [RFC5389] or a similar mechanism to first determine the information to declare. This would require, however, full specification and adoption of this mechanism by the end systems. It would not be available at all during this period and would thereafter be limited to systems that have been upgraded to include it. The long tail of browser deployments indicates that many systems might go without upgrades for a significant period of time. The proxy infrastructure, in contrast, is commonly under more active management and represents a much smaller number of elements; this impacts both the general deployment difficulty and the number of systems that the origin server must trust.
在部署恢复元数据的系统时，存在一些常见的紧张关系。首先是不同行为者在部署速度上的权衡。[RFC7239]中的转发HTTP扩展提供了一个例子。当与代理一起使用时，它恢复与原始请求方相关的信息，从而允许响应服务器根据原始方的区域、网络或与身份相关的其他特征定制响应。当然，在使用STUN[RFC5389]或类似机制首先确定要声明的信息之后，原始客户端可能会自己添加此数据。然而，这需要终端系统对该机制进行全面规范和采用。在这段时间内，它将完全不可用，此后将仅限于已升级以包含它的系统。浏览器部署的长尾效应表明，许多系统可能在相当长的一段时间内没有升级。相反，代理基础设施通常处于更积极的管理之下，所代表的元素数量要少得多；这会影响总体部署难度和源服务器必须信任的系统数量。
The second common tension is between metadata minimization and the desire to tailor content responses. For origin servers whose content is common across users, the loss of metadata may have limited impact on the system's functioning. For other systems, which commonly tailor content by region or network, the loss of metadata may imply a
第二种常见的紧张关系是元数据最小化和定制内容响应之间的矛盾。对于跨用户共享内容的源服务器，元数据的丢失对系统功能的影响可能有限。对于通常按区域或网络定制内容的其他系统，元数据的丢失可能意味着
loss of functionality. Where the user desires this functionality, restoration can commonly be achieved by the use of other identifiers or login procedures. Where the user does not desire this functionality, but it is a preference of the server or a third party, adjustment is more difficult. At the extreme, content blocking by network origin may be a regulatory requirement. Trusting a network intermediary to provide accurate data is, of course, fragile in this case, but it may be a part of the regulatory framework.
功能丧失。如果用户需要此功能，通常可以通过使用其他标识符或登录过程来实现恢复。如果用户不需要此功能，但这是服务器或第三方的首选，则调整会更加困难。在极端情况下，由网络来源阻止内容可能是一项监管要求。当然，在这种情况下，信任网络中介提供准确的数据是脆弱的，但这可能是监管框架的一部分。
There are also tensions with latency of operation. For example, where the end system does not initially know the information that would be added by on-path devices, it must engage the protocol mechanisms to determine it. Determining a public IP address to include in a locally supplied header might require a STUN exchange, and the additional latency of this exchange discourages deployment of host-based solutions. To minimize this latency, engaging those mechanisms may need to be done in parallel with or in advance of the core protocol exchanges with which this metadata would be supplied.
此外，还存在与操作延迟有关的紧张关系。例如，当终端系统最初不知道路径设备将添加的信息时，它必须使用协议机制来确定它。确定要包含在本地提供的头中的公共IP地址可能需要STUN交换，并且此交换的额外延迟不鼓励部署基于主机的解决方案。为了最大限度地减少这种延迟，可能需要在提供元数据的核心协议交换的同时或之前使用这些机制。
These tensions do not change the basic recommendation, but they suggest that the parties who are introducing encryption and data minimization for existing protocols consider carefully whether the work also implies introducing mechanisms for the end-to-end provisioning of metadata when a user has actively consented to provide it.
这些紧张关系并没有改变基本的建议，但是他们建议正在为现有协议引入加密和数据最小化的各方仔细考虑该工作是否也意味着当用户主动同意提供元数据时，端到端提供元数据的机制。
This document makes no request of IANA.
本文件未向IANA提出任何要求。
This memorandum describes a design pattern emerging from responses to the attacks described in [RFC7258]. Continued use of this design pattern, which uses mid-flow devices to restore metadata, lowers the impact of mitigations to that attack.
本备忘录描述了[RFC7258]中描述的攻击响应中出现的设计模式。继续使用此设计模式（使用中流设备恢复元数据）可以降低对该攻击的缓解影响。
Note that some emergency service recipients, notably PSAPs (Public Safety Answering Points) may prefer data provided by a network to data provided by an end system, because an end system could use false data to attack others or consume resources. While this has the consequence that the data available to the PSAP is often more coarse than that available to the end system, the risk of false data being provided involves a risk to the lives of those targeted.
请注意，一些紧急服务接受者，尤其是PSAP（公共安全应答点），可能更喜欢网络提供的数据而不是终端系统提供的数据，因为终端系统可能使用虚假数据攻击他人或消耗资源。虽然这导致PSAP可用的数据通常比终端系统可用的数据更粗糙，但提供虚假数据的风险涉及目标用户的生命风险。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/info/rfc7624>.
[RFC7624]Barnes，R.，Schneier，B.，Jennings，C.，Hardie，T.，Trammell，B.，Huitema，C.，和D.Borkmann，“面对普遍监视的保密性：威胁模型和问题陈述”，RFC 7624，DOI 10.17487/RFC76242015年8月<http://www.rfc-editor.org/info/rfc7624>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<http://www.rfc-editor.org/info/rfc6891>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, DOI 10.17487/RFC7239, June 2014, <http://www.rfc-editor.org/info/rfc7239>.
[RFC7239]Peterson，A.和M.Nilsson，“转发HTTP扩展”，RFC 7239，DOI 10.17487/RFC7239，2014年6月<http://www.rfc-editor.org/info/rfc7239>.
[RFC7687] Farrell, S., Wenning, R., Bos, B., Blanchet, M., and H. Tschofenig, "Report from the Strengthening the Internet (STRINT) Workshop", RFC 7687, DOI 10.17487/RFC7687, December 2015, <http://www.rfc-editor.org/info/rfc7687>.
[RFC7687]Farrell，S.，Wenning，R.，Bos，B.，Blanchet，M.，和H.Tschofenig，“加强互联网（STRINT）研讨会的报告”，RFC 7687，DOI 10.17487/RFC7687，2015年12月<http://www.rfc-editor.org/info/rfc7687>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <http://www.rfc-editor.org/info/rfc7871>.
[RFC7871]Contavalli，C.，van der Gaast，W.，Lawrence，D.，和W.Kumari，“DNS查询中的客户端子网”，RFC 7871，DOI 10.17487/RFC7871，2016年5月<http://www.rfc-editor.org/info/rfc7871>.
Acknowledgements
致谢
This document is derived in part from the work initially done on the perpass mailing list and at the STRINT workshop [RFC7687]. The text was originally developed by the IAB's Privacy and Security Program before submission to the IETF. The document also benefited from an extensive review by Mohamed Boucadair.
本文件部分源自perpass邮件列表和STRINT研讨会[RFC7687]最初完成的工作。该文本最初是由IAB的隐私和安全计划在提交给IETF之前开发的。该文件还得益于穆罕默德·布卡代尔的广泛审查。
Author's Address
作者地址
Ted Hardie
泰德·哈迪
Email: ted.ietf@gmail.com
Email: ted.ietf@gmail.com