Internet Architecture Board (IAB) S. Farrell
Request for Comments: 7687 Trinity College, Dublin
Category: Informational R. Wenning
ISSN: 2070-1721 B. Bos
W3C
M. Blanchet
Viagenie
H. Tschofenig
ARM Ltd.
December 2015
Internet Architecture Board (IAB) S. Farrell
Request for Comments: 7687 Trinity College, Dublin
Category: Informational R. Wenning
ISSN: 2070-1721 B. Bos
W3C
M. Blanchet
Viagenie
H. Tschofenig
ARM Ltd.
December 2015
Report from the Strengthening the Internet (STRINT) Workshop
加强互联网（STRINT）研讨会报告
Abstract
摘要
The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.
加强互联网（STRINT）研讨会于2014年初在伦敦召开，为期两天，共有100名参与者参加，讨论技术界，尤其是IETF和W3C，应如何应对普遍监控，以及更广泛地说，如何在面对此类攻击时加强互联网。讨论涉及术语、用户界面的作用、缓解类别、一些特定用例、转换策略（包括机会主义加密）等问题。研讨会结束时提出了一些高级别建议，相信这些建议可以实施，并有助于加强互联网。这是该讲习班的报告。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
请注意，本文件是研讨会会议记录的报告。本报告中记录的观点和立场是研讨会参与者的观点和立场，不一定反映IAB的观点和立场。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。IAB批准发布的文件不适用于任何级别的互联网标准；见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/rfc7687.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7687.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Workshop Goals . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. After the Workshop . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Workshop Chairs and Program Committee . . . . . . . 29
Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Workshop Goals . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. After the Workshop . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Workshop Chairs and Program Committee . . . . . . . 29
Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
The technical plenary session at IETF 88 [vancouverplenary] concluded that Pervasive Monitoring (PM) represents an attack on the Internet, and the IETF has begun to carry out the more obvious actions required to try to handle this attack. However, there are much more complex questions arising that need further consideration before any additional concrete plans can be made.
IETF 88的技术全体会议[VancouverConference]得出结论，普及监控（PM）代表了对互联网的攻击，IETF已经开始采取更明显的行动，试图应对这种攻击。然而，在制定任何其他具体计划之前，还需要进一步考虑一些更为复杂的问题。
The W3C (<https://www.w3.org>) and IAB (<https://www.iab.org>) therefore decided to host a workshop on the topic of "Strengthening the Internet Against Pervasive Monitoring" [STRINT] before IETF 89 in London in March 2014. The FP7-funded STREWS project (<https://www.strews.eu/>) organised the STRINT workshop on behalf of the IAB and W3C.
W3C(<https://www.w3.org>)和IAB(<https://www.iab.org>)因此，决定在2014年3月IETF 89在伦敦召开之前，举办一次主题为“加强互联网，防止普遍监控”的研讨会[STRINT]。FP7资助的STREWS项目(<https://www.strews.eu/>)代表IAB和W3C组织了STRINT研讨会。
The main workshop goal was to discuss what can be done, especially by the two standards organisations IETF and W3C, against PM, both for existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones (WebRTC, HTTP/2, etc.).
研讨会的主要目标是讨论如何应对PM，特别是两个标准组织IETF和W3C可以针对现有互联网协议（HTTP/1、SMTP等）和新协议（WebRTC、HTTP/2等）采取哪些措施。
The starting point for the workshop was the existing IETF consensus that PM is an attack [RFC7258] (the text of which had achieved IETF consensus at the time of the workshop, even though the RFC had yet to be published).
研讨会的起点是现有的IETF共识，即PM是一种攻击[RFC7258]（其文本在研讨会时已达成IETF共识，尽管RFC尚未发布）。
The workshop was well attended (registration closed when the maximum capacity of 100 was reached, but more than 150 expressed a desire to register) and several people (about 165 at the maximum) listened to the streaming audio. The submitted papers (67 in total) were generally of good quality and all were published, except for a few where authors who couldn't take part in the workshop preferred not to publish.
研讨会的与会者非常踊跃（当达到最大容量100人时，注册就结束了，但有150多人表示希望注册），有几个人（最多165人）收听了流媒体音频。提交的论文（总共67篇）质量一般都很好，所有论文都发表了，只有少数不能参加研讨会的作者不愿意发表。
The chairs of the workshop summarised the workshop in the final session in the form of the following recommendations:
研讨会主席在最后一届会议上以以下建议的形式总结了研讨会：
1. Well-implemented cryptography can be effective against PM and will benefit the Internet if used more, despite its cost, which is steadily decreasing anyway.
1. 实施良好的加密技术可以有效地对抗PM，如果使用得更多，将使互联网受益，尽管其成本正在稳步下降。
2. Traffic analysis also needs to be considered, but is less well understood in the Internet community: relevant research and protocol mitigations such as data minimisation need to be better understood.
2. 还需要考虑流量分析，但互联网社区对流量分析了解较少：需要更好地了解相关研究和协议缓解措施，如数据最小化。
3. Work should continue on progressing the PM threat model document [Barnes] discussed in the workshop. Subsequent work on this topic resulted in the publication of [RFC7624].
3. 应继续推进研讨会上讨论的PM威胁模型文件[Barnes]。关于这一主题的后续工作导致了[RFC7624]的出版。
4. Later, the IETF may be in a position to start to develop an update to BCP 72 [RFC3552], most likely as a new RFC enhancing that BCP and dealing with recommendations on how to mitigate PM and how to reflect that in IETF work.
4. 随后，IETF可能会开始对BCP 72[RFC3552]进行更新，最有可能是作为一个新的RFC来增强BCP，并处理关于如何缓解PM以及如何在IETF工作中反映PM的建议。
5. The term "opportunistic" has been widely used to refer to a possible mitigation strategy for PM. The community needs to document definition(s) for this term, as it is being used differently by different people and in different contexts. We may also be able to develop a cookbook-like set of related protocol techniques for developers. Since the workshop, the IETF's Security area has taken up this work, most recently favouring the generic term "Opportunistic Security" (OS) [Kent]. Subsequent work on this topic resulted in the publication of a definition of OS in [RFC7435].
5. “机会主义”一词已广泛用于指PM的可能缓解策略。社区需要记录该术语的定义，因为不同的人在不同的环境中使用它。我们还可以为开发人员开发一套类似于烹饪书的相关协议技术。自研讨会以来，IETF的安全领域开始了这项工作，最近支持通用术语“机会主义安全”（OS）[Kent]。关于此主题的后续工作导致[RFC7435]中发布了操作系统的定义。
6. The technical community could do better in explaining the real technical downsides related to PM in terms that policy makers can understand.
6. 技术界可以更好地用政策制定者能够理解的术语解释与PM相关的真正技术缺陷。
7. Many user interfaces (UIs) could be better in terms of how they present security state, though this is a significantly hard problem. There may be benefits if certain dangerous choices were simply not offered anymore. But that could require significant coordination among competing software makers; otherwise, some will be considered "broken" by users.
7. 许多用户界面（UI）在显示安全状态方面可能会更好，尽管这是一个非常困难的问题。如果不再提供某些危险的选择，可能会有好处。但这可能需要相互竞争的软件制造商之间进行重大协调；否则，一些将被用户视为“损坏”。
8. Further discussion is needed on ways to better integrate UI issues into the processes of IETF and W3C.
8. 需要进一步讨论如何更好地将UI问题集成到IETF和W3C的过程中。
9. Examples of good software configurations that can be cut-and-pasted for popular software, etc., can help. This is not necessarily standards work, but maybe the standards organisations can help and can work with those developing such package-specific documentation.
9. 可以为流行软件剪切和粘贴的良好软件配置示例，等等，都会有所帮助。这不一定是标准工作，但标准组织可能会提供帮助，并与开发此类包特定文档的人员合作。
10. The IETF and W3C can do more so that default ("out-of-the-box") settings for protocols better protect security and privacy.
10. IETF和W3C可以做更多的工作，使协议的默认（“开箱即用”）设置更好地保护安全和隐私。
11. Captive portals [Captive] and some firewalls, too, can and should be distinguished from real man-in-the-middle attacks. This might mean establishing common conventions with makers of such middleboxes, but might also mean developing new protocols. However, the incentives for deploying such new middlebox features might not align.
11. 俘虏门户[俘虏]和一些防火墙也可以而且应该与真正的中间人攻击区分开来。这可能意味着与此类中间盒的制造商建立共同的约定，但也可能意味着开发新的协议。然而，部署这些新的中间包功能的动机可能并不一致。
As stated, the STRINT workshop started from the position [RFC7258] that PM is an attack. While some dissenting voices are expected and need to be heard, that was the baseline assumption for the workshop, and the high-level goal was to provide more consideration of that and how it ought to affect future work within the IETF and W3C.
如上所述，STRINT研讨会从[RFC7258]位置开始，即PM是一种攻击。虽然预计会有一些不同的声音，需要倾听，但这是研讨会的基本假设，高级别目标是提供更多的考虑，以及它应该如何影响IETF和W3C内的未来工作。
At the next level down, the goals of the STRINT workshop were to:
在下一阶段，STRINT研讨会的目标是：
o Discuss and hopefully come to agreement among the participants on concepts in PM for both threats and mitigation, e.g., "opportunistic" as the term applies to cryptography.
o 讨论PM中关于威胁和缓解的概念，并希望在参与者之间达成一致，例如，“机会主义”一词适用于密码学。
o Discuss the PM threat model, and how that might be usefully documented for the IETF at least, e.g., via an update to BCP 72. [RFC3552]
o 讨论PM威胁模型，以及如何至少通过BCP 72的更新为IETF有效记录PM威胁模型。[RFC3552]
o Discuss and progress common understanding in the trade-offs between mitigating and suffering PM.
o 讨论缓解和痛苦PM之间权衡的共识并取得进展。
o Identify weak links in the chain of Web security architecture with respect to PM.
o 识别Web安全体系结构链中与PM相关的薄弱环节。
o Identify potential work items for the IETF, IAB, IRTF, and W3C that would help mitigate PM.
o 为IETF、IAB、IRTF和W3C确定有助于缓解PM的潜在工作项。
o Discuss the kinds of action outside the IETF/W3C context that might help those done within the IETF/W3C.
o 讨论在IETF/W3C上下文之外可能有助于在IETF/W3C中完成的操作的种类。
The workshop structure was designed to maximise discussion time. There were no direct presentations of submitted papers. Instead, the moderators of each session summarised topics that the Technical Programme Committee (TPC) had agreed based on the submitted papers. These summary presentations took at most 50% of the session and usually less.
车间结构旨在最大限度地延长讨论时间。没有直接介绍提交的论文。相反，每届会议的主持人总结了技术方案委员会（TPC）根据提交的论文商定的主题。这些总结报告最多占整个会议的50%，通常较少。
Because the papers would not be presented during the workshop, participants were asked to read and discuss the papers beforehand, at least those relevant to their fields of interest. (To help people choose papers to read, authors were asked to provide short abstracts.)
由于研讨会期间不会提交论文，参与者被要求提前阅读和讨论论文，至少是与他们感兴趣的领域相关的论文。（为了帮助人们选择要阅读的论文，作者被要求提供简短的摘要。）
Most of the sessions had two moderators, one to lead the discussion, while the other managed the queue of people who wanted to speak. This worked well: everybody got a chance to speak and each session still ended on time.
大多数会议都有两位主持人，一位负责主持讨论，另一位负责管理想要发言的人的队列。这很有效：每个人都有机会发言，而且每次会议都按时结束。
The penultimate session consisted of break-outs (which turned out to be the most productive sessions of all, most likely simply due to the smaller numbers of people involved). The subjects for the break-outs were agreed during the earlier sessions, and just before the break-out session the participants collectively determined who would attend which.
倒数第二次会议包括休息（结果是所有会议中最有成效的会议，很可能只是因为参与人数较少）。在前几次会议上，与会者就突发事件的主题达成了一致意见，就在突发事件会议之前，与会者集体决定谁将参加哪一次会议。
The following sections contain summaries of the various sessions. See the minutes (see Appendix B) for more details.
以下各节载有各届会议的摘要。更多详情请参见会议记录（见附录B）。
The first session discussed the goals of the workshop. Possible approaches to improving security in the light of pervasive monitoring include a critical look at what metadata is actually required, whether old (less secure) devices can be replaced with new ones, what are "low-hanging fruit" (issues that can be handled quickly and easily), and what level of security is "good enough": a good solution may be one that is good for 90% of people or 90% of organisations.
第一次会议讨论了讲习班的目标。根据普遍监控提高安全性的可能方法包括：仔细查看实际需要哪些元数据，旧（不太安全）设备是否可以用新设备替换，什么是“低效的果实”（可以快速轻松处理的问题），以及什么级别的安全“足够好”：一个好的解决方案可能适合90%的人或90%的组织。
Some participants felt that standards are needed so that people can see if their systems conform to a certain level of security, and easy to remember names are needed for those standards, so that a buyer can immediately see that a product "conforms to the named intended standard."
一些与会者认为，需要标准，以便人们能够看到他们的系统是否符合某种程度的安全性，并且这些标准需要易于记忆的名称，以便购买者能够立即看到产品“符合指定的预期标准”
One difference between "traditional" attacks and pervasive monitoring is modus operandi of the attacker: typically, one determines what resources an attacker might want to target and at what cost and then one defends against that threat. But a pervasive attacker has no specific targets, other than to collect everything he can. The calculation of the cost of losing resources vs. the cost of protecting them is thus different. And unlike someone motivated to make money, a PM attacker may not be concerned at the cost of the attack (or may even prefer a higher cost, for "empire building" reasons).
“传统”攻击和普遍监视之间的一个区别是攻击者的操作方式：通常，攻击者会确定攻击者可能要攻击的资源和成本，然后防御该威胁。但是一个无处不在的攻击者没有特定的目标，除了收集他能收集的一切。因此，损失资源的成本与保护资源的成本的计算是不同的。而且，与有动机赚钱的人不同，PM攻击者可能不关心攻击的成本（或者出于“帝国建设”的原因，甚至可能更喜欢更高的成本）。
The terminology used to talk about threats has to be chosen carefully (this was a common theme in several sessions), because we need to explain to people outside the technical community what they need to do or not do. For example, authentication of endpoints doesn't so much "protect against" man-in-the-middle (MITM) attacks as make them visible. The attacker can still mount an attack but does not remain invisible while he does so. Somebody on either end of the conversation needs to react to the alert from the system: stop the conversation or find a different channel.
必须仔细选择用于谈论威胁的术语（这是几次会议的共同主题），因为我们需要向技术界以外的人解释他们需要做什么或不需要做什么。例如，端点的身份验证与其说是“防止”中间人（MITM）攻击，不如说是使它们可见。攻击者仍然可以发起攻击，但在发起攻击时不会保持不可见。对话两端的某人需要对系统发出的警报作出反应：停止对话或找到其他频道。
Paradoxically, while larger sites such as Facebook, Yahoo, and Google supervise the security of their respective services more than other smaller sites, such large sites offer a much more attractive target to attack. Avoiding overuse of such repositories for private or
自相矛盾的是，尽管Facebook、雅虎和谷歌等大型网站比其他小型网站更能监督各自服务的安全，但这些大型网站提供了一个更具吸引力的攻击目标。避免将此类存储库过度用于私人或私人用途
sensitive information may be a useful measure that increases the cost of collecting for a pervasive attacker. This is sometimes called the target-dispersal approach.
敏感信息可能是增加普遍攻击者收集成本的有用措施。这有时被称为目标分散方法。
Lack of interoperability between systems can lead to poorly thought out work-arounds and compromises that may themselves introduce vulnerabilities. Thus, improving interoperability needs to be high on the list of priorities of standards makers and even more for implementers. Of course, testing (such as interop testing) is, at some level, part of the process of the IETF and W3C; and the W3C is currently increasing its testing efforts.
系统之间缺乏互操作性可能会导致考虑不周的变通办法和妥协，而这些变通办法和妥协本身可能会引入漏洞。因此，提高互操作性需要成为标准制定者优先考虑的事项，对实施者来说更是如此。当然，测试（如互操作测试）在某种程度上是IETF和W3C过程的一部分；W3C目前正在加大测试力度。
The first session on Communication Security (COMSEC) tools looked at the question why existing security tools aren't used more.
关于通信安全（COMSEC）工具的第一次会议探讨了为什么现有安全工具没有被更多地使用的问题。
The example of the public key infrastructure used to secure HTTP is informative. One problem is that certification authorities (CAs) may issue a certificate for any domain. Thus, a single compromised CA can be used in combination with a MITM to impersonate any server. Moreover, ongoing administration, including requesting, paying for, and installing new certificates, has proven over time to be an insurmountable barrier for many web site administrators, leading them not to bother to secure their systems.
用于保护HTTP的公钥基础设施的示例提供了信息。一个问题是，证书颁发机构（CA）可以为任何域颁发证书。因此，单个受损CA可以与MITM结合使用来模拟任何服务器。此外，不断进行的管理，包括申请、支付和安装新证书，随着时间的推移已被证明是许多网站管理员无法逾越的障碍，导致他们不再费心保护自己的系统。
Some ideas were discussed for improving the CA system, e.g., via cross-certification of CAs and by means of "certificate transparency" -- a public, permanent log of who issued which certificate [RFC6962].
讨论了改进CA系统的一些想法，例如，通过CA的交叉认证和“证书透明度”——世卫组织颁发哪个证书的公共永久日志[RFC6962]。
Using other models than the hierarchical certificate model (as alternative or in combination) may also help. Pretty Good Privacy (PGP) demonstrates a model known as a "web of trust" where people verify the public key of the people they meet. Because there is no innate transitive trust in PGP, it is appropriate only for small-scale uses; an example is a team of people working on a project.
使用分层证书模型以外的其他模型（作为替代或组合）也可能有所帮助。Pretty Good Privacy（PGP）展示了一个被称为“信任网”的模型，在该模型中，人们验证他们遇到的人的公钥。因为PGP中没有天生的传递信任，所以它只适合于小规模使用；一个例子是一个项目团队。
Yet another model is "trust on first use" (TOFU). This is used quite effectively by SSH [RFC4252]. On the first connection, one has no way to verify that the received public key belongs to the server one is contacting, therefore, the key is accepted without further verification. But on the subsequent connections, one can verify that the received key is the same key as the first time. So, a MITM has to be there on all connections, including the first; otherwise, it will be detected by a key mismatch.
另一种模式是“第一次使用时的信任”（豆腐）。SSH[RFC4252]非常有效地使用了这一点。在第一次连接中，无法验证接收到的公钥是否属于所联系的服务器，因此，不需要进一步验证即可接受该密钥。但在随后的连接中，可以验证接收到的密钥是否与第一次相同。因此，所有连接上都必须有一个MITM，包括第一个连接；否则，它将被密钥不匹配检测到。
This works well for SSH, because people typically use SSH to communicate with a small number of servers over and over again. And, if they want, they may find a separate channel to get the public key (or its fingerprint). It may also work for web servers used by small groups (the server of a sports club, a department of a company, etc.), but probably works less well for public servers that are visited once or a few times or for large services where many servers may be used.
这对SSH很有效，因为人们通常使用SSH反复与少量服务器通信。而且，如果他们愿意，他们可能会找到一个单独的渠道来获取公钥（或其指纹）。它也适用于小团体使用的web服务器（体育俱乐部的服务器、公司的部门等），但对于访问一次或几次的公共服务器或可能使用多台服务器的大型服务，它的效果可能较差。
A similar proposal [RFC7469] for an HTTP header introduces an aspect of TOFU into HTTP: Key pinning tells HTTP clients that for a certain time after receiving this certificate, they should not expect the certificate to change. If it does, even if the new certificate looks valid, the client should assume a security breach.
HTTP头的类似建议[RFC7469]将TOFU的一个方面引入到HTTP中：密钥固定告诉HTTP客户端，在收到此证书后的一段时间内，他们不应该期望证书发生更改。如果是这样，即使新证书看起来有效，客户端也应该假定存在安全漏洞。
The Session Initiation Protocol (SIP) [RFC3261] can require several different intermediaries in different stages of the communication to deal with NAT traversal and to handle policy. While both hop-by-hop and end-to-end encryption are specified, in practice, many SIP providers disable these functions. The reasons for disabling end-to-end security here are understandable: to overcome lack of interoperability they often need to change protocol headers and modify protocol data. Some workshop participants argued that SIP would never have taken off if it hadn't been possible for providers to monitor and interfere in communications in this way. Of course, that means an attacker can listen in just as easily.
会话发起协议（SIP）[RFC3261]可能需要在通信的不同阶段使用几个不同的中介来处理NAT遍历和处理策略。虽然指定了逐跳加密和端到端加密，但在实践中，许多SIP提供商禁用了这些功能。这里禁用端到端安全性的原因是可以理解的：为了克服互操作性的不足，他们通常需要更改协议头和修改协议数据。一些研讨会参与者认为，如果供应商不可能以这种方式监控和干扰通信，SIP就永远不会成功。当然，这意味着攻击者可以同样轻松地监听。
A new protocol for peer-to-peer communication of video and audio (and potentially other data) is WebRTC. WebRTC reuses many of the same architectural concepts as SIP, but there is a reasonable chance that it can do better in terms of protecting users: The people implementing the protocols and offering the service have different goals and interests. In particular, the first implementers are browser makers, who may have different business models from other more traditional Voice over IP providers.
一种新的视频和音频（以及潜在的其他数据）对等通信协议是WebRTC。WebRTC重用了许多与SIP相同的体系结构概念，但在保护用户方面，它有可能做得更好：实施协议和提供服务的人有不同的目标和兴趣。特别是，第一批实现者是浏览器制造商，他们的业务模式可能与其他更传统的IP语音提供商不同。
XMPP [RFC6120] suffers from yet a different kind of problem. It has encryption and authentication, and the OTR ("off the record") extension even provides what is called Perfect Forward Secrecy (PFS), i.e., compromising the current communication never gives an attacker enough information to decrypt past communications that he may have recorded. But, in practice, many people don't use XMPP at all, but rather Skype, WhatsApp, or other instant-messaging tools with unknown or no security. The problem here seems to be one of user awareness. And though OTR does provide security, it is not well integrated with XMPP, nor is it available as a core feature of XMPP clients.
XMPP[RFC6120]面临着另一种问题。它具有加密和身份验证功能，OTR（“off-the-record”）扩展甚至提供了所谓的完美前向保密（PFS），也就是说，泄露当前通信不会给攻击者提供足够的信息来解密他可能记录的过去通信。但是，在实践中，许多人根本不使用XMPP，而是使用Skype、WhatsApp或其他安全性未知或没有安全性的即时消息工具。这里的问题似乎是用户意识问题。尽管OTR确实提供了安全性，但它并没有很好地与XMPP集成，也不能作为XMPP客户机的核心功能使用。
To increase usage of existing solutions, some tasks can be identified; though how those map to actions for, e.g., IETF/W3C is not clear:
为了提高现有解决方案的使用率，可以确定一些任务；尽管这些行动如何映射到IETF/W3C等的行动尚不清楚：
o Improvements to the certificate system, such as certificate transparency (CT).
o 证书系统的改进，如证书透明度（CT）。
o Making it easier (cheaper, quicker) for system administrators to deploy secure solutions.
o 使系统管理员更容易（更便宜、更快）部署安全解决方案。
o Improve awareness of the risks. Identify which communities influence which decisions and what is the appropriate message for each.
o 提高风险意识。确定哪些社区影响哪些决策，以及每个社区的适当信息。
o Provide an upgrade path that doesn't break existing systems or require that everybody upgrade at the same time. Opportunistic Security may be one model for that.
o 提供不破坏现有系统或要求所有人同时升级的升级路径。机会主义安全可能是一种模式。
Previous sessions already concluded that the problem isn't just technical, such as getting the right algorithms in the standards, fixing interoperability, or educating implementers and systems administrators. There are user interface issues and education issues too. And there are also legal issues and policy issues for governments.
以前的会议已经得出结论，问题不仅仅是技术上的，比如在标准中获得正确的算法，修复互操作性，或者教育实施者和系统管理员。还有用户界面问题和教育问题。政府也面临法律问题和政策问题。
It appears that the public, in general, demands more privacy and security (e.g., for their children) but are also pessimistic about getting that. They trust that somebody assures that nothing bad happens to them, but they also expect to be spied on all the time.
一般来说，公众似乎要求更多的隐私和安全（例如，为他们的孩子），但也对获得更多的隐私和安全持悲观态度。他们相信有人会保证不会有什么不好的事情发生在他们身上，但他们也希望一直被监视。
(Perceived) threats of terrorism gave governments a reason to allow widespread surveillance, far beyond what may previously have been considered dangerous for freedom.
（被察觉的）恐怖主义威胁给了政府一个允许广泛监视的理由，这远远超出了以前可能被认为对自由有害的范围。
In this environment, the technical community will have a hard time developing and deploying technologies that fully counter PM, which means there has to be action in the social and political spheres, too.
在这种环境下，技术界将很难开发和部署完全对抗PM的技术，这意味着也必须在社会和政治领域采取行动。
Technology isn't the only thing that can make life harder for attackers. Government-sponsored PM is indirectly affected by trade agreements and treaties, and thus it makes sense to lobby for those to be as privacy-friendly as possible.
技术并不是让攻击者的生活变得更加艰难的唯一因素。政府赞助的PM受到贸易协定和条约的间接影响，因此，游说这些协定和条约尽可能保护隐私是有意义的。
Court cases on the grounds of human rights can also influence policy, especially if they reach, for example, the European Court of Human Rights.
以人权为理由的法庭案件也会影响政策，特别是如果这些案件涉及到欧洲人权法院（European Court of human rights）。
In medicine and law, it is common to have ethics committees, not so in software. Should standards bodies such as the IETF and W3C have an ethics committee? Standards such as the Geolocation API [w3c-geo-api] have gotten scrutiny from privacy experts, but only in an ad hoc manner. (W3C has permanent groups to review standards for accessibility and internationalisation. It also has a Privacy group, but that currently doesn't do the same kind of systematic reviews.)
在医学和法律领域，设立伦理委员会是很常见的，而在软件领域则不然。像IETF和W3C这样的标准机构是否应该有一个道德委员会？诸如地理定位API[w3c geo API]之类的标准已经得到隐私专家的仔细审查，但只是以一种特别的方式。（W3C有永久性的小组来审查无障碍性和国际化的标准。它也有一个隐私小组，但目前没有进行同样的系统审查。）
As the Internet-Draft draft-barnes-pervasive-problem-00 [Barnes] (which was included as paper 44) explains, PM doesn't just monitor the networks, but also attacks at the endpoints, turning organisations or people into (willing, unwilling, or unwitting) collaborators. Note: that document later evolved into [RFC7624]. One technical means of protection is thus to design protocols such that there are fewer potential collaborators, e.g., a provider of cloud storage cannot hand over plaintext for content that is encrypted with a key he doesn't have, and cannot hand over names if his client is anonymous.
正如互联网草案草案草案-barnes-pervasive-problem-00[barnes]（作为第44号文件包含）所解释的那样，PM不仅监控网络，还监控端点的攻击，将组织或个人变成（自愿、不自愿或无意的）合作者。注：该文档后来演变为[RFC7624]。因此，一种技术保护手段是设计协议，以减少潜在合作者的数量，例如，云存储提供商不能为使用他没有的密钥加密的内容移交明文，如果他的客户是匿名的，则不能移交姓名。
It is important to distinguish between PM and fighting crime. PM is an attack, but a judge ordering the surveillance of a suspected criminal is not. The latter, often abbreviated in this context as LI (for Lawful Intercept) is outside the scope of this workshop.
区分预防性维护和打击犯罪很重要。PM是一种攻击，但法官下令监视嫌疑犯则不是。后者在本文中通常缩写为LI（用于合法拦截），不属于本研讨会的范围。
An earlier session discussed why existing COMSEC tools weren't used more. This second session on COMSEC therefore discussed what improvements and/or new tools were needed.
早些时候的一次会议讨论了为什么现有的通信安全工具没有得到更多的使用。因此，第二次通信安全会议讨论了需要哪些改进和/或新工具。
Discussion at the workshop indicated that an important meta-tool for improving existing security technology could be Opportunistic Security (OS) [Kent]. The idea is that software is enhanced with a module that tries to encrypt communications when it detects that the other end also has the same capability, but otherwise it lets the communication continue in the old way. The detailed definition of OS was being discussed by the IETF Security Area Advisory Group at the time of this workshop [SAAG_list].
研讨会上的讨论表明，改进现有安全技术的一个重要元工具可能是机会主义安全（OS）[Kent]。其思想是，软件通过一个模块进行增强，该模块在检测到另一端也具有相同的功能时，尝试加密通信，但在其他方面，它允许通信以旧的方式继续。在本次研讨会期间，IETF安全区域咨询小组正在讨论操作系统的详细定义[SAAG_列表]。
OS would protect against a passive eavesdropper but should also allow for endpoint authentication to protect against an active attacker (a MITM). As OS spreads, more and more communications would be encrypted (and hopefully authenticated), and thus there is less and less for an eavesdropper to collect.
操作系统可以防止被动窃听，但也应该允许端点身份验证来防止主动攻击者（MITM）。随着操作系统的普及，越来越多的通信将被加密（并有望通过身份验证），因此窃听者收集的信息越来越少。
Of course, an implementation of OS could give a false sense of security as well: some connections are encrypted, some are not. A user might see something like a padlock icon in browsers, but there was agreement at the workshop that such user interface features ought not be changed because OS is being used.
当然，操作系统的实现也可能给人一种错误的安全感：有些连接是加密的，有些不是。用户可能会在浏览器中看到类似挂锁图标的东西，但在研讨会上达成了一致意见，即不应更改此类用户界面功能，因为正在使用操作系统。
There is also the possibility that a MITM intercepts the reply from a server that says "yes, I can do encryption" and removes it, causing the client to fall back to an unencrypted protocol. Mitigations against this can be to have other channels of finding out a server's capabilities and remembering that a server could do encryption previously.
还有一种可能性是，MITM会截获来自服务器的回复，该服务器会说“是的，我可以进行加密”，并将其删除，从而导致客户端退回到未加密的协议。针对这种情况的缓解措施可以是通过其他渠道了解服务器的功能，并记住服务器以前可以进行加密。
There is also, again, a terminology problem. The technical descriptions of OS talk about "silent fail" when a connection couldn't be encrypted and has to fall back to the old, unencrypted protocol. Actually, it's not a fail; it's no worse than it was before. A successful encryption would rather be a "silent improvement."
此外，还有一个术语问题。在操作系统的技术描述中，当一个连接不能被加密并且不得不退回到旧的未加密协议时，会出现“无声故障”。事实上，这不是失败；情况并不比以前更糟。成功的加密更像是“无声的改进”
That raises the question of the UI: How do you explain to a user what their security options are, and, in case an error occurs, how do you explain the implications of the various responses?
这就提出了UI的问题：如何向用户解释他们的安全选项，以及在发生错误时如何解释各种响应的含义？
The people working on encryption are mathematicians and engineers, and typically not the same people who know about UI. We need to involve the experts. We also need to distinguish between usability of the UI, user understanding, and user experience. For an e-commerce site, e.g., it is not just important that the user's data is technically safe, but also that he feels secure. Otherwise, he still won't buy anything.
从事加密工作的人是数学家和工程师，通常不是那些了解UI的人。我们需要让专家参与进来。我们还需要区分UI的可用性、用户理解和用户体验。例如，对于一个电子商务网站来说，用户的数据不仅在技术上是安全的，而且他感到安全也很重要。否则，他还是什么都不买。
When talking about users, we also need to distinguish the end user (who we typically think about when we talk about UI) from the server administrators and other technical people involved in enabling a connection. When something goes wrong (e.g., the user's software detects an invalid certificate), the message usually goes to the end user. But, he isn't necessarily the person who can do something about it. For example, if the problem is a certificate that expired yesterday, the options for the user are to break the connection (the safe choice, but it means he can't get his work done) or continue anyway (there could be a MITM). The server administrator, on the other hand, could actually solve the problem.
在谈到用户时，我们还需要将最终用户（我们在谈到UI时通常会想到的用户）与服务器管理员和其他参与启用连接的技术人员区分开来。当出现问题时（例如，用户的软件检测到无效证书），消息通常发送给最终用户。但是，他不一定是那个能做点什么的人。例如，如果问题是昨天过期的证书，那么用户可以选择断开连接（安全选择，但这意味着他无法完成工作）或继续（可能存在MITM）。另一方面，服务器管理员实际上可以解决这个问题。
Encryption and authentication have a cost, in terms of setting them up, but also in terms of the time it takes for software to do the calculations. The setup cost can be reduced with sensible defaults, predefined profiles, and cut-and-paste configurations. And for some
加密和身份验证在设置它们方面是有成本的，但在软件进行计算所需的时间方面也是有成本的。通过合理的默认设置、预定义的配置和剪切粘贴配置，可以降低设置成本。对一些人来说
connections, authentication without encryption could be enough, in the case that the data doesn't need to be kept secret, but it is important to know that it is the real data. Most mail user agents (UA) already provide independent options for encryption and signing, but web servers only support authentication if the connection is also encrypted.
在数据不需要保密的情况下，无需加密的连接、身份验证就足够了，但重要的是要知道它是真实的数据。大多数邮件用户代理（UA）已经为加密和签名提供了独立的选项，但web服务器仅在连接也加密时才支持身份验证。
On the other hand, as email also shows, it is difficult for users to understand what encryption and authentication do separately.
另一方面，正如电子邮件所示，用户很难理解加密和身份验证分别做什么。
It also has to be kept in mind that encrypting only the "sensitive" data and not the rest decreases the cost for an attacker, too: It becomes easy to know which connections are worth attacking. Selective field confidentiality is also more prone to lead to developer error, as not all developers will know the provenance of values to be processed.
还必须记住，只加密“敏感”数据而不加密其余数据也会降低攻击者的成本：很容易知道哪些连接值得攻击。选择性字段机密性也更容易导致开发人员错误，因为并非所有开发人员都知道要处理的值的来源。
One problem with the TOFU model as used by SSH (see explanation above) is that it lacks a solution for key continuity: When a key is changed (which can happen, e.g., when a server is replaced or the software upgraded), there is no way to inform the client. (In practice, people use other means, such as calling people on the phone or asking their colleagues in the office, but that doesn't scale and doesn't always happen either.) An improvement in the SSH protocol could thus be a way to transfer a new key to a client in a safe way.
SSH使用的TOFU模型的一个问题（见上面的解释）是它缺少密钥连续性的解决方案：当密钥发生更改时（这可能发生，例如，当服务器被更换或软件升级时），无法通知客户端。（在实践中，人们使用其他方式，比如打电话或询问办公室同事，但这不会扩大规模，也不总是发生。）因此，SSH协议的改进可能是一种以安全方式将新密钥传输到客户端的方法。
Encryption and authentication help protect the content of messages. Correctly implemented encryption is very hard to crack. (To get the content, an attacker would rather attempt to steal the keys, corrupt the encoding software, or get the content via a collaborator. See [RFC7624] for more information on "collaborator".) But encrypting the content doesn't hide the fact that you are communicating. This metadata (who talks to whom, when, and for how long) is often as interesting as the content itself, and in some cases the size and timing of messages is even an accurate predictor of the content. So how to stop an attacker from collecting metadata, given that much of that data is actually needed by routers and other services to deliver the message to the right place?
加密和身份验证有助于保护消息的内容。正确实现的加密很难破解。（为了获取内容，攻击者宁愿尝试窃取密钥、损坏编码软件或通过合作者获取内容。有关“合作者”的更多信息，请参阅[RFC7624]），但加密内容不会隐藏您正在通信的事实。这种元数据（谁与谁、何时与多长时间交谈）通常与内容本身一样有趣，在某些情况下，消息的大小和时间甚至可以准确预测内容。那么，鉴于路由器和其他服务实际上需要大量元数据来将消息传递到正确的位置，如何阻止攻击者收集元数据呢？
It is useful to distinguish different kinds of metadata: explicit (or metadata proper) and implicit (sometimes called traffic data). Implicit metadata is things that can be derived from a message or are necessary for its delivery, such as the destination address, the size, the time, or the frequency with which messages pass. Explicit
区分不同种类的元数据很有用：显式（或元数据本身）和隐式（有时称为流量数据）。隐式元数据是可以从消息中派生或传递消息所必需的内容，例如目标地址、大小、时间或消息传递的频率。明确的
metadata is things like quality ratings, provenance, or copyright data: data about the data, useful for an application, but not required to deliver the data to its endpoint.
元数据是类似于质量评级、出处或版权数据的东西：关于数据的数据，对应用程序有用，但不需要将数据交付到其端点。
A system such as Tor hides much of the metadata by passing through several servers, encrypting all the data except that which a particular server needs to see. Each server thus knows which server a message came from and where it has to send it to, but cannot know where the previous server got it from or where the next server is instructed to send it. However, deliberately passing through multiple servers makes the communication slower than taking the most direct route and increases the amount of traffic the network as a whole has to process.
像Tor这样的系统通过传递多个服务器来隐藏大部分元数据，加密除特定服务器需要查看的数据之外的所有数据。因此，每个服务器都知道消息来自哪个服务器以及必须发送到哪里，但不知道前一个服务器从哪里获得消息，或者下一个服务器被指示发送消息。但是，故意通过多个服务器会使通信速度比采用最直接的路由慢，并增加整个网络必须处理的通信量。
There are three kinds of measures that can be taken to make metadata harder to get: aggregation, contraflow, and multipath (see "Flows and Pervasive Monitoring" [Paper4]). New protocols should be designed such that these measures are not inadvertently disallowed, e.g., because the design assumes that the whole of a conversation passes through the same route.
为了使元数据更难获取，可以采取三种措施：聚合、反向流和多路径（请参见“流和普适监控”[Paper4]）。新协议的设计应确保这些措施不会被无意中拒绝，例如，因为设计假定整个会话都通过相同的路由。
"Aggregation" means collecting conversations from multiple sources into one stream. For example, if HTTP connections pass through a proxy, all the conversations appear to come from the proxy instead of from their original sources. (This assumes that telltale information in the headers is stripped by the proxy or that the connection is encrypted.) It also works in the other direction: if multiple web sites are hosted on the same server, an attacker cannot see which of those web sites a user is reading. (This assumes that the name of the site is in the path info of the URL and not in the domain name; otherwise, watching DNS queries can still reveal the name.)
“聚合”是指将多个来源的对话收集到一个流中。例如，如果HTTP连接通过代理，则所有对话似乎都来自代理，而不是来自其原始来源。（这假设头中的指示信息被代理剥离或连接被加密。）它也在另一个方向工作：如果多个网站托管在同一台服务器上，则攻击者无法看到用户正在阅读这些网站中的哪一个。（这假设站点的名称位于URL的路径信息中，而不是域名中；否则，观看DNS查询仍然可以显示名称。）
"Contraflow" means routing a conversation via one or more other servers than the normal route, e.g., by using a tunnel (e.g., with SSH or a VPN) to another server. Tor is an example of this. An attacker must watch more routes and do more effort to correlate conversations. (Again, this assumes that there is no telltale information left in the messages that leave the tunnel.)
“反向流”是指通过一个或多个非正常路由的其他服务器路由对话，例如，通过使用隧道（例如，使用SSH或VPN）到另一台服务器。Tor就是一个例子。攻击者必须监视更多的路由并尽更多努力关联对话。（同样，这假设离开隧道的消息中没有任何指示信息。）
"Multipath" splits up a single conversation (or a set of related conversations) and routes the parts in different ways, e.g., sending a request via a satellite link and receiving the response via a land line, or starting a conversation on a cellular link and continuing it via Wi-Fi. This again increases the cost for an attacker, who has to monitor and correlate data traversing multiple networks.
“多路径”将单个会话（或一组相关会话）拆分，并以不同的方式路由部分，例如，通过卫星链路发送请求并通过陆地线路接收响应，或在蜂窝链路上启动会话并通过Wi-Fi继续。这再次增加了攻击者的成本，他们必须监视并关联穿越多个网络的数据。
Protecting metadata automatically with technology at a lower layer than the application layer is difficult. The applications themselves need to pass less data, e.g., use anonymous temporary handles instead of permanent identifiers. There is often no real need for people to use the same identifier on different computers (smartphone, desktop, etc.) other than that the application they use was designed that way.
在比应用层低的一层使用技术自动保护元数据是困难的。应用程序本身需要传递更少的数据，例如，使用匿名临时句柄而不是永久标识符。人们通常不需要在不同的计算机（智能手机、桌面等）上使用相同的标识符，除非他们使用的应用程序就是这样设计的。
One thing that can be done relatively easily in the short term is to go through existing protocols to check what data they send that isn't really necessary. One candidate mentioned for such a study was XMPP.
在短期内可以相对容易地完成的一件事是通过现有的协议来检查它们发送的哪些数据不是真正必要的。这项研究提到的一位候选人是XMPP。
"Fingerprinting" is the process of distinguishing different senders of messages based on metadata [RFC6973]: Clients can be recognised (or at least grouped) because their messages always have a combination of features that other clients' messages do not have. Reducing redundant metadata and reducing the number of optional features in a protocol reduces the variation between clients and thus makes fingerprinting harder.
“指纹识别”是基于元数据区分不同消息发送者的过程[RFC6973]：可以识别（或至少分组）客户机，因为他们的消息总是具有其他客户机消息所不具备的功能组合。减少冗余元数据和协议中可选功能的数量可以减少客户端之间的差异，从而使指纹识别更加困难。
Traffic analysis is a research discipline that produces sometimes surprising findings that are little known among protocol developers. Some collections of results are
流量分析是一门研究学科，它有时会产生令人惊讶的发现，而协议开发人员对此知之甚少。一些结果集合是
o a selected bibliography on anonymity by the Free Haven Project <http://freehaven.net/anonbib/>,
o 自由港项目的匿名书目精选<http://freehaven.net/anonbib/>,
o the yearly Symposium on Privacy Enhancing Technologies (PETS) <http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>, and
o 隐私增强技术（PETS）年度研讨会<http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>，以及
o the yearly Workshop on Privacy in the Electronic Society (WPES) <http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html>.
o 电子社会隐私年度研讨会（WPES）<http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html>。
Techniques that deliberately change the timing or size of messages, such as padding, can also help reduce traffic analysis. Obviously, they make conversations slower and/or use more bandwidth, but in some cases that is not an issue, e.g., if the conversation is limited by the speed of a human user anyway. HTTP/2, for example, has a built-in padding mechanism. However, it is not easy to use these techniques well and make messages harder to recognise (as intended) rather than easier.
故意改变消息时间或大小的技术（如填充）也有助于减少流量分析。显然，它们会使对话速度变慢和/或使用更多带宽，但在某些情况下，这不是问题，例如，如果对话受到人类用户速度的限制。例如，HTTP/2有一个内置的填充机制。然而，很好地使用这些技术并使消息更难识别（如预期的）而不是更容易。
Different users in different contexts may have different security needs, so maybe the priority can be a user choice (if that can be done without making high-security users stand out from other users). Although many people would not understand what their choices are, some do, such as political activists or journalists.
不同环境中的不同用户可能有不同的安全需求，因此，优先级可能是用户的选择（如果这样做不会让高安全性用户从其他用户中脱颖而出）。尽管许多人不明白他们的选择是什么，但有些人却明白，比如政治活动家或记者。
Secure protocols have often been designed in the past for end-to-end security: Intermediaries cannot read or modify the messages. This is the model behind TLS, for example.
过去，安全协议通常是为端到端安全而设计的：中介无法读取或修改消息。例如，这就是TLS背后的模型。
In practice, however, people have more or less valid reasons to insist on intermediaries: companies filtering incoming and outgoing traffic for viruses, inspecting content to give priority to certain applications, or caching content to reduce bandwidth.
然而，在实践中，人们或多或少有充分的理由坚持使用中介机构：公司过滤传入和传出的流量以防病毒，检查内容以优先考虑某些应用程序，或者缓存内容以减少带宽。
In the presence of end-to-end encryption and authentication, these intermediaries have two choices: use fake certificates to impersonate the endpoints or have access to the private keys of the endpoints. The former is a MITM attack that is difficult to distinguish from a more malicious one, and the latter obviously decreases the security of the endpoints by copying supposedly confidential information and concentrating credentials in a single place.
在存在端到端加密和身份验证的情况下，这些中介机构有两种选择：使用假证书模拟端点，或访问端点的私钥。前者是一种难以与恶意攻击区分的MITM攻击，后者通过复制假定的机密信息并将凭据集中在一个地方，明显降低了端点的安全性。
As mentioned in Section 5.2 above, aggregation of data in a single place makes that place an attractive target. And in the case of PM, even if the data is not concentrated physically in one place, it is under control of a single legal entity that can be made into a collaborator.
如上文第5.2节所述，将数据聚集在一个地方会使该地方成为一个有吸引力的目标。在PM的情况下，即使数据不是集中在一个地方，它也由一个可以成为合作者的单一法律实体控制。
The way Web communication with TLS typically works is that the client authenticates the server, but the server does not authenticate the client at the TLS layer. (If the user needs to be identified, that is mainly done at the application layer via username and password.) Thus, the presence of a MITM (middlebox) could be detected by the client (because of the incorrect certificate), but not by the server. If the client doesn't immediately close the connection (which they do not in many cases), the server may thus disclose information that the user would rather not have disclosed.
与TLS的Web通信通常的工作方式是，客户端对服务器进行身份验证，但服务器不在TLS层对客户端进行身份验证。（如果需要识别用户，这主要是通过用户名和密码在应用层完成的。）因此，MITM（中间箱）的存在可能会被客户端检测到（因为证书不正确），而不会被服务器检测到。如果客户机没有立即关闭连接（在许多情况下，他们不会这样做），服务器可能会因此泄露用户不愿意泄露的信息。
One widespread example of middleboxes is captive portals, as found on the Wi-Fi hotspots in hotels, airports, etc. Even the hotspots offering free access often intercept communications to redirect the user to a login or policy page.
中间包的一个广泛例子是专属门户，如酒店、机场等的Wi-Fi热点。即使是提供免费访问的热点也经常拦截通信以将用户重定向到登录或策略页面。
When the communication they intercept is, e.g., the automatic update of your calendar program or a chat session, the redirect obviously doesn't work: these applications don't know how to display a web page. With the increasing use of applications, it may be a while before the user actually opens a browser. The flood of error messages may also have as a result that the user no longer reads the errors, allowing an actual malicious attack to go unnoticed.
当他们截获的通信是自动更新日历程序或聊天会话时，重定向显然不起作用：这些应用程序不知道如何显示网页。随着应用程序使用的增加，用户实际打开浏览器可能需要一段时间。大量错误消息也可能导致用户不再读取错误，从而导致实际恶意攻击不被注意。
Some operating systems now come with heuristics that try to recognise captive portals and either automatically login or show their login page in a separate application. (But, some hotspot providers apparently don't want automatic logins and actually reverse-engineered the heuristics to try and fool them.)
一些操作系统现在提供了试探法，试图识别捕获的门户，并在单独的应用程序中自动登录或显示其登录页面。（但是，一些热点提供商显然不希望自动登录，实际上反向设计了试探法，试图愚弄他们。）
It seems some protocol is missing in this case. Captive portals shouldn't have to do MITM attacks to be noticed. A mechanism at the link layer or an extension to DHCP that tells a connecting device about the login page may help, although that still doesn't solve the problem for devices that do not have a web browser, such as voice over IP phones. HTTP response code 511 (defined in [RFC6585]) is another attempt at a partial solution. (It's partial because it can only work at the moment the user uses a browser to connect to a web site and doesn't use HTTPS.)
在这种情况下，似乎缺少一些协议。俘虏门户不应该为了引起注意而进行MITM攻击。链接层的机制或DHCP的扩展告诉连接设备有关登录页的信息可能会有所帮助，尽管这仍然不能解决没有web浏览器的设备（如IP电话语音）的问题。HTTP响应代码511（在[RFC6585]中定义）是部分解决方案的另一种尝试。（这是部分原因，因为它只能在用户使用浏览器连接到网站时工作，而不使用HTTPS。）
A practical problem with deployment of such a protocol may be that many such captive portals are very old and never updated. The hotel staff only knows how to reboot the system, and, as long as it works, the hotel has no incentive to buy a new one. As evidence of this: how many such systems require you to get a password and the ticket shows the price as zero? This is typically because the owner doesn't know how to reconfigure the hotspot, but he does know how to change the price in his cash register.
部署这样一个协议的一个实际问题可能是，许多这样的捕获门户非常陈旧，从未更新过。酒店员工只知道如何重新启动系统，而且，只要它能工作，酒店就没有购买新系统的动机。作为证据：有多少这样的系统需要您获得密码，而票子上显示的价格为零？这通常是因为所有者不知道如何重新配置热点，但他知道如何更改收银机中的价格。
Despite some requests earlier in the workshop, the research break-out did not discuss clean-slate approaches. The challenge was rather that the relationship between security research and standardisation needs improvement. Research on linkability is not yet well known in the IETF. But, the other side of the coin needs improvement too: While doing protocol design, standardisation organisations should indicate what specific problems are in need of more research.
尽管研讨会早些时候提出了一些要求，但这项研究并没有讨论干净的方法。挑战在于安全研究和标准化之间的关系需要改进。关于链接性的研究在IETF中尚不为人所知。但是，硬币的另一面也需要改进：在进行协议设计时，标准化组织应该指出哪些具体问题需要更多研究。
The break-out then made a nonexhaustive list of topics that are in need of further research:
然后，分出一个非详尽的主题列表，需要进一步研究：
o The interaction of compression and encryption as demonstrated by the CRIME ("Compression Ratio Info-leak Made Easy") SSL/TLS vulnerability [Ristic]
o 犯罪（“压缩比信息泄漏变得容易”）SSL/TLS漏洞[Ristic]所证明的压缩和加密的交互作用
o A more proactive deprecation of algorithms based on research results
o 基于研究结果的更主动的算法否决
o Mitigation for return-oriented programming attacks
o 面向返回编程攻击的缓解措施
o How to better obfuscate so-called "metadata"
o 如何更好地混淆所谓的“元数据”
o How to make the existence of traffic and their endpoints stealthy
o 如何使流量及其端点隐形存在
Browsers are the first clients one thinks of when talking about encrypted connections, authentication, and certificates, but there are many others.
当谈到加密连接、身份验证和证书时，浏览器是人们首先想到的客户端，但还有许多其他客户端。
Other common cases of "false" alarms for MITM (after captive portals) include expired and misconfigured certificates. This is quite common in intranets, when the sysadmin hasn't bothered updating a certificate and rather tells his handful of users to just "click continue." The problem is on the one hand that users may not understand the difference between this case and the same error message when they connect to a server outside the company, and on the other hand that the incorrect certificate installed by the sysadmin is not easily distinguishable from an incorrect certificate from a MITM. The error message is almost the same, and the user may just click continue again.
其他常见的MITM“错误”警报（在捕获门户之后）包括过期和配置错误的证书。这在内部网中很常见，当系统管理员没有费心更新证书，而是告诉他的少数用户“单击继续”时。问题是，一方面，用户可能不理解这种情况与连接到公司外服务器时相同错误消息之间的区别，另一方面，系统管理员安装的错误证书与MITM中的错误证书很难区分。错误消息几乎相同，用户只需再次单击“继续”。
One way to get rid of such certificates is if client software no longer offers the option to continue after a certificate error. That requires that all major clients (such as browsers) change their behaviour at the same time; otherwise, the first one to do so will be considered broken by users, because the others still work. Also, it requires a period in which that software gives increasingly strong warnings about the cut-off date after which the connection will fail with this certificate.
消除此类证书的一种方法是，如果客户端软件不再提供在证书错误后继续的选项。这要求所有主要客户机（如浏览器）同时改变其行为；否则，第一个这样做的将被用户认为是坏的，因为其他的仍然可以工作。此外，它还需要一段时间，在这段时间内，该软件会对截止日期发出越来越强烈的警告，在截止日期之后，该证书将导致连接失败。
Yet another source of error messages is self-signed certificates. Such certificates are actually only errors for sites that are not expected to have them. If a message about a self-signed certificate appears when connecting to Facebook or Google, you're clearly not connected to the real Facebook or Google. But, for a personal web site, it shouldn't cause such scary warnings. There may be ways to improve the explanations in the error message and provide an easy way to verify the certificate (by email, phone, or some other channel) and trust it.
错误消息的另一个来源是自签名证书。这样的证书实际上只是预期不会有证书的站点的错误。如果在连接到Facebook或Google时出现关于自签名证书的消息，则表明您显然没有连接到真正的Facebook或Google。但是，对于个人网站来说，它不应该引起如此可怕的警告。可能有一些方法可以改进错误消息中的解释，并提供一种验证证书（通过电子邮件、电话或其他渠道）和信任证书的简单方法。
One step in improving security is to require the relevant features (in particular, encryption and authentication) to be implemented in compliant products: The features are labelled as "MUST" in the standard rather than "MAY". This is sometimes referred to as Mandatory To Implement (MTI) and is the current practice for IETF protocols [RFC3365].
提高安全性的一个步骤是要求在兼容产品中实现相关功能（特别是加密和身份验证）：这些功能在标准中被标记为“必须”，而不是“可能”。这有时被称为强制实施（MTI），是IETF协议[RFC3365]的现行做法。
But, that may not be enough to counter PM. It may be that the features are there, but not used, because only very knowledgeable users or sysadmins turn them on. Or, it may be that implementations do not actually follow the MTI parts of specifications. Or, it may be that some security features are implemented, but interoperability for those doesn't really work. Or, even worse, it may be that protocol designers have only followed the letter of the MTI best practice and not its spirit, with the result that security features are hard to use or make deployment harder. One can thus argue that such features should be defined to be on by default.
但是，这可能不足以对抗首相。这些功能可能存在，但没有被使用，因为只有知识渊博的用户或系统管理员才能打开它们。或者，可能是实现实际上没有遵循规范的MTI部分。或者，可能实现了一些安全功能，但这些功能的互操作性并不真正起作用。或者，更糟糕的是，协议设计者只遵循MTI最佳实践的文字，而没有遵循其精神，结果导致安全特性难以使用或使部署更加困难。因此，有人会争辩说，这些功能应该被定义为默认打开。
Going further, one might argue that these features should not even be options, i.e., there should be no way to turn them off. This is sometimes called Mandatory To Use (MTU).
进一步说，有人可能会说这些功能甚至不应该是选项，也就是说，不应该有办法关闭它们。这有时被称为强制使用（MTU）。
The questions raised at this session were for what protocols is on-by-default appropriate, and how can one explain to the developers of such protocols that it is needed?
在本次会议上提出的问题是，默认情况下什么协议是合适的，以及如何向此类协议的开发人员解释它是必要的？
Of course, there would be resistance to MTU security from implementers and deployments that practice deep packet inspection (DPI) and also perhaps from some governments. On the other hand, there may also be governments that outlaw protocols without proper encryption.
当然，实施深度数据包检查（DPI）的实施者和部署人员以及一些政府可能会对MTU安全性产生抵制。另一方面，也可能有政府在没有适当加密的情况下将协议定为非法。
This break-out concluded that there could be value in attempting to document a new Best Current Practice for the IETF that moves from the current MTI position to one where security features are on by default. Some of the workshop participants expressed interest in authoring a draft for such a new BCP and progressing it through the IETF consensus process (where it would no doubt be controversial).
这一突发事件的结论是，试图记录IETF的新的最佳实践可能有价值，该实践从当前MTI位置移动到默认启用安全功能的位置。一些研讨会参与者表示有兴趣为这样一个新的BCP起草一份草案，并通过IETF协商一致过程（在这一过程中无疑会引起争议）。
There was a small break-out on the idea of measurement as a way to encourage or gamify the increased use of security mechanisms.
关于将计量作为鼓励或游戏化增加使用安全机制的一种方式的想法有一个小的突破。
This break-out considered the use of the term "opportunistic" as it applies to cryptographic security and attempted to progress the work towards arriving at an agreed-upon definition for use of that term, at it applies to IETF and W3C work.
本次突发事件考虑了术语“机会主义”的使用，因为它适用于加密安全，并试图推进工作，以达成一致的定义使用该术语，在它适用于IETF和W3C工作。
While various terms had been used, with many people talking about opportunistic encryption, that usage was felt to be problematic both because it conflicted with the use of the same term in [RFC4322] and because it was being used differently in different parts of the community.
虽然使用了各种术语，许多人都在谈论机会主义加密，但这种用法被认为是有问题的，因为它与[RFC4322]中相同术语的使用相冲突，并且在社区的不同部分使用不同。
At the session, it was felt that the term "opportunistic keying" was better, but, as explained above, subsequent list discussion resulted in a move to the term "Opportunistic Security" (OS).
在会议上，有人认为“机会主义密钥”一词更好，但是，如上所述，随后的列表讨论导致使用“机会主义安全”（OS）一词。
Aside from terminology, discussion focused on the use of Diffie-Hellman (D-H) key exchange as the preferred mechanism of OS, with fall back to cleartext if D-H doesn't succeed as a counter for passive attacks.
除了术语外，讨论的重点是使用Diffie-Hellman（D-H）密钥交换作为操作系统的首选机制，如果D-H不能成功作为被动攻击的计数器，则可使用明文。
There was also, of course, the desire to be able to easily escalate from countering passive attacks to also handling endpoint authentication and thereby also countering MITM attacks.
当然，人们还希望能够轻松地从对付被动攻击升级到处理端点身份验证，从而也对付MITM攻击。
Making OS visible to users was again considered to be undesirable, as users could not be expected to distinguish between cleartext, OS, and (one-sided or mutual) endpoint authentication.
让操作系统对用户可见再次被认为是不可取的，因为不能期望用户区分明文、操作系统和（单方面或相互的）端点身份验证。
Finally, it was noted that it may take some effort to establish how middleboxes might affect OS at different layers and that OS really is not suitable as the only mitigation to use for high-sensitivity sessions such as financial transactions.
最后，有人指出，可能需要做出一些努力来确定中间包如何影响不同层的操作系统，而操作系统确实不适合作为用于金融交易等高敏感度会话的唯一缓解措施。
Some routing and transport Area Directors felt a little left out by all the application-layer break-outs, so they had their own brainstorm about what could be done at the transport and routing layers from which these notes resulted.
一些路由和传输区域主管觉得所有的应用程序层突发事件都有点遗漏了，因此他们有自己的头脑风暴，讨论在这些注释产生的传输和路由层可以做些什么。
The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer service that is reordering- and delay-insensitive. Use of LEDBAT could offer the following benefits for an application:
LEDBAT[RFC6817]协议针对的是一种对重排序和延迟不敏感的批量传输服务。使用LEDBAT可以为应用程序提供以下好处：
a. Because it is reordering-insensitive, traffic can be sprayed across a large number of forwarding paths. Assuming such different paths exist, this would make it more challenging to capture and analyze a full interaction.
a. 因为它对重新排序不敏感，所以可以在大量转发路径上喷洒流量。假设存在这种不同的路径，这将使捕获和分析完整的交互变得更具挑战性。
b. The application can vary the paths by indicating per packet a different flow. In IPv6, this can be done via different IPv6 flow labels. For IPv4, this can be done by encapsulating the IP packet into UDP and varying the UDP source port.
b. 应用程序可以通过为每个数据包指示不同的流来改变路径。在IPv6中，这可以通过不同的IPv6流标签来完成。对于IPv4，这可以通过将IP数据包封装到UDP并改变UDP源端口来实现。
c. Since LEDBAT is delay-insensitive and applications using it would need to be as well, it would be possible to obfuscate the application signatures by varying the packet lengths and frequency.
c. 由于LEDBAT对延迟不敏感，使用它的应用程序也需要延迟不敏感，因此可以通过改变数据包长度和频率来混淆应用程序签名。
d. This can also hide the transport header (for IP in UDP).
d. 这还可以隐藏传输头（对于UDP中的IP）。
e. If the Reverse Path Forwarding (RPF) [RFC3704] check problem can be fixed, perhaps the source could be hidden; however, such fixes assume the traffic is within trusted perimeters.
e. 如果可以修复反向路径转发（RPF）[RFC3704]检查问题，则可能会隐藏源；但是，此类修复假定流量在可信范围内。
f. The use of LEDBAT is orthogonal to the use of encryption and provides different benefits (harder to intercept the whole conversation, ability to obfuscate the traffic analysis), and it has different costs (longer latency, new transport protocol usage) to its users.
f. LEDBAT的使用与加密的使用是正交的，它提供了不同的好处（更难截获整个对话，能够混淆流量分析），并且它对用户有不同的成本（更长的延迟，新的传输协议使用）。
The idea of encrypting traffic from Customer Edge (CE) to CE as part of an L3VPN or such was also discussed. This could allow hiding of addresses, including source, and headers. From conversation with Ron Bonica, it's clear that some customers already do encryption (though without hiding the source address). So, rather than an enhancement, this is an existing mechanism for which deployment and use can be encouraged.
还讨论了作为L3VPN等的一部分对从客户边缘（CE）到CE的流量进行加密的想法。这可能允许隐藏地址，包括源和头。从与Ron Bonica的对话中可以明显看出，一些客户已经进行了加密（尽管没有隐藏源地址）。因此，这不是一种增强，而是一种可以鼓励部署和使用的现有机制。
Finally, it was discussed whether it would be useful to have a means of communicating where and what layers are doing encryption on an application's traffic path. The initial idea of augmenting ICMP has some issues (not visible to application, ICMP packets frequently filtered) as well as potential work (determining how to trust the report of encryption). It would be interesting to understand if such communication is actually needed and what the requirements would be.
最后，讨论了在应用程序的通信路径上，有一种在何处以及哪些层在进行加密的通信方式是否有用。扩充ICMP的最初想法有一些问题（应用程序看不到，ICMP数据包经常被过滤）以及潜在的工作（确定如何信任加密报告）。了解这种交流是否真的需要以及要求是什么是很有意思的。
Holding the workshop just before the IETF had the intended effect: a number of people went to both the workshop and the IETF, and they took the opportunity of being together at the IETF to continue the discussions.
在IETF达到预期效果之前举办研讨会：许多人参加了研讨会和IETF，他们利用在IETF聚会的机会继续讨论。
IETF working groups meeting in London took the recommendations from the workshop into account. It was even the first item in the report about the IETF meeting by the IETF chair, Jari Arkko:
在伦敦举行的IETF工作组会议考虑了研讨会的建议。这甚至是IETF主席Jari Arkko关于IETF会议的报告中的第一项：
Strengthening the security and privacy of the Internet continued to draw a lot of attention. The STRINT workshop organised by the IAB and W3C just before the IETF attracted 100 participants and over 60 papers. Even more people would have joined us, but there
加强互联网的安全和隐私继续引起人们的广泛关注。IAB和W3C在IETF之前组织的STRINT研讨会吸引了100名参与者和60多篇论文。本来会有更多的人加入我们，但是
was no space. During the IETF meeting, we continued discussing the topic at various working groups. A while ago we created the first working group specifically aimed at addressing some of the issues surrounding pervasive monitoring. The Using TLS for Applications (UTA) working group had its first meeting in London. But many other working groups also address these issues in their own work. The TCPM working group discussed a proposal to add opportunistic keying mechanisms directly onto the TCP protocol. And the DNSE BOF considered the possibility of adding confidentiality support to DNS queries. Finally, there is an ongoing effort to review old specifications to search for areas that might benefit from taking privacy and data minimisation better into account. [Arkko1]
没有空间。在IETF会议期间，我们继续在各个工作组讨论该主题。不久前，我们成立了第一个工作组，专门解决围绕普遍监测的一些问题。应用TLS（UTA）工作组在伦敦举行了第一次会议。但许多其他工作组也在自己的工作中处理这些问题。TCPM工作组讨论了在TCP协议中直接添加机会键控机制的建议。DNSE BOF考虑了向DNS查询添加机密性支持的可能性。最后，目前正在努力审查旧规范，以搜索可能从更好地考虑隐私和数据最小化中获益的领域。[Arkko1]
Two papers that were written for the workshop, but not finished in time, are worth mentioning, too: One by the same Jari Arkko, titled "Privacy and Networking Functions" [Arkko2]; and one by Johan Pouwelse, "The Shadow Internet: liberation from Surveillance, Censorship and Servers" [Pouwelse].
有两篇论文是为研讨会撰写的，但没有及时完成，也值得一提：一篇是同一个Jari Arkko写的，题为“隐私和网络功能”[Arkko2]；约翰·普韦尔斯（Johan Pouwelse）的一篇文章《影子互联网：从监视、审查和服务器中解放出来》[Pouwelse]。
This document is all about security and privacy.
本文档涉及安全和隐私。
[Arkko1] Arkko, J., "IETF-89 Summary", March 2014, <http://www.ietf.org/blog/2014/03/ietf-89-summary/>.
[Arkko1]Arkko，J.，“IETF-89摘要”，2014年3月<http://www.ietf.org/blog/2014/03/ietf-89-summary/>.
[Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014, <http://www.arkko.com/ietf/strint/ draft-arkko-strint-networking-functions.txt>.
[Arkko 2]Arkko，J.，“隐私和网络功能”，2014年3月<http://www.arkko.com/ietf/strint/ 起草arkko strint networking functions.txt>。
[Barnes] Barnes, R., Schneier, B., Jennings, C., and T. Hardie, "Pervasive Attack: A Threat Model and Problem Statement", Work in Progress, draft-barnes-pervasive-problem-00, January 2014.
[Barnes]Barnes，R.，Schneier，B.，Jennings，C.，和T.Hardie，“普遍攻击：威胁模型和问题陈述”，正在进行的工作，草稿-Barnes-Pervasive-Problem-00，2014年1月。
[Captive] Wikipedia, "Captive portal", October 2015, <https://en.wikipedia.org/w/ index.php?title=Captive_portal&oldid=685621201>.
[专属]维基百科，“专属门户”，2015年10月<https://en.wikipedia.org/w/ index.php？title=Captive\u portal&oldid=685621201>。
[Kent] Kent, S., "Opportunistic Security as a Countermeasure to Pervasive Monitoring", Work in Progress, draft-kent-opportunistic-security-01, April 2014.
[Kent]Kent，S.，“机会主义安全作为普遍监控的对策”，正在进行的工作，草稿-Kent-Opportunity-Security-01，2014年4月。
[Paper4] Hardie, T., "Flows and Pervasive Monitoring", STRINT Workshop, 2014, <https://www.w3.org/2014/strint/papers/4.pdf>.
[Paper4]Hardie，T.，“流量和普遍监测”，STRINT研讨会，2014年<https://www.w3.org/2014/strint/papers/4.pdf>.
[Pouwelse] Pouwelse, J., "The Shadow Internet: liberation from Surveillance, Censorship and Servers", Work in Progress, draft-pouwelse-perpass-shadow-internet-00, February 2014.
[Pouwelse]Pouwelse，J.，“影子互联网：从监视、审查和服务器中解放出来”，正在进行的工作，草稿-Pouwelse-perpass-Shadow-Internet-00，2014年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365]Schiller，J.，“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，DOI 10.17487/RFC3365，2002年8月<http://www.rfc-editor.org/info/rfc3365>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<http://www.rfc-editor.org/info/rfc3552>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<http://www.rfc-editor.org/info/rfc3704>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <http://www.rfc-editor.org/info/rfc4252>.
[RFC4252]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，DOI 10.17487/RFC4252，2006年1月<http://www.rfc-editor.org/info/rfc4252>.
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, DOI 10.17487/RFC4322, December 2005, <http://www.rfc-editor.org/info/rfc4322>.
[RFC4322]Richardson，M.和D.Redelmeier，“使用互联网密钥交换（IKE）的机会主义加密”，RFC 4322，DOI 10.17487/RFC4322，2005年12月<http://www.rfc-editor.org/info/rfc4322>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC 6585，DOI 10.17487/RFC6585，2012年4月<http://www.rfc-editor.org/info/rfc6585>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<http://www.rfc-editor.org/info/rfc6817>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <http://www.rfc-editor.org/info/rfc6962>.
[RFC6962]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，RFC 6962，DOI 10.17487/RFC6962，2013年6月<http://www.rfc-editor.org/info/rfc6962>.
[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>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<http://www.rfc-editor.org/info/rfc7469>.
[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>.
[Ristic] Ristic, I., "CRIME: Information Leakage Attack against SSL/TLS", Qualys Blog, <https://community.qualys.com/blogs/securitylabs/2012/ 09/14/crime-information-leakage-attack-against-ssltls>.
[Ristic]Ristic，I.，“犯罪：针对SSL/TLS的信息泄漏攻击”，Qualys博客<https://community.qualys.com/blogs/securitylabs/2012/ 09/14/针对ssltls>的犯罪信息泄漏攻击。
[SAAG_list] IETF, "saag Discussion Archive", <https://www.ietf.org/ mail-archive/web/saag/current/maillist.html>.
[SAAG_列表]IETF，“SAAG讨论档案”<https://www.ietf.org/ 邮件存档/web/saag/current/maillist.html>。
[STRINT] W3C/IAB, "STRINT Workshop", <https://www.w3.org/2014/strint/Overview.html>.
[STRINT]W3C/IAB，“STRINT研讨会”<https://www.w3.org/2014/strint/Overview.html>.
[vancouverplenary] IETF, "IETF 88 Technical Plenary Minutes", <https://www.ietf.org/proceedings/88/minutes/ minutes-88-iab-techplenary>.
[Vancouver全体会议]IETF，“IETF 88技术全体会议纪要”<https://www.ietf.org/proceedings/88/minutes/ 会议记录-88-iab-TechEnglobal>。
[w3c-geo-api] Popescu, A., "Geolocation API Specification", W3C Recommendation, October 2013, <http://www.w3.org/TR/geolocation-API/>.
[w3c地理api]Popescu，A.，“地理定位api规范”，w3c建议，2013年10月<http://www.w3.org/TR/geolocation-API/>.
The workshop was organised by the STREWS project (<https://www.strews.eu/>), which is a research project funded under the European Union's 7th Framework Programme (<http://cordis.europa.eu/fp7/ict/>). It was the first of two workshops in its work plan. The organisers were supported by the IAB and W3C, and, for the local organisation, by Telefonica Digital (<http://blog.digital.telefonica.com/>).
研讨会由STREWS项目组织(<https://www.strews.eu/>)，这是一个由欧盟第七框架计划资助的研究项目(<http://cordis.europa.eu/fp7/ict/>). 这是其工作计划中两个讲习班的第一个。组织者得到了IAB和W3C的支持，对于当地组织，还得到了Telefonica Digital的支持(<http://blog.digital.telefonica.com/>).
One of the suggestions in the project description of the STREWS project was to attach the first workshop to an IETF meeting. The best opportunity was IETF 89 in London, which began on Sunday 2 March 2014; see <https://www.ietf.org/meeting/89/> for more information. Telefonica Digital offered meeting rooms at its offices in central London for the preceding Friday and Saturday, just minutes away from the IETF's location.
STREWS项目的项目描述中的建议之一是将第一次研讨会附加到IETF会议上。最好的机会是2014年3月2日星期日在伦敦举行的IETF 89；看<https://www.ietf.org/meeting/89/>了解更多信息。上周五和周六，Telefonica Digital在其位于伦敦市中心的办公室提供会议室，距离IETF的地点仅几分钟。
The room held 100 people, which was thought to be sufficient. There turned out to be more interest than expected and we could have filled a larger room, but 100 people is probably an upper limit for good discussions anyway.
这个房间能容纳100人，这被认为是足够的。结果证明，人们的兴趣比预期的要多，我们本可以填满一个更大的房间，但无论如何，100人可能是良好讨论的上限。
Apart from the usual equipment in the room (projector, white boards, microphones, coffee), we also set up some extra communication channels:
除了房间里的常规设备（投影仪、白板、麦克风、咖啡），我们还设置了一些额外的沟通渠道：
o A mailing list where participants could discuss the agenda and the published papers about three weeks in advance of the workshop itself.
o 一份邮件列表，参与者可以在研讨会开始前大约三周讨论议程和发表的论文。
o Publicly advertised streaming audio (one-way only). At some point, no less than 165 people were listening.
o 公开宣传的流媒体音频（仅单向）。在某个时候，至少有165人在听。
o An IRC channel for live minute-taking, passing links and other information, and helping remote participants to follow the proceedings.
o IRC频道，用于实时记录、传递链接和其他信息，并帮助远程参与者跟踪会议进程。
o An Etherpad, where the authors of papers could provide an abstract of their submissions, to help participants who could not read all 66 papers in full in advance of the workshop. The abstracts were also used on the workshop's web site: <https://www.w3.org/2014/strint/>.
o 一个Etherpad，论文作者可以在这里提供他们提交的论文摘要，以帮助无法在研讨会之前阅读全部66篇论文的参与者。研讨会的网站上也使用了这些摘要：<https://www.w3.org/2014/strint/>.
o A Twitter hashtag (#strint). Four weeks after the workshop, there were still a few new messages about events related to workshop topics; see <https://twitter.com/search?q=%23strint>.
o 推特标签（#strint）。研讨会结束四周后，仍有一些关于研讨会主题相关活动的新信息；看<https://twitter.com/search?q=%23strint>.
This was the final agenda of the workshop, as determined by the TPC and participants on the mailing list prior to the workshop. The included links are to the slides that the moderators used to introduce each discussion topic and to the minutes.
这是研讨会的最终议程，由TPC和研讨会前邮寄名单上的参与者确定。包含的链接指向主持人用来介绍每个讨论主题的幻灯片和会议记录。
Minutes: <http://www.w3.org/2014/02/28-strint-minutes.html>
Minutes: <http://www.w3.org/2014/02/28-strint-minutes.html>
Workshop starts, welcome, logistics, opening/overview
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf>
Workshop starts, welcome, logistics, opening/overview
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf>
o Goal is to plan how we respond to PM threats
o 目标是规划我们如何应对PM威胁
o Specific questions to be discussed in sessions
o 将在会议上讨论的具体问题
o Outcomes are actions for IETF, W3C, IRTF, etc.
o 结果是IETF、W3C、IRTF等的行动。
I. Threats - What problem are we trying to solve?
(Presenter: Richard Barnes; Moderator: Cullen Jennings)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf>
I. Threats - What problem are we trying to solve?
(Presenter: Richard Barnes; Moderator: Cullen Jennings)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf>
* What attacks have been described? (Attack taxonomy)
* 描述了哪些攻击？（攻击分类）
* What should we assume the attackers' capabilities are?
* 我们应该假设攻击者的能力是什么？
* When is it really "pervasive monitoring" and when is it not?
* 什么时候是真正的“普遍监控”，什么时候不是？
* Scoping - what's in and what's out? (for IETF/W3C)
* 范围界定-什么在里面，什么在外面？（适用于IETF/W3C）
II. COMSEC 1 - How can we increase usage of current COMSEC tools?
(Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf>
II. COMSEC 1 - How can we increase usage of current COMSEC tools?
(Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf>
* Whirlwind catalog of current tools
* 当前工具的旋风目录
* Why aren't people using them? In what situations are / aren't they used?
* 为什么人们不使用它们？在什么情况下使用/不使用它们？
* Securing AAA and management protocols - why not?
* 保护AAA和管理协议-为什么不？
* How can we (IETF/W3C/community) encourage more/better use?
* 我们（IETF/W3C/community）如何鼓励更多/更好的使用？
III. Policy - What policy/legal/other issues need to be taken into
account? (Presenter: Christine Runnegar; Moderator: Rigo
Wenning)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf>
III. Policy - What policy/legal/other issues need to be taken into
account? (Presenter: Christine Runnegar; Moderator: Rigo
Wenning)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf>
* What non-technical activities do we need to be aware of?
* 我们需要了解哪些非技术性活动？
* How might such non-technical activities impact on IETF/W3C?
* 这些非技术性活动如何影响IETF/W3C？
* How might IETF/W3C activities impact those non-technical activities?
* IETF/W3C活动如何影响这些非技术性活动？
Saturday plan, open mic, wrap-up of the day
周六计划，开放话筒，当天总结
Minutes: <http://www.w3.org/2014/03/01-strint-minutes.html>
Minutes: <http://www.w3.org/2014/03/01-strint-minutes.html>
IV. COMSEC 2 - What improvements to COMSEC tools are needed?
(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf>
IV. COMSEC 2 - What improvements to COMSEC tools are needed?
(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf>
* Opportunistic encryption - what is it and where it might apply
* 机会主义加密-它是什么以及它可能应用于何处
* Mitigations aiming to block PM vs. detect PM - when to try which?
* 旨在阻止PM与检测PM的缓解措施-何时尝试哪种？
V. Metadata - How can we reduce the metadata that protocols expose? (Presenters: Alfredo Pironti, Ted Hardie; Moderator: Alissa Cooper)
V.元数据-我们如何减少协议公开的元数据？（主持人：阿尔弗雷多·皮龙蒂，特德·哈迪；主持人：艾莉莎·库珀）
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf>
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf>
* Metadata, fingerprinting, minimisation
* 元数据、指纹、最小化
* What's out there?
* 外面有什么？
* How can we do better?
* 我们怎样才能做得更好？
VI. Deployment - How can we address PM in deployment / operations?
(Presenter: Eliot Lear; Moderator: Barry Leiba)
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf>
VI. Deployment - How can we address PM in deployment / operations?
(Presenter: Eliot Lear; Moderator: Barry Leiba)
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf>
* "Mega"-commercial services (clouds, large-scale email and Online Social Networks, SIP, WebRTC)
* “Mega”-商业服务（云、大型电子邮件和在线社交网络、SIP、WebRTC）
* Target dispersal - good goal or wishful thinking?
* 目标分散-好目标还是一厢情愿？
* Middleboxes: when a help and when a hindrance?
* 中间人：什么时候是帮助，什么时候是阻碍？
VII. Break-out Sessions (x 3) / Bar-Camp style (Hannes Tschofenig)
七,。休息会（x 3）/酒吧露营式（Hannes Tschofenig）
* Content to be defined during meeting, as topics come up
* 会议期间，随着话题的出现，将定义内容
* Sum up at the end to gather conclusions for report
* 最后总结，为报告收集结论
Break-outs:
突发事件：
1. Research Questions (Moderator: Kenny Paterson)
1. 研究问题（主持人：肯尼·帕特森）
+ Do we need more/different crypto tools?
+ 我们需要更多/不同的加密工具吗？
+ How can applications make better use of COMSEC tools?
+ 应用程序如何更好地使用通信安全工具？
+ What research topics could be handled in IRTF?
+ IRTF可以处理哪些研究主题？
+ What other research would help?
+ 还有什么其他研究会有帮助？
2. Clients
2. 客户
3. On by default
3. 默认打开
4. Measurement
4. 测量
5. Opportunistic
5. 机会主义的
VIII. Break-out Reports, Open Mic & Conclusions - What are we going
to do to address PM?
Slides: <https://www.w3.org/2014/strint/slides/summary.pdf>
VIII. Break-out Reports, Open Mic & Conclusions - What are we going
to do to address PM?
Slides: <https://www.w3.org/2014/strint/slides/summary.pdf>
* Gather conclusions / recommendations / goals from earlier sessions
* 从以前的会议中收集结论/建议/目标
The workshop chairs were three: Stephen Farrell (TCD) and Rigo Wenning (W3C) from the STREWS project, and Hannes Tschofenig (ARM) from the STREWS Interest Group.
研讨会主席有三位：斯特劳斯项目的斯蒂芬·法雷尔（TCD）和里戈·温宁（W3C），以及斯特劳斯兴趣小组的汉内斯·茨霍芬尼（ARM）。
The Technical Programme Committee (TPC) was charged with evaluating the submitted papers. It was made up of the members of the STREWS project, the members of the STREWS Interest Group, plus invited experts: Bernard Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP), Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler (Microsoft), and Sean Turner (IECA).
技术方案委员会（TPC）负责评估提交的论文。它由STREWS项目成员、STREWS兴趣小组成员以及受邀专家组成：Bernard Aboba（微软）、Dan Appelquist（Telefonica&W3C标签）、Richard Barnes（Mozilla）、Bert Bos（W3C）、Lieven Desmet（KU Leuven）、Karen O’Donoghue（ISOC）、Russ Housley（守夜安全）、Martin Johns（SAP）、Ben Laurie（谷歌），艾略特·李尔（Cisco）、肯尼·帕特森（Royal Holloway）、埃里克·雷科拉（RTFM）、温迪·塞尔茨（W3C）、戴夫·泰勒（Microsoft）和肖恩·特纳（IECA）。
The participants to the workshop were:
讲习班的参加者包括：
o Bernard Aboba (Microsoft Corporation) o Thijs Alkemade (Adium) o Daniel Appelquist (Telefonica Digital) o Jari Arkko (Ericsson) o Alia Atlas (Juniper Networks) o Emmanuel Baccelli (INRIA) o Mary Barnes o Richard Barnes (Mozilla) o Steve Bellovin (Columbia University) o Andrea Bittau (Stanford University) o Marc Blanchet (Viagenie) o Carsten Bormann (Uni Bremen TZI) o Bert Bos (W3C) o Ian Brown (Oxford University) o Stewart Bryant (Cisco Systems) o Randy Bush (IIJ / Dragon Research Labs) o Kelsey Cairns (Washington State University) o Stuart Cheshire (Apple) o Vincent Cheval (University of Birmingham) o Benoit Claise (Cisco) o Alissa Cooper (Cisco) o Dave Crocker (Brandenburg InternetWorking) o Leslie Daigle (Internet Society) o George Danezis (University College London) o Spencer Dawkins (Huawei) o Mark Donnelly (Painless Security) o Nick Doty (W3C) o Dan Druta (AT&T)
o Bernard Aboba（微软公司）o Thijs Alkemade（Adium）o Daniel Appelquist（Telefonica Digital）o Jari Arkko（爱立信）o Alia Atlas（Juniper Networks）o Emmanuel Baccelli（INRIA）o Mary Barnes o Richard Barnes（Mozilla）o Steve Bellovin（哥伦比亚大学）o Andrea Bittau（斯坦福大学）o Marc Blanchet（Viagenie）o卡斯滕·鲍曼（不来梅大学）o伯特·博斯（W3C）o伊恩·布朗（牛津大学）o斯图尔特·布莱恩特（思科系统）o兰迪·布什（IIJ/龙研究实验室）o凯尔西·凯恩斯（华盛顿州立大学）o斯图尔特·柴郡（苹果）o文森特·切瓦尔（伯明翰大学）o贝诺特·克莱斯（思科）o艾莉莎·库珀（思科）o戴夫·克罗克（勃兰登堡互联网）o莱斯利·戴格尔（互联网协会）o乔治·达内齐斯（伦敦大学学院）o斯宾塞·道金斯（华为）o马克·唐纳利（无痛安全）o尼克·多蒂（W3C）o丹·德鲁塔（AT&T）
o Peter Eckersley (Electronic Frontier Foundation) o Lars Eggert (NetApp) o Kai Engert (Red Hat) o Monika Ermert o Stephen Farrell (Trinity College Dublin) o Barbara Fraser (Cisco) o Virginie Galindo (gemalto) o Stefanie Gerdes (Uni Bremen TZI) o Daniel Kahn Gillmor (ACLU) o Wendy M. Grossman o Christian Grothoff (The GNUnet Project) o Oliver Hahm (INRIA) o Joseph Lorenzo Hall (Center for Democracy & Technology) o Phillip Hallam-Baker o Harry Halpin (W3C/MIT and IRI) o Ted Hardie (Google) o Joe Hildebrand (Cisco Systems) o Russ Housley (Vigil Security, LLC) o Cullen Jennings (CISCO) o Leif Johansson (SUNET) o Harold Johnson (Irdeto) o Alan Johnston (Avaya) o L. Aaron Kaplan (CERT.at) o Steve Kent (BBN Technologies) o Achim Klabunde (European Data Protection Supervisor) o Hans Kuhn (NOC) o Christian de Larrinaga o Ben Laurie (Google) o Eliot Lear (Cisco Ssytems) o Barry Leiba (Huawei Technologies) o Sebastian Lekies (SAP AG) o Orit Levin (Microsoft Corporation) o Carlo Von LynX (#youbroketheinternet) o Xavier Marjou (Orange) o Larry Masinter (Adobe) o John Mattsson (Ericsson) o Patrick McManus (Mozilla) o Doug Montgomery (NIST) o Kathleen Moriarty (EMC) o Alec Muffett (Facebook) o Suhas Nandakumar (Cisco Systems) o Linh Nguyen (ERCIM/W3C) o Linus Nordberg (NORDUnet) o Mark Nottingham o Karen O'Donoghue (Internet Society) o Piers O'Hanlon (Oxford Internet Institute) o Kenny Paterson (Royal Holloway, University of London) o Jon Peterson (Neustar)
o Peter Eckersley（电子前沿基金会）o Lars Eggert（NetApp）o Kai Engert（红帽）o Monika Ermert o Stephen Farrell（都柏林三一学院）o Barbara Fraser（Cisco）o Virginie Galindo（gemalto）o Stefanie Gerdes（不来梅大学）o Daniel Kahn Gillmor（ACLU）o Wendy M.Grossman o Christian Grothoff（GNUnet项目）o Oliver Hahm（INRIA）o Joseph Lorenzo Hall（民主与技术中心）o Phillip Hallam Baker o Harry Halpin（W3C/MIT和IRI）o Ted Hardie（谷歌）o Joe Hildebrand（思科系统）o Russ Housley（Vigil Security，LLC）o Cullen Jennings（思科）o Leif Johansson（SUNET）o Harold Johnson（爱迪托）o Alan Johnston（Avaya）o L.Aaron Kaplan（CERT.at）o史蒂夫·肯特（BBN Technologies）o阿奇姆·克拉邦德（欧洲数据保护主管）o汉斯·库恩（NOC）o克里斯蒂安·德拉里纳加（Christian de Larrinaga）o本·劳里（Google）o艾略特·李尔（Cisco Ssytems）o巴里·莱巴（华为技术）o塞巴斯蒂安·莱基斯（SAP AG）o奥里特·莱文（微软公司）o卡洛·冯·林克斯（Youbrokertheinternet）o泽维尔·马约（橙色）o Larry Masinter（Adobe）o John Mattsson（Ericsson）o Patrick McManus（Mozilla）o Doug Montgomery（NIST）o Kathleen Moriarty（EMC）o Alec Muffett（Facebook）o Suhas Nandakumar（Cisco Systems）o Linh Nguyen（ERCIM/W3C）o Linus Nordberg（NORDUnet）o Mark Nottingham o Karen o'Donoghue（互联网协会）o Piers o'Hanlon（牛津互联网研究所）O Kenny Paterson（Royal Holloway，伦敦大学）O Jon Peterson（NeS明星）
o Joshua Phillips (University of Birmingham) o Alfredo Pironti (INRIA) o Dana Polatin-Reuben (University of Oxford) o Prof. Johan Pouwelse (Delft University of Technology) o Max Pritikin (Cisco) o Eric Rescorla (Mozilla) o Pete Resnick (Qualcomm Technologies, Inc.) o Tom Ristenpart (University of Wisconsin) o Andrei Robachevsky (Internet Society) o David Rogers (Copper Horse) o Scott Rose (NIST) o Christine Runnegar (Internet Society) o Philippe De Ryck (DistriNet - KU Leuven) o Peter Saint-Andre (&yet) o Runa A. Sandvik (Center for Democracy and Technology) o Jakob Schlyter o Dr. Jan Seedorf (NEC Laboratories Europe) o Wendy Seltzer (W3C) o Melinda Shore (No Mountain Software) o Dave Thaler (Microsoft) o Brian Trammell (ETH Zurich) o Hannes Tschofenig (ARM Limited) o Sean Turner (IECA, Inc.) o Matthias Waehlisch (Freie Universitaet Berlin) o Greg Walton (Oxford University) o Rigo Wenning (W3C) o Tara Whalen (Apple Inc.) o Greg Wood (Internet Society) o Jiangshan Yu (University of Birmingham) o Aaron Zauner o Dacheng Zhang (Huawei) o Phil Zimmermann (Silent Circle LLC) o Juan-Carlos Zuniga (InterDigital)
o Joshua Phillips（伯明翰大学）O Alfredo Pironti（INRIA）O Dana Polatin Reuben（牛津大学）O Johan Pouwelse教授（代尔夫特理工大学）O Max Pritikin（Cisco）O Eric Rescorla（Mozilla）O Pete Resnick（高通技术公司）O SoD（威斯康星大学）O（互联网协会）o大卫·罗杰斯（铜马）o斯科特·罗斯（NIST）o克里斯蒂娜·朗尼加（互联网协会）o菲利普·德莱克（DistriNet-KU Leuven）o彼得·圣安德烈（尚未）o鲁纳·A·桑德维克（民主与技术中心）o雅各布·施莱特o简·西多夫博士（欧洲NEC实验室）o温迪·塞尔茨（W3C）o梅林达·肖尔（无山软件）o Dave Thaler（微软）o Brian Trammell（苏黎世ETH）o Hannes Tschofenig（ARM有限公司）o Sean Turner（IECA，Inc.）o Matthias Waehlisch（柏林弗雷大学）o Greg Walton（牛津大学）o Rigo Wenning（W3C）o Tara Whalen（苹果公司）o Greg Wood（互联网协会）o江山于（伯明翰大学）o Aaron Zauner o张大成（华为）o Phil Zimmermann（沉默圈有限责任公司）o Juan Carlos Zuniga（跨指）
Authors' Addresses
作者地址
Stephen Farrell
Trinity College, Dublin
Email: stephen.farrell@cs.tcd.ie
URI: https://www.cs.tcd.ie/Stephen.Farrell/
Stephen Farrell
Trinity College, Dublin
Email: stephen.farrell@cs.tcd.ie
URI: https://www.cs.tcd.ie/Stephen.Farrell/
Rigo Wenning World Wide Web Consortium 2004, route des Lucioles B.P. 93 Sophia-Antipolis 06902 France Email: rigo@w3.org URI: http://www.w3.org/People/Rigo/
Rigo Wenning万维网联盟2004，route des Lucioles B.P.93 Sophia Antipolis 06902法国电子邮件：rigo@w3.orgURI:http://www.w3.org/People/Rigo/
Bert Bos World Wide Web Consortium 2004, route des Lucioles B.P. 93 Sophia-Antipolis 06902 France Email: bert@w3.org
Bert Bos World Wide Web Consortium 2004，route des Lucioles B.P.93 Sophia Antipolis 06902法国电子邮件：bert@w3.org
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Email: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca
Marc Blanchet Viagenie 246魁北克省阿伯丁市，QC G1R 2E1加拿大电子邮件：Marc。Blanchet@viagenie.caURI:http://viagenie.ca
Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at
Hannes Tschofenig ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号电子邮件：Hannes。tschofenig@gmx.netURI:http://www.tschofenig.priv.at