diff options
Diffstat (limited to 'doc/rfc/rfc7687.txt')
| -rw-r--r-- | doc/rfc/rfc7687.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc7687.txt b/doc/rfc/rfc7687.txt new file mode 100644 index 0000000..3f59d5e --- /dev/null +++ b/doc/rfc/rfc7687.txt @@ -0,0 +1,1795 @@ + + + + + + +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 + +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. + + 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. + +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. + + 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. + + + + +Farrell, et al. Informational [Page 1] + +RFC 7687 STRINT Workshop Report December 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + 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. + + 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. + + 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.). + + + +Farrell, et al. Informational [Page 2] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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). + +2. Summary + + 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. + + 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. + + 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. + + 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]. + + 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. + + 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]. + + + + + +Farrell, et al. Informational [Page 3] + +RFC 7687 STRINT Workshop Report December 2015 + + + 6. The technical community could do better in explaining the real + technical downsides related to PM in terms that policy makers + can understand. + + 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. + + 8. Further discussion is needed on ways to better integrate UI + issues into the processes of IETF and 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. + + 10. The IETF and W3C can do more so that default ("out-of-the-box") + settings for protocols better protect security and privacy. + + 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. + +3. Workshop Goals + + 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. + + At the next level down, the goals of the STRINT workshop were to: + + 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 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] + + + + +Farrell, et al. Informational [Page 4] + +RFC 7687 STRINT Workshop Report December 2015 + + + o Discuss and progress common understanding in the trade-offs + between mitigating and suffering PM. + + o Identify weak links in the chain of Web security architecture with + respect to PM. + + o Identify potential work items for the IETF, IAB, IRTF, and W3C + that would help mitigate PM. + + o Discuss the kinds of action outside the IETF/W3C context that + might help those done within the IETF/W3C. + +4. Workshop Structure + + 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. + + 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. + + + + + + + + + + + + + +Farrell, et al. Informational [Page 5] + +RFC 7687 STRINT Workshop Report December 2015 + + +5. Topics + + The following sections contain summaries of the various sessions. + See the minutes (see Appendix B) for more details. + +5.1. Opening session + + 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. + + 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." + +5.2. Threats + + 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). + + 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. + + 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 + + + +Farrell, et al. Informational [Page 6] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + +5.3. Increase Usage of Security Tools + + The first session on Communication Security (COMSEC) tools looked at + the question why existing security tools aren't used more. + + 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. + + 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]. + + 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. + + 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. + + + + + + +Farrell, et al. Informational [Page 7] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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. + + 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. + + 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. + + 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. + + + + + +Farrell, et al. Informational [Page 8] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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: + + o Improvements to the certificate system, such as certificate + transparency (CT). + + o Making it easier (cheaper, quicker) for system administrators to + deploy secure solutions. + + o Improve awareness of the risks. Identify which communities + influence which decisions and what is the appropriate message for + each. + + 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. + +5.4. Policy Issues and Non-technical Actions + + 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. + + 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. + + + + + + +Farrell, et al. Informational [Page 9] + +RFC 7687 STRINT Workshop Report December 2015 + + + Court cases on the grounds of human rights can also influence policy, + especially if they reach, for example, the 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.) + + 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. + + 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. + +5.5. Improving the Tools + + 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 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. + + + +Farrell, et al. Informational [Page 10] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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? + + 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. + + 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. + + 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 + + + +Farrell, et al. Informational [Page 11] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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. + +5.6. Hiding Metadata + + 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? + + 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 + + + + + +Farrell, et al. Informational [Page 12] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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. + + "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.) + + "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.) + + "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. + + + + + + +Farrell, et al. Informational [Page 13] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + "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. + + 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 the yearly Symposium on Privacy Enhancing Technologies (PETS) + <http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>, + and + + o the yearly Workshop on Privacy in the Electronic Society (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. + + 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. + + + + +Farrell, et al. Informational [Page 14] + +RFC 7687 STRINT Workshop Report December 2015 + + +5.7. Deployment, Intermediaries, and Middleboxes + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + + + +Farrell, et al. Informational [Page 15] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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.) + + 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. + +5.8. Break-out 1 - Research + + 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. + + 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 A more proactive deprecation of algorithms based on research + results + + o Mitigation for return-oriented programming attacks + + o How to better obfuscate so-called "metadata" + + + +Farrell, et al. Informational [Page 16] + +RFC 7687 STRINT Workshop Report December 2015 + + + o How to make the existence of traffic and their endpoints stealthy + +5.9. Break-out 2 - Clients + + 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. + + 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. + +5.10. Break-out 3 - On by Default + + 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]. + + + + +Farrell, et al. Informational [Page 17] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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). + + 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. + + 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). + +5.11. Break-out 4 - Measurement + + There was a small break-out on the idea of measurement as a way to + encourage or gamify the increased use of security mechanisms. + +5.12. Break-out 5 - Opportunistic + + 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. + + + + + + + + +Farrell, et al. Informational [Page 18] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + 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). + + 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. + + 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. + + 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. + +5.13. Unofficial Transport/Routing Break-out + + 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: + + 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. + + 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. + + + +Farrell, et al. Informational [Page 19] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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. + + d. This can also hide the transport header (for IP in UDP). + + 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. + + 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. + + 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. + + 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. + +6. After the Workshop + + 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 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: + + 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 + + + +Farrell, et al. Informational [Page 20] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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] + + 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]. + +7. Security Considerations + + This document is all about security and privacy. + +8. Informative References + + [Arkko1] Arkko, J., "IETF-89 Summary", March 2014, + <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>. + + [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. + + [Captive] Wikipedia, "Captive portal", October 2015, + <https://en.wikipedia.org/w/ + index.php?title=Captive_portal&oldid=685621201>. + + [Kent] Kent, S., "Opportunistic Security as a Countermeasure to + Pervasive Monitoring", Work in Progress, draft-kent- + opportunistic-security-01, April 2014. + + + + + + +Farrell, et al. Informational [Page 21] + +RFC 7687 STRINT Workshop Report December 2015 + + + [Paper4] Hardie, T., "Flows and Pervasive Monitoring", + STRINT Workshop, 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. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + + + + + + +Farrell, et al. Informational [Page 22] + +RFC 7687 STRINT Workshop Report December 2015 + + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [SAAG_list] + IETF, "saag Discussion Archive", <https://www.ietf.org/ + mail-archive/web/saag/current/maillist.html>. + + [STRINT] W3C/IAB, "STRINT Workshop", + <https://www.w3.org/2014/strint/Overview.html>. + + + + + + +Farrell, et al. Informational [Page 23] + +RFC 7687 STRINT Workshop Report December 2015 + + + [vancouverplenary] + IETF, "IETF 88 Technical Plenary Minutes", + <https://www.ietf.org/proceedings/88/minutes/ + minutes-88-iab-techplenary>. + + [w3c-geo-api] + Popescu, A., "Geolocation API Specification", + W3C Recommendation, October 2013, + <http://www.w3.org/TR/geolocation-API/>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farrell, et al. Informational [Page 24] + +RFC 7687 STRINT Workshop Report December 2015 + + +Appendix A. Logistics + + 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/>). + + 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. + + 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. + + 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 Publicly advertised streaming audio (one-way only). At some + point, no less than 165 people were listening. + + o An IRC channel for live minute-taking, passing links and other + information, and helping remote participants to follow the + proceedings. + + 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 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>. + + + + +Farrell, et al. Informational [Page 25] + +RFC 7687 STRINT Workshop Report December 2015 + + +Appendix B. Agenda + + 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. + +B.1. Friday 28 February + + 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> + + o Goal is to plan how we respond to PM threats + + o Specific questions to be discussed in sessions + + o Outcomes are actions for IETF, W3C, IRTF, etc. + + 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) + + 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? + + * How can we (IETF/W3C/community) encourage more/better use? + + + + +Farrell, et al. Informational [Page 26] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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? + + * How might IETF/W3C activities impact those non-technical + activities? + + Saturday plan, open mic, wrap-up of the day + +B.2. Saturday 1 March + + 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> + + * Opportunistic encryption - what is it and where it might + apply + + * Mitigations aiming to block PM vs. detect PM - when to try + which? + + V. Metadata - How can we reduce the metadata that protocols expose? + (Presenters: Alfredo Pironti, Ted Hardie; Moderator: Alissa + Cooper) + + 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? + + + + + + + +Farrell, et al. Informational [Page 27] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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) + + * 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) + + * 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) + + + Do we need more/different crypto tools? + + + How can applications make better use of COMSEC tools? + + + What research topics could be handled in IRTF? + + + What other research would help? + + 2. Clients + + 3. On by default + + 4. Measurement + + 5. Opportunistic + + 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 + + + + + + + + +Farrell, et al. Informational [Page 28] + +RFC 7687 STRINT Workshop Report December 2015 + + +Appendix C. Workshop Chairs and Program Committee + + 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. + + 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). + +Appendix D. Participants + + 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) + + + +Farrell, et al. Informational [Page 29] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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) + + + +Farrell, et al. Informational [Page 30] + +RFC 7687 STRINT Workshop Report December 2015 + + + 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) + + + + + + + + + + + + + + + + + + +Farrell, et al. Informational [Page 31] + +RFC 7687 STRINT Workshop Report December 2015 + + +Authors' Addresses + + 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/ + + + Bert Bos + World Wide Web Consortium + 2004, route des Lucioles + B.P. 93 + Sophia-Antipolis 06902 + France + Email: bert@w3.org + + + Marc Blanchet + Viagenie + 246 Aberdeen + Quebec, QC G1R 2E1 + Canada + Email: Marc.Blanchet@viagenie.ca + URI: 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 + + + + + + + + +Farrell, et al. Informational [Page 32] + |