idnits 2.17.1
draft-iab-strint-report-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 793: '...s are labelled as MUST in the standard...'
RFC 2119 keyword, line 794: '... rather than MAY. This is sometimes...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 4, 2015) is 3119 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 1073
-- Looks like a reference, but probably isn't: '2' on line 1075
-- Looks like a reference, but probably isn't: '3' on line 1077
-- Looks like a reference, but probably isn't: '4' on line 1079
-- Looks like a reference, but probably isn't: '5' on line 1081
-- Looks like a reference, but probably isn't: '6' on line 1083
-- Looks like a reference, but probably isn't: '7' on line 1085
-- Looks like a reference, but probably isn't: '8' on line 1087
-- Looks like a reference, but probably isn't: '9' on line 1089
-- Looks like a reference, but probably isn't: '10' on line 1091
-- Looks like a reference, but probably isn't: '11' on line 1093
-- Looks like a reference, but probably isn't: '12' on line 1095
-- Looks like a reference, but probably isn't: '13' on line 1097
-- Looks like a reference, but probably isn't: '14' on line 1146
-- Looks like a reference, but probably isn't: '15' on line 1148
-- Looks like a reference, but probably isn't: '16' on line 1150
-- Looks like a reference, but probably isn't: '17' on line 1154
-- Looks like a reference, but probably isn't: '18' on line 1171
-- Looks like a reference, but probably isn't: '19' on line 1183
-- Looks like a reference, but probably isn't: '20' on line 1186
-- Looks like a reference, but probably isn't: '21' on line 1198
-- Looks like a reference, but probably isn't: '22' on line 1201
-- Looks like a reference, but probably isn't: '23' on line 1210
-- Looks like a reference, but probably isn't: '24' on line 1222
-- Looks like a reference, but probably isn't: '25' on line 1235
-- Looks like a reference, but probably isn't: '26' on line 1247
-- Looks like a reference, but probably isn't: '27' on line 1251
-- Looks like a reference, but probably isn't: '28' on line 1259
-- Looks like a reference, but probably isn't: '29' on line 1260
-- Looks like a reference, but probably isn't: '30' on line 1260
-- Looks like a reference, but probably isn't: '31' on line 1270
-- Looks like a reference, but probably isn't: '32' on line 1305
-- Looks like a reference, but probably isn't: '33' on line 1312
-- Looks like a reference, but probably isn't: '34' on line 1313
-- Looks like a reference, but probably isn't: '35' on line 1314
== Unused Reference: 'Arkko1' is defined on line 971, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 6962
(Obsoleted by RFC 9162)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 37 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group S. Farrell
3 Internet-Draft Trinity College, Dublin
4 Intended status: Informational R. Wenning
5 Expires: March 7, 2016 B. Bos
6 W3C
7 M. Blanchet
8 Viagenie
9 H. Tschofenig
10 ARM Ltd.
11 September 4, 2015
13 Report from the Strengthening the Internet (STRINT) workshop
14 draft-iab-strint-report-03
16 Abstract
18 The Strengthening the Internet (STRINT) workshop assembled one
19 hundred participants in London for two days in early 2014 to discuss
20 how the technical community, and in particular the IETF and the W3C,
21 should react to Pervasive Monitoring and more generally how to
22 strengthen the Internet in the face of such attacks. The discussions
23 covered issues of terminology, the role of user interfaces, classes
24 of mitigation, some specific use cases, transition strategies
25 (including opportunistic encryption), and more. The workshop ended
26 with a few high-level recommendations, which it is believed could be
27 implemented and which could help strengthen the Internet. This is
28 the report of that workshop.
30 Note that this document is a report on the proceedings of the
31 workshop. The views and positions documented in this report are
32 those of the workshop participants and do not necessarily reflect IAB
33 views and positions.
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on March 7, 2016.
51 Copyright Notice
53 Copyright (c) 2015 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (http://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document.
63 Table of Contents
65 1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Workshop goals . . . . . . . . . . . . . . . . . . . . . . . 4
68 4. Workshop structure . . . . . . . . . . . . . . . . . . . . . 5
69 5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
70 6. After the workshop . . . . . . . . . . . . . . . . . . . . . 20
71 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
72 8. Security considerations . . . . . . . . . . . . . . . . . . . 21
73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
74 Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25
75 Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26
76 Appendix C. Workshop chairs & program committee . . . . . . . . 28
77 Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 28
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
80 1. Context
82 The Vancouver IETF plenary[vancouverplenary] concluded that Pervasive
83 Monitoring (PM) represents an attack on the Internet, and the IETF
84 has begun to carry out the more obvious actions required to try to
85 handle this attack. However, there are additional much more complex
86 questions arising that need further consideration before any
87 additional concrete plans can be made.
89 The W3C [1] and IAB [2] therefore decided to host a workshop [3] on
90 the topic of "Strengthening the Internet Against Pervasive
91 Monitoring" before IETF 89 [4] in London in March 2014. The
92 FP7-funded STREWS [5] project organised the STRINT workshop on behalf
93 of the IAB and W3C.
95 The main workshop goal was to discuss what can be done, especially by
96 the two standards organisations IETF and W3C, against PM, both for
97 existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones
98 (WebRTC, HTTP/2, etc.).
100 The starting point for the workshop was the existing IETF consensus
101 that PM is an attack[RFC7258] (the text of which had achieved IEFF
102 consensus at the time of the workshop, even though the RFC had yet to
103 be published).
105 2. Summary
107 The workshop was well attended (registration closed when the maximum
108 capacity of 100 was reached, but more than 150 expressed a desire to
109 register) and several people (about 165 at the maximum) listened to
110 the streaming audio. The submitted papers (67 in total) were
111 generally of good quality and all were published, except for a few
112 where authors who couldn't take part in the workshop preferred not to
113 publish.
115 The chairs of the workshop summarised the workshop in the final
116 session in the form of the following recommendations:
118 1. Well-implemented cryptography can be effective against PM and
119 will benefit the Internet if used more, despite its cost, which
120 is steadily decreasing anyway.
122 2. Traffic analysis also needs to be considered, but is less well
123 understood in the Internet community: relevant research and
124 protocol mitigations such as data minimisation need to be better
125 understood.
127 3. Work should continue on progressing the PM threat model
128 draft[I-D.barnes-pervasive-problem] discussed in the workshop.
130 4. Later, the IETF may be in a position to start to develop an
131 update to BCP 72 [RFC3552], most likely as a new RFC enhancing
132 that BCP and dealing with recommendations on how to mitigate PM
133 and how to reflect that in IETF work.
135 5. The term "Opportunistic" has been widely used to refer to a
136 possible mitigation strategy for PM. The community need to
137 document definition(s) for this term, as it is being used
138 differently by different people and in different contexts. We
139 may also be able to develop a cookbook-like set of related
140 protocol techniques for developers. Since the workshop, the
141 IETF's security area has taken up this work, most recently
142 favouring the generic term "Opportunistic Security" (OS)
143 [I-D.kent-opportunistic-security]. Subsequent work on this
144 topic resulted in the publication of a definition of OS in
145 [RFC7435].
147 6. The technical community could do better in explaining the real
148 technical downsides related to PM in terms that policy makers
149 can understand.
151 7. Many User Interfaces (UIs) could be better in terms of how they
152 present security state, though this is a significantly hard
153 problem. There may be benefits if certain dangerous choices
154 were simply not offered anymore. But that could require
155 significant co-ordination among competing software makers,
156 otherwise some will be considered "broken" by users.
158 8. Further discussion is needed on ways to better integrate UI
159 issues into the processes of IETF and W3C.
161 9. Examples of good software configurations that can be cut-and-
162 paste'd for popular software, etc., can help. This is not
163 necessarily standards work, but maybe the standards
164 organisations can help and can work with those developing such
165 package-specific documentation.
167 10. The IETF and W3C can do more so that default ("out-of-the-box")
168 settings for protocols better protect security and privacy.
170 11. Captive portals [6] (and some firewalls, too) can and should be
171 distinguished from real man-in-the-middle attacks. This might
172 mean establishing common conventions with makers of such
173 middleboxes, but might also need new protocols. However, the
174 incentives for deploying such new middlebox features might not
175 align.
177 3. Workshop goals
179 As stated, the STRINT workshop started from the position [RFC7258]
180 that PM is an attack. While some dissenting voices are expected and
181 need to be heard, that was the baseline assumption for the workshop,
182 and the high-level goal was to provide more consideration of that and
183 how it ought to affect future work within the IETF and W3C.
185 At the next level down the goals of the STRINT workshop were to:
187 o Discuss and hopefully come to agreement among the participants on
188 concepts in PM for both threats and mitigation, e.g.,
189 "opportunistic" as the term applies to cryptography.
191 o Discuss the PM threat model, and how that might be usefully
192 documented for the IETF at least, e.g., via an update to BCP72.
193 [7]
195 o Discuss and progress common understanding in the trade-offs
196 between mitigating and suffering PM.
198 o Identify weak links in the chain of Web security architecture with
199 respect to PM.
201 o Identify potential work items for the IETF, IAB, IRTF and W3C that
202 would help mitigate PM.
204 o Discuss the kinds of action outside the IETF/W3C context might
205 help those done within the IETF/W3C.
207 4. Workshop structure
209 The workshop structure was designed to maximise discussion time.
210 There were no direct presentations of submitted papers. Instead, the
211 moderators of each session summarised topics that the Technical
212 Programme Committee (TPC) had agreed based on the submitted papers.
213 These summary presentations took at most 50% of the session and
214 usually less.
216 Because the papers would not be presented during the workshop,
217 participants were asked to read and discuss the papers beforehand, at
218 least those relevant to their fields of interest. (To help people
219 choose papers to read, authors were asked to provide short
220 abstracts.)
222 Most of the sessions had two moderators, one to lead the discussion,
223 while the other managed the queue of people who wanted to speak.
224 This worked well: everybody got a chance to speak and each session
225 still ended on time.
227 The penultimate session consisted of break-outs (which turned out to
228 be the most productive sessions of all, most likely simply due to the
229 smaller numbers of people involved). The subjects for the break-outs
230 were agreed during the earlier sessions and just before the break-out
231 session the participants collectively determined who would attend
232 which.
234 5. Topics
236 The following sections contain summaries of the various sessions.
237 See the minutes (see Appendix B) for more details.
239 5.1. Opening session
241 The first session discussed the goals of the workshop. Possible
242 approaches to improving security in the light of pervasive monitoring
243 include a critical look at what metadata is actually required,
244 whether old (less secure) devices can be replaced with new ones, what
245 are "low-hanging fruit" (issues that can be handled quickly and
246 easily), and what level of security is "good enough": a good solution
247 may be one that is good for 90% of people or 90% of organisations.
249 Some participants felt that standards are needed so that people can
250 see if their systems conform to a certain level of security, and easy
251 to remember names are needed for those standards, so that a buyer can
252 immediately see that a product "conforms to the named intended
253 standard."
255 5.2. Threats
257 One difference between "traditional" attacks and pervasive monitoring
258 is modus-operandi of the attacker: typically, one determines what
259 resources an attacker might want to target and at what cost and then
260 one defends against that threat. But a pervasive attacker has no
261 specific targets, other than to collect everything he can. The
262 calculation of the cost of losing resources vs. the cost of
263 protecting them is thus different. And unlike someone motivated to
264 make money, a PM attacker may not be concerned at the cost of the
265 attack (or may even prefer a higher cost, for "empire building"
266 reasons").
268 The terminology used to talk about threats has to be chosen carefully
269 (this was a common theme in several sessions), because we need to
270 explain to people outside the technical community what they need to
271 do or not do. For example, authentication of endpoints doesn't so
272 much "protect against" man-in-the-middle (MITM) attacks as make them
273 visible. The attacker can still attack, but it does not remain
274 invisible while he does so. Somebody on either end of the
275 conversation needs to react to the alert from the system: stop the
276 conversation or find a different channel.
278 Paradoxically, while larger sites such as Facebook, Yahoo, and Google
279 supervise the security of their respective services more than other
280 smaller sites, such large sites offer a much more attractive target
281 to attack. Avoiding overuse of such repositories for private or
282 sensitive information may be a useful measure that increases the cost
283 of collecting for a pervasive attacker. This is sometimes called the
284 target-dispersal approach.
286 Lack of interoperability between systems can lead to poorly thought
287 out work-arounds and compromises that may themselves introduce
288 vulnerabilities. And thus improving interoperability needs to be
289 high on the list of priorities of standards makers and even more for
290 implementers. Of course, testing, such as interop testing, is at
291 some level, part of the process of IETF and W3C; and W3C is currently
292 increasing its testing efforts.
294 5.3. Increase usage of security tools
296 The first session on Communication Security (COMSEC) tools looked at
297 the question why existing security tools aren't used more.
299 The example of the public key infrastructure used to secure HTTP is
300 informative. One problem is that certificate authorities (CAs) may
301 issue a certificate for any domain. Thus a single compromised CA can
302 be used in combination with a MITM to impersonate any server.
303 Moreover, ongoing administration, including requesting, paying for
304 and installing new certificates, has proven over time to be an
305 insurmountable barrier for many web site administrators, leading them
306 not to bother to secure their systems.
308 Some ideas were discussed for improving the CA system, e.g., via
309 cross-certification of CAs and by means of "certificate
310 transparency": a public, permanent log of who issued which
311 certificate. [RFC6962]
313 Using other models than the hierarchical certificate model (as
314 alternative or in combination) may also help. PGP demonstrates a
315 model known as a "web of trust" where people verify the public key of
316 the people they meet. Because there is no innate transitive trust in
317 PGP, it is appropriate only for small scale uses; an example being a
318 team of people working on a project.
320 Yet another model is "trust on first use" (TOFU). This is used quite
321 effectively by SSH [RFC4252]. On the first connection, one has no
322 way to verify that the received public key belongs to the server one
323 is contacting, therefore, the key is accepted without further
324 verification. But on the subsequent connections, one can verify that
325 the received key is the same key as the first time. So a MITM has to
326 be there on all connections, including the first, otherwise it will
327 be detected by a key mismatch.
329 This works well for SSH, because people typically use SSH to
330 communicate with a small number of servers over and over again. And,
331 if they want, they may find a separate channel to get the public key
332 (or its fingerprint). It may also work for Web servers used by small
333 groups (the server of a sports club, a department of a company,
334 etc.), but probably works less well for public servers that are
335 visited once or a few times or for large services where many servers
336 may be used.
338 A similar proposal [draft-ietf-websec-key-pinning] for an HTTP header
339 introduces an aspect of TOFU into HTTP: Key pinning tells HTTP
340 clients that for a certain time after receiving this certificate,
341 they should not expect the certificate to change. If it does, even
342 if the new certificate looks valid, the client should assume a
343 security breach.
345 Session Initiation Protocol (SIP) [RFC3261] can require several
346 different intermediaries in different stages of the communication to
347 deal with NAT traversal and to handle policy. While both hop-by-hop
348 and end-to-end encryption are specified, in practice many SIP
349 providers disable these functions. The reasons for disabling end-to-
350 end security here are understandable: to overcome lack of
351 interoperability they often need to change protocol headers and
352 modify protocol data. Some workshop participants argued that SIP
353 would never have taken off if it hadn't been possible for providers
354 to monitor and interfere in communications in this way. Of course,
355 that means an attacker can listen in just as easily.
357 A new protocol for peer-to-peer communication of video and audio (and
358 potentially other data) is WebRTC. WebRTC re-uses many of the same
359 architectural concepts as SIP, but there is a reasonable chance that
360 it can do better in terms of protecting users: The people
361 implementing the protocols and offering the service have different
362 goals and interests. In particular, the first implementers are
363 browser makers, who may have different business models from other
364 more traditional Voice over IP providers.
366 XMPP[RFC6120] suffers from yet another problem. It has encryption
367 and authentication, and the OTR ("off the record") extension even
368 provides what is called Perfect Forward Secrecy (PFS, compromising
369 the current communication never gives an attacker enough information
370 to decrypt past communications that he may have recorded). But, in
371 practice, many people don't use XMPP at all, but rather Skype,
372 WhatsApp or other instant-messaging tools with unknown or no
373 security. The problem here seems to be one of user awareness. And
374 though OTR does provide security, it is not well integrated with XMPP
375 and nor is it available as a core feature of XMPP clients.
377 To increase usage of existing solutions, some tasks can be
378 identified, though how those map to actions for e.g. IETF/W3C is not
379 clear:
381 o Improvements to the certificate system, such as certificate
382 transparency (CT).
384 o Making it easier (cheaper, quicker) for system administrators to
385 deploy secure solutions.
387 o Improve awareness of the risks. Identify which communities
388 influence which decisions and what is the appropriate message for
389 each.
391 o Provide an upgrade path that doesn't break existing systems or
392 require that everybody upgrade at the same time. Opportunistic
393 Security may be one model for that.
395 5.4. Policy issues and non-technical actions
397 Previous sessions already concluded that the problem isn't just
398 technical, such as getting the right algorithms in the standards,
399 fixing interoperability, or educating implementers and systems
400 administrators. There are user interface issues and education issues
401 too. And there are also legal issues and policy issues for
402 governments.
404 It appears that the public in general demand more privacy and
405 security (e.g., for their children) but are also pessimistic about
406 getting that. They trust that somebody assures that nothing bad
407 happens to them, but they also expect to be spied on all the time.
409 (Perceived) threats of terrorism gave governments a reason to allow
410 widespread surveillance, far beyond what may previously have been
411 considered dangerous for freedom.
413 In this environment, the technical community will have a hard time
414 developing and deploying technologies that fully counter PM, which
415 means there has to be action in the social and political spheres,
416 too.
418 Technology isn't the only thing that can make life harder for
419 attackers. Government-sponsored PM is indirectly affected by trade
420 agreements and treaties and thus it makes sense to lobby for those to
421 be as privacy-friendly as possible.
423 Court cases on the grounds of human rights can also influence policy,
424 especially if they reach, for example, the European Court of Human
425 Rights.
427 In medicine and law, it is common to have ethics committees, not so
428 in software. Should standards bodies such as IETF and W3C have an
429 ethics committee? Standards such as the Geolocation API
430 [w3c-geo-api] have gotten scrutiny from privacy experts, but only in
431 an ad-hoc manner. (W3C has permanent groups to review standards for
432 accessibility and internationalisation. It also has a Privacy group,
433 but that currently doesn't do the same kind of systematic reviews.)
435 As the Internet Draft draft-barnes-pervasive-problem-00 (included as
436 paper 44 [8]) explains, PM doesn't just monitor the networks, but
437 also attacks at the endpoints, turning organisations or people into
438 (willing, unwilling, or unwitting) collaborators. One technical
439 means of protection is thus to design protocols such that there are
440 fewer potential collaborators, e.g., a provider of cloud storage
441 cannot hand over plaintext for content that is encrypted with a key
442 he doesn't have, and cannot hand over names if his client is
443 anonymous.
445 It is important to distinguish between PM and fighting crime. PM is
446 an attack, but a judge ordering the surveillance of a suspected
447 criminal is not. The latter, often abbreviated in this context as LI
448 (for Lawful Intercept), is outside the scope of this workshop.
450 5.5. Improving the tools
452 An earlier session discussed why existing COMSEC tools weren't used
453 more. This second session on COMSEC therefore discussed what
454 improvements and/or new tools were needed.
456 Discussion at the workshop indicated that an important meta-tool for
457 improving existing security technology could be Opportunistic
458 Security (OS) [I-D.kent-opportunistic-security]. The idea is that
459 software is enhanced with a module that tries to encrypt
460 communications when it detects that the other end also has the same
461 capability but otherwise lets the communication continue in the old
462 way. The detailed definition of OS is being discussed by the IETF
463 security area at the time of this workshop [saag].
465 OS would protect against a passive eavesdropper but should also allow
466 for endpoint authentication to protect against an active attacker (a
467 MITM). As OS spreads, more and more communications would be
468 encrypted (and hopefully authenticated) and thus there is less and
469 less for an eavesdropper to collect.
471 Of course, an implementation of OS could give a false sense of
472 security as well: some connections are encrypted, some are not. A
473 user might see something like a padlock icon in browsers, but there
474 was agreement at the workshop that such user interface features ought
475 not be changed because OS is being used.
477 There is also the possibility that a MITM intercepts the reply from a
478 server that says "yes, I can do encryption" and removes it, causing
479 the client to fall back to an unencrypted protocol. Mitigations
480 against this can be to have other channels of finding out a server's
481 capabilities and remembering that a server could do encryption
482 previously.
484 There is also, again, a terminology problem. The technical
485 descriptions of OS talk about "silent fail" when a connection
486 couldn't be encrypted and has to fall back to the old, unencrypted
487 protocol. Actually, it's not a fail; it's no worse than it was
488 before. A successful encryption would rather be a "silent
489 improvement."
491 That raises the question of the UI: How do you explain to a user what
492 their security options are, and, in case an error occurs, how do you
493 explain the implications of the various responses?
495 The people working on encryption are mathematicians and engineers,
496 and typically not the same people who know about UI. We need to
497 involve the experts. We also need to distinguish between usability
498 of the UI, user understanding, and user experience. For an
499 e-commerce site, e.g., it is not just important that the user's data
500 is technically safe, but also that he feels secure. Otherwise he
501 still won't buy anything.
503 When talking about users, we also need to distinguish the end user
504 (who we typically think about when we talk about UI) from the server
505 administrators and other technical people involved in enabling a
506 connection. When something goes wrong (e.g., the user's software
507 detects an invalid certificate), the message usually goes to the end
508 user. But he isn't necessarily the person who can do something about
509 it. E.g., if the problem is a certificate that expired yesterday,
510 the options for the user are to break the connection (the safe
511 choice, but it means he can't get his work done) or continue anyway
512 (there could be a MITM...). The server administrator, on the other
513 hand, could actually solve the problem.
515 Encryption and authentication have a cost, in terms of setting them
516 up, but also in terms of the time it takes for software to do the
517 calculations. The set-up cost can be reduced with sensible defaults,
518 predefined profiles and cut-and-paste configurations. And for some
519 connections, authentication without encryption could be enough, in
520 the case that the data doesn't need to be kept secret, but it is
521 important to know that it is the real data. Most mail user agents
522 (UA) already provide independent options for encryption and signing,
523 but Web servers only support authentication if the connection is also
524 encrypted.
526 On the other hand, as e-mail also shows, it is difficult for users to
527 understand what encryption and authentication do separately.
529 And it also has to be kept in mind that encrypting only the
530 "sensitive" data and not the rest decreases the cost for an attacker,
531 too: It becomes easy to know which connections are worth attacking.
532 Selective field confidentiality is also more prone to lead to
533 developer error, as not all developers will know the provenance of
534 values to be processed.
536 One problem with the TOFU model as used by SSH (see explanation
537 above) is that it lacks a solution for key continuity: When a key is
538 changed (which can happen, e.g., when a server is replaced or the
539 software upgraded), there is no way to inform the client. (In
540 practice, people use other means, such as calling people on the phone
541 or asking their colleagues in the office, but that doesn't scale and
542 doesn't always happen either.) An improvement in the SSH protocol
543 could thus be a way to transfer a new key to a client in a safe way.
545 5.6. Hiding metadata
547 Encryption and authentication help protect the content of messages.
548 Correctly implemented encryption is very hard to crack. (To get the
549 content, an attacker would rather attempt to steal the keys, corrupt
550 the encoding software, or get the content via a collaborator.) But
551 encrypting the content doesn't hide the fact that you are
552 communicating. This metadata (who talks to whom, when and for how
553 long) is often as interesting as the content itself, and in some
554 cases the size and timing of messages is even an accurate predictor
555 of the content. So how to stop an attacker from collecting metadata,
556 given that much of that data is actually needed by routers and other
557 services to deliver the message to the right place?
559 It is useful to distinguish different kinds of metadata: explicit (or
560 metadata proper) and implicit (sometimes called traffic data).
561 Implicit metadata is things that can be derived from a message or are
562 necessary for its delivery, such as the destination address, the
563 size, the time, or the frequency with which messages pass. Explicit
564 metadata is things like quality ratings, provenance or copyright
565 data: data about the data, useful for an application, but not
566 required to deliver the data to its endpoint.
568 A system such as Tor hides much of the metadata by passing through
569 several servers, encrypting all the data except that which a
570 particular server needs to see. Each server thus knows which server
571 a message came from and where he has to send it to, but cannot know
572 where the previous server got it from or where the next server is
573 instructed to send it. However, deliberately passing through
574 multiple servers makes the communication slower than taking the most
575 direct route and increases the amount of traffic the network as a
576 whole has to process.
578 There are three kinds of measures that can be taken to make metadata
579 harder to get: aggregation, contraflow and multipath (see paper 4
580 [9]). New protocols should be designed such that these measures are
581 not inadvertently disallowed, e.g., because the design assumes that
582 the whole of a conversation passes through the same route.
584 "Aggregation" means collecting conversations from multiple sources
585 into one stream. E.g., if HTTP connections pass through a proxy, all
586 the conversations appear to come from the proxy instead of from their
587 original sources. (This assumes that telltale information in the
588 headers is stripped by the proxy, or that the connection is
589 encrypted.) It also works in the other direction: if multiple Web
590 sites are hosted on the same server, an attacker cannot see which of
591 those Web sites a user is reading. (This assumes that the name of
592 the site is in the path info of the URL and not in the domain name,
593 otherwise watching DNS queries can still reveal the name.)
595 "Contraflow" means routing a conversation via one or more other
596 servers than the normal route, e.g., by using a tunnel (e.g., with
597 SSH or a VPN) to another server. Tor is an example of this. An
598 attacker must watch more routes and do more effort to correlate
599 conversations. (Again, this assumes that there is no telltale
600 information left in the messages that leave the tunnel.)
602 "Multipath" splits up a single conversation (or a set of related
603 conversations) and routes the parts in different ways. E.g., sending
604 a request via a satellite link and receiving the response via a land
605 line; or starting a conversation on a cellular link and continuing it
606 via Wi-Fi. This again increases the cost for an attacker, who has to
607 monitor and correlate multiple networks.
609 Protecting metadata automatically with technology at a lower layer
610 than the application layer is difficult. The applications themselves
611 need to pass less data, e.g., use anonymous temporary handles instead
612 of permanent identifiers. There is often no real need for people to
613 use the same identifier on different computers (smartphone, desktop,
614 etc.) other than that the application they use was designed that way.
616 One thing that can be done relatively easily in the short term is to
617 go through existing protocols to check what data they send that isn't
618 really necessary. One candidate mentioned for such a study was XMPP.
620 "Fingerprinting" is the process of distinguishing different senders
621 of messages based on metadata: Clients can be recognised (or at least
622 grouped) because their messages always have a combination of features
623 that other clients do not have. Reducing redundant metadata and
624 reducing the number of optional features in a protocol reduces the
625 variation between clients and thus makes fingerprinting harder.
627 Traffic analysis is a research discipline that produces sometimes
628 surprising findings, which are little known among protocol
629 developers. Some collections of results are
631 o A selected bibliography on anonymity [10] by the Free Haven
632 Project,
634 o The yearly Symposium on Privacy Enhancing Technologies (PETS)
635 [11], and
637 o The yearly Workshop on Privacy in the Electronic Society (WPES)
638 [12].
640 Techniques that deliberately change the timing or size of messages,
641 such as padding, can also help reduce fingerprinting. Obviously,
642 they make conversations slower and/or use more bandwidth, but in some
643 cases that is not an issue, e.g., if the conversation is limited by
644 the speed of a human user anyway. HTTP/2 has a built-in padding
645 mechanism. However, it is not so easy to use these techniques well,
646 and not actually make messages easier to recognise rather than
647 harder.
649 Different users in different contexts may have different security
650 needs, so maybe the priority can be a user choice (if that can be
651 done without making high-security users stand out from other users).
652 Although many people would not understand what their choices are,
653 some do, such as political activists or journalists.
655 5.7. Deployment, intermediaries and middleboxes
657 Secure protocols have often been designed in the past for end-to-end
658 security: Intermediaries cannot read or modify the messages. This is
659 the model behind TLS for example.
661 In practice, however, people have more or less valid reasons to
662 insist on intermediaries: companies filtering incoming and outgoing
663 traffic for viruses or other reasons, giving priority to certain
664 communications or caching to reduce bandwidth.
666 In the presence of end-to-end encryption and authentication, these
667 intermediaries have two choices: use fake certificates to impersonate
668 the endpoints or have access to the private keys of the endpoints.
669 The former is a MITM attack that is difficult to distinguish from a
670 more malicious one, and the latter obviously decreases the security
671 of the endpoints by copying supposedly protected data and
672 concentrating such data in a single place.
674 As mentioned in Section 5.2 above, aggregation of data in a single
675 place makes that place an attractive target. And in the case of PM
676 even if the data is not concentrated physically in one place, it is
677 under control of a single legal entity that can be made into a
678 collaborator.
680 The way Web communication with TLS typically works is that the client
681 authenticates the server, but the server does not authenticate the
682 client at the TLS layer. (If the client needs to be identified, that
683 is mainly done at the application layer via passwords or cookies.)
684 Thus the presence of a MITM (middlebox) could be detected by the
685 client (because of the incorrect certificate), but not by the server.
686 If the client doesn't immediately close the connection (which they do
687 not in many cases), the server may thus disclose information that the
688 user would rather not have disclosed.
690 One widespread example of middleboxes is captive portals, as found on
691 the Wi-Fi hotspots in hotels, airports, etc. Even the hotspots
692 offering free access often intercept communications to redirect the
693 user to a login or policy page.
695 When the communication they intercept is, e.g., the automatic update
696 of your calendar program or a chat session, the redirect obviously
697 doesn't work: these applications don't know how to display a Web
698 page. With the increasing use of applications, it may be a while
699 before the user actually opens a browser. The flood of error
700 messages may also have as a result that the user no longer reads the
701 errors, allowing an actual malicious attack to go unnoticed.
703 Some operating systems now come with heuristics that try to recognise
704 captive portals and either automatically login or show their login
705 page in a separate application. (But some hotspot providers
706 apparently don't want automatic logins and actually reverse-
707 engineered the heuristics to try and fool them.)
709 It seems some protocol is missing in this case. Captive portals
710 shouldn't have to do MITM attacks to be noticed. Something like an
711 extension to DHCP that tells a connecting device about the login page
712 may help, although that still doesn't solve the problem for devices
713 that do not have a Web browser, such as game consoles or SIP phones.
714 HTTP response code 511 (defined in [RFC6585]) is another attempt at a
715 partial solution (Partial, because it can only work at the moment the
716 user uses a browser to connect to a Web site and doesn't use HTTPS).
718 A practical problem with deployment of such a protocol may be that
719 many such captive portals are very old and never updated. The hotel
720 staff only knows how to reboot the system and as long as it works,
721 the hotel has no incentive to buy a new one. As evidence of this:
722 how many such systems require you to get a password and the ticket
723 shows the price as zero? This is typically because the owner doesn't
724 know how to reconfigure the hotspot, but he does know how to change
725 the price in his cash register.
727 5.8. Break-out 1 - research
729 Despite some requests earlier in the workshop, the research break-out
730 did not discuss clean-slate approaches. The challenge was rather
731 that the relationship between security research and standardisation
732 needs improvement. Research on linkability is not yet well known in
733 the IETF. But the other side of the coin needs improvement too:
734 While doing protocol design, standardisation should indicate what
735 specific problems are in need of more research.
737 The break-out then made a non-exclusive list of topics that are in
738 need of further research:
740 o The interaction of compression and encryption as demonstrated by
741 the CRIME SSL/TLS vulnerability [13]
743 o A more proactive deprecation of algorithms based on research
744 results
746 o Mitigation for return-oriented programming attacks
748 o How to better obfuscate so called "metadata"
750 o How to make the existence of traffic and their endpoints stealthy
752 5.9. Break-out 2 - clients
754 Browsers are the first clients one thinks of when talking about
755 encrypted connections, authentication and certificates, but there are
756 many others.
758 Other common case of "false" alarms for MITM (after captive portals)
759 include expired and mis-configured certificates. This is quite
760 common in intranets, when the sysadmin hasn't bothered updating a
761 certificate and rather tells his handful of users to just "click
762 continue." The problem is on the one hand that users may not
763 understand the difference between this case and the same error
764 message when they connect to a server outside the company, and on the
765 other hand that the incorrect certificate installed by the sysadmin
766 is not easily distinguishable from an incorrect certificate from a
767 MITM. The error message is almost the same and the user may just
768 click continue again.
770 One way to get rid of such certificates is if client software no
771 longer offers the option to continue after a certificate error. That
772 requires that all major clients (such as browsers) change their
773 behaviour at the same time, otherwise the first one to do so will be
774 considered broken by users, because the others still work. Also it
775 requires a period in which that software gives increasingly strong
776 warnings about the cut-off date after which the connection will fail
777 with this certificate.
779 Yet another source of error messages is self-signed certificates.
780 Such certificates are actually only errors for sites that are not
781 expected to have them. If a message about a self-signed certificate
782 appears when connecting to Facebook or Google, you're clearly not
783 connected to the real Facebook or Google. But for a personal Website
784 it shouldn't cause such scary warnings. There may be ways to improve
785 the explanations in the error message and provide an easy way to
786 verify the certificate (by e-mail, over the phone or some other
787 channel) and trust it.
789 5.10. Break-out 3 - on by default
791 One step in improving security is to require the relevant features,
792 in particular encryption and authentication, to be implemented in
793 compliant products: The features are labelled as MUST in the standard
794 rather than MAY. This is sometimes referred to as Mandatory To
795 Implement (MTI) and is the current practice for IETF
796 protocols[RFC3365].
798 But that may not be enough to counter PM. It may be that the
799 features are there, but not used, because only very knowledgeable
800 users or sysadmins turn them on. Or it may be that implementations
801 do not actually follow the MTI parts of specifications. Or it may be
802 that some security features are implemented but interoperability for
803 those doesn't really work. Or, even worse, it may be that protocol
804 designers have only followed the letter of the MTI best practice and
805 not its spirit, with the result that security features are hard to
806 use or make deployment harder. One can thus argue that such features
807 should be defined to be on by default.
809 Going further one might argue that these features should not even be
810 options, i.e., there should be no way to turn them off. This is
811 sometimes called Mandatory To Use (MTU).
813 The question raised at this session was for what protocols on-by-
814 default is appropriate, and how can one explain to the developers of
815 such protocols that it is needed?
817 There would of course be resistance to MTU security from implemeters
818 and deployments that practice deep packet inspection (DPI) and also
819 perhaps from some governments. On the other hand, there may also be
820 governments that outlaw protocols without proper encryption.
822 This break-out concluded that there could be value in attempting to
823 document a new Best Current Practice for the IETF that moves from the
824 current MTI position to one where security features are on-by-
825 default. Some of the workshop participants expressed interest in
826 authoring a draft for such a new BCP and progressing that through the
827 IETF consensus process (where it would no doubt be controversial).
829 5.11. Break-out 4 - measurement
831 There was a small break-out on the idea of measurement as a way to
832 encourage or gamify the increased use of security mechanisms.
834 5.12. Break-out 5 - opportunistic
836 This break out considered the use of the term "opportunistic" as it
837 applies to cryptographic security and attempted to progress the work
838 towards arriving at an agreed-upon definition for use of that term,
839 at it applies to IETF and W3C work.
841 While various terms had been used, with many people talking about
842 opportunistic encryption, that usage was felt to be problematic both
843 because it conflicted with the use of the same term in [RFC4322] and
844 because it was being used differently in different parts of the
845 community.
847 At the session it was felt that the term "opportunistic keying" was
848 better, but as explained above subsequent list discussion resulted in
849 a move to the term "Opportunistic Security" (OS).
851 Aside from terminology, disussion focused on the use of Diffie-
852 Hellman (D-H) key exchange as the preferred mechanism of OS, with
853 fall back to cleartext if D-H doesn't succeed as a counter for
854 passive attacks.
856 There was also of course the desire to be able to easily escalate
857 from countering passive attacks to also handling endpoint
858 authentication and thereby also countering MITM attacks.
860 Making OS visible to users was again considered to be undesirable, as
861 users could not be expected to distinguish between cleartext, OS and
862 (one-sided or mutual) endpoint authentication.
864 Finally, it was noted that it may take some effort to establish how
865 middleboxes might affect OS at different layers and that OS really is
866 not suitable as the only migitation to use for high-sensitivity
867 sessions such as financial transactions.
869 5.13. Unofficial Transport/Routing Break-out
871 Some routing and transport area directors felt a little left out by
872 all the application layer break-outs, so they had their own
873 brainstorm about what could be done at the Transport and Routing
874 layers from which these notes resulted.
876 The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer
877 service that is reordering and delay insensitive. Use of LDEBAT
878 could offer the following benefits for an application:
880 a. Because it is reordering-insensitive, traffic can be sprayed
881 across a large number of forwarding paths. Assuming such
882 different paths exist, this would make it more challenging to
883 capture and analyze a full interaction.
885 b. The application can vary the paths by indicating per packet a
886 different flow. In IPv6, this can be done via different IPv6
887 flow labels. For IPv4, this can be done by encapsulating the IP
888 packet into UDP and varying the UDP source port.
890 c. Since LEDBAT is delay-insensitive and applications using it would
891 need to be as well, it would be possible to obfuscate the
892 application signatures by varying the packet lengths and
893 frequency.
895 d. This can also hide the transport header (for IP in UDP).
897 e. If the Reverse Path Forwarding(RPF)[RFC3704] check problem can be
898 fixed, perhaps the source could be hidden, however it assumes the
899 trafic is within trusted perimeters.
901 f. The use of LEDBAT is orthogonal to the use of encryption and
902 provides different benefits (harder to intercept the whole
903 conversation, ability to obfuscate the traffic analysis), and
904 also has different costs (longer latency, new transport protocol
905 usage) to its users.
907 The idea of encrypting traffic from customer edge (CE) to CE as part
908 of an L3VPN or such was also discussed. This could allow hiding of
909 addresses, including source, and headers. From conversation with Ron
910 Bonica, some customers already do encryption (though not hiding the
911 source address) like this. So, it is unclear that this is very
912 practically useful as an enhancement except for encouraging
913 deployment and use.
915 Finally, it was discussed whether it would be useful to have a means
916 of communicating where and what layers are doing encryption on an
917 application's traffic path. The initial idea of augmenting ICMP has
918 some issues (not visible to application, ICMP packets frequently
919 filtered) as well as potential work (determining how to trust the
920 report of encryption). It would be interesting to understand if such
921 communication is actually needed and what the requirements would be.
923 6. After the workshop
925 Holding the workshop just before the IETF had the intended effect: a
926 number of people went to both the workshop and the IETF, and they
927 took the opportunity of being together at the IETF to continue the
928 discussions.
930 IETF Working groups meeting in London took the recommendations from
931 the workshop into account. It was even the first item in the report
932 about the IETF meeting by the IETF chair, Jari Arkko:
934 "Strengthening the security and privacy of the Internet continued
935 to draw a lot of attention. The STRINT workshop organised by the
936 IAB and W3C just before the IETF attracted 100 participants and
937 over 60 papers. Even more people would have joined us, but there
938 was no space. During the IETF meeting, we continued discussing
939 the topic at various working groups. A while ago we created the
940 first working group specifically aimed at addressing some of the
941 issues surrounding pervasive monitoring. The Using TLS for
942 Applications (UTA) working group had its first meeting in London.
943 But many other working groups also address these issues in their
944 own work. The TCPM working group discussed a proposal to add
945 opportunistic keying mechanisms directly onto the TCP protocol.
946 And the DNSE BOF considered the possibility of adding
947 confidentiality support to DNS queries. Finally, there is an
948 ongoing effort to review old specifications to search for areas
949 that might benefit from taking privacy and data minimisation
950 better into account."[Arkko1]
952 Two papers that were written for the workshop, but not finished in
953 time, are worth mentioning, too: One by the same Jari Arkko, titled
954 "Privacy and Networking Functions" [Arkko2]; and one by Johan
955 Pouwelse, "The Shadow Internet: liberation from Surveillance,
956 Censorship and Servers" [draft-pouwelse-perpass-shadow-internet]
958 7. IANA considerations
960 There are none. We hope the RFC editor deletes this section.
962 8. Security considerations
964 This document does not define a technology but is all about security
965 and privacy.
967 9. References
969 9.1. Informative references
971 [Arkko1] Arkko, J., "IETF-89 Summary", March 2014,
972 .
974 [Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014,
975 .
978 (Work in progress.)
980 [draft-ietf-websec-key-pinning]
981 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
982 Extension for HTTP", February 2014.
984 (Work in progress.)
986 [draft-pouwelse-perpass-shadow-internet]
987 Pouwelse, J., Ed., "The Shadow Internet: liberation from
988 Surveillance, Censorship and Servers", February 2014,
989 .
992 (Work in progress.)
994 [I-D.barnes-pervasive-problem]
995 Barnes, R., Schneier, B., Jennings, C., and T. Hardie,
996 "Pervasive Attack: A Threat Model and Problem Statement",
997 draft-barnes-pervasive-problem-01 (work in progress), July
998 2014.
1000 [I-D.kent-opportunistic-security]
1001 Kent, S., "Opportunistic Security as a Countermeasure to
1002 Pervasive Monitoring", draft-kent-opportunistic-
1003 security-01 (work in progress), April 2014.
1005 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1006 A., Peterson, J., Sparks, R., Handley, M., and E.
1007 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1008 DOI 10.17487/RFC3261, June 2002,
1009 .
1011 [RFC3365] Schiller, J., "Strong Security Requirements for Internet
1012 Engineering Task Force Standard Protocols", BCP 61,
1013 RFC 3365, DOI 10.17487/RFC3365, August 2002,
1014 .
1016 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1017 Text on Security Considerations", BCP 72, RFC 3552,
1018 DOI 10.17487/RFC3552, July 2003,
1019 .
1021 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1022 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
1023 2004, .
1025 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1026 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
1027 January 2006, .
1029 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic
1030 Encryption using the Internet Key Exchange (IKE)",
1031 RFC 4322, DOI 10.17487/RFC4322, December 2005,
1032 .
1034 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1035 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
1036 March 2011, .
1038 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
1039 Codes", RFC 6585, April 2012.
1041 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
1042 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
1043 DOI 10.17487/RFC6817, December 2012,
1044 .
1046 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1047 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1048 .
1050 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
1051 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
1052 2014, .
1054 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1055 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1056 December 2014, .
1058 [saag] Area, S., "IETF Security Area mailing list", March 2014,
1059 .
1062 [vancouverplenary]
1063 IETF, , "IETF 88 Technical Plenary Minutes",
1064 .
1067 [w3c-geo-api]
1068 Popescu, A., "Geolocation API Specification", October
1069 2013, .
1071 9.2. URIs
1073 [1] http://www.w3.org/
1075 [2] https://www.iab.org/
1077 [3] https://www.w3.org/2014/strint/Overview.html
1079 [4] https://www.ietf.org/meeting/89/index.html
1081 [5] http://www.strews.eu/
1083 [6] https://en.wikipedia.org/wiki/Captive_portal
1085 [7] http://tools.ietf.org/html/bcp72
1087 [8] https://www.w3.org/2014/strint/papers/44.pdf
1089 [9] https://www.w3.org/2014/strint/papers/04.pdf
1091 [10] http://freehaven.net/anonbib/
1093 [11] http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html
1095 [12] http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html
1097 [13] https://community.qualys.com/blogs/securitylabs/2012/09/14/crime
1098 -information-leakage-attack-against-ssltls
1100 [14] http://www.strews.eu/
1102 [15] http://cordis.europa.eu/fp7/ict/
1104 [16] http://blog.digital.telefonica.com/
1106 [17] https://www.ietf.org/meeting/89/index.html
1108 [18] http://lists.i1b.org/pipermail/strint-attendees-i1b.org/
1110 [19] https://www.w3.org/2014/strint/
1112 [20] https://twitter.com/search?q=%23strint
1114 [21] http://www.w3.org/2014/02/28-strint-minutes.html
1116 [22] http://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf
1118 [23] http://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf
1120 [24] http://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf
1122 [25] http://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf
1124 [26] http://www.w3.org/2014/03/01-strint-minutes.html
1126 [27] http://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf
1128 [28] http://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf
1130 [29] http://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf
1132 [30] http://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf
1134 [31] http://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf
1136 [32] https://www.w3.org/2014/strint/slides/summary.pdf
1138 [33] https://www.cs.tcd.ie/Stephen.Farrell/
1140 [34] http://www.w3.org/People/Rigo/
1142 [35] http://www.tschofenig.priv.at/wp/?page_id=5
1144 Appendix A. Logistics
1146 The workshop was organised by the STREWS [14] project (a research
1147 project funded under the European Union's 7th Framework Programme
1148 [15]), as the first of two workshops in its work plan. The
1149 organisers were supported by the IAB and W3C, and, for the local
1150 organisation, by Telefonica Digital. [16]
1152 One of the suggestions in the project description of the STREWS
1153 project was to attach the first workshop to an IETF meeting. The
1154 best opportunity was IETF 89 [17] in London, which would begin on
1155 Sunday March 2, 2014. Telefonica Digital offered meeting rooms at
1156 its offices in central London for the preceding Friday and Saturday,
1157 just minutes away from the IETF's location.
1159 The room held 100 people, which was thought to be sufficient. There
1160 turned out to be more interest than expected and we could have filled
1161 a larger room, but 100 people is probably an upper limit for good
1162 discussions anyway.
1164 Apart from the usual equipment in the room (projector, white boards,
1165 microphones, coffee...), we also set up some extra communication
1166 channels:
1168 o A mailing list where participants could discuss the agenda and the
1169 published papers about three weeks in advance of the workshop
1170 itself. (Only participants were allowed to write to the mailing
1171 list, but the archive [18] is public.)
1173 o Publicly advertised streaming audio (one-way only). At some
1174 point, no less than 165 people were listening.
1176 o An IRC channel for live minute taking, passing links and other
1177 information, and as a help for remote participants to follow the
1178 proceedings.
1180 o An Etherpad, where the authors of papers could provide an abstract
1181 of their submissions, to help participants who could not read all
1182 66 papers in full in advance of the workshop. The abstracts were
1183 also used on the workshop's Web site [19].
1185 o A "Twitter hashtag" (#strint). Four weeks after the workshop,
1186 there were still a few new messages [20] about events related to
1187 workshop topics.
1189 Appendix B. Agenda
1191 This was the final agenda of the workshop, as determined by the TPC
1192 and participants on the mailing list prior to the workshop. The
1193 included links are to the slides that the moderators used to
1194 introduce each discussion topic and to the minutes.
1196 B.1. Friday 28 February
1198 Minutes [21]
1200 Workshop starts, welcome, logistics, opening/overview [slides]
1201 [22]
1203 * Goal is to plan how we respond to PM threats
1205 * Specific questions to be discussed in sessions
1207 * Outcomes are actions for IETF, W3C, IRTF, etc.
1209 I. Threats - What problem are we trying to solve? (Presenter:
1210 Richard Barnes; Moderator: Cullen Jennings) [slides] [23]
1212 * What attacks have been described? (Attack taxonomy)
1214 * What should we assume the attackers' capabilities are?
1216 * When is it really "pervasive monitoring" and when is it not?
1218 * Scoping - what's in and what's out? (for IETF/W3C)
1220 II. COMSEC 1 - How can we increase usage of current COMSEC tools?
1221 (Presenter: Hannes Tschofenig; Moderator: Leif Johansson) [slides]
1222 [24]
1224 * Whirlwind catalog of current tools
1226 * Why aren't people using them? In what situations are / aren't
1227 they used?
1229 * Securing AAA and management protocols - why not?
1231 * How can we (IETF/W3C/community) encourage more/better use?
1233 III. Policy - What policy / legal/ other issues need to be taken
1234 into account? (Presenter: Christine Runnegar; Moderator: Rigo
1235 Wenning) [slides] [25]
1236 * What non-technical activities do we need to be aware of?
1238 * How might such non-technical activities impact on IETF/W3C?
1240 * How might IETF/W3C activities impact on those non-technical
1241 activities?
1243 Session IV - Saturday plan, open-mic, wrap up day
1245 B.2. Saturday 1 March
1247 Minutes [26]
1249 IV. COMSEC 2 - What improvements to COMSEC tools are
1250 needed?(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
1251 [slides] [27]
1253 * Opportunistic encryption - what is it and where it might apply
1255 * Mitigations aiming to block PM vs. detect PM - when to try
1256 which?
1258 V. Metadata - How can we reduce the metadata that protocols
1259 expose? (Presenter: Alfredo Pironti [slides] [28] / Ted Hardie
1260 [slides] [29]; Moderator: Alissa Cooper [slides] [30])
1262 * Meta-data, fingerprinting, minimisation
1264 * What's out there?
1266 * How can we do better?
1268 VI. Deployment - How can we address PM in deployment /
1269 operations? (Presenter: Eliot Lear; Moderator: Barry Leiba)
1270 [slides] [31]
1272 * "Mega"-commercial services (clouds, large scale email & SN,
1273 SIP, WebRTC...)
1275 * Target dispersal - good goal or wishful thinking?
1277 * Middleboxes: when a help and when a hindrance?
1279 VII. 3 x Break-out Sessions / Bar-Camp style (Hannes Tschofenig)
1281 * Content to be defined during meeting, as topics come up
1283 * Sum up at the end to gather conclusions for report
1284 Break-outs:
1286 1. Research Questions (Moderator: Kenny Paterson)
1288 + Do we need more/different crypto tools?
1290 + How can applications make better use of COMSEC tools?
1292 + What research topics could be handled in IRTF?
1294 + What other research would help?
1296 2. clients
1298 3. on by default
1300 4. measuring
1302 5. opportunistic
1304 VIII. Break-out reports, Open mic & Conclusions - What are we
1305 going to do to address PM? [slides] [32]
1307 * Gather conclusions / recommendations / goals from earlier
1308 sessions
1310 Appendix C. Workshop chairs & program committee
1312 The workshop chairs were three: Stephen Farrell [33] (TCD) and Rigo
1313 Wenning [34] (W3C) from the STREWS project, and Hannes Tschofenig
1314 [35] (ARM) from the STREWS Interest Group.
1316 A program committee (PC) was charged with evaluating the submitted
1317 papers. It was made up of the members of the STREWS project, the
1318 members of the STREWS Interest Group, plus invited experts: Bernard
1319 Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard
1320 Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen
1321 O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP),
1322 Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal
1323 Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler
1324 (Microsoft) and Sean Turner (IECA).
1326 Appendix D. Participants
1328 The participants to the workshop were:
1330 o Bernard Aboba (Microsoft Corporation)
1331 o Thijs Alkemade (Adium)
1333 o Daniel Appelquist (Telefonica Digital)
1335 o Jari Arkko (Ericsson)
1337 o Alia Atlas (Juniper Networks)
1339 o Emmanuel Baccelli (INRIA)
1341 o Mary Barnes
1343 o Richard Barnes (Mozilla)
1345 o Steve Bellovin (Columbia University)
1347 o Andrea Bittau (Stanford University)
1349 o Marc Blanchet (Viagenie)
1351 o Carsten Bormann (Uni Bremen TZI)
1353 o Bert Bos (W3C)
1355 o Ian Brown (Oxford University)
1357 o Stewart Bryant (Cisco Systems)
1359 o Randy Bush (IIJ / Dragon Research Labs)
1361 o Kelsey Cairns (Washington State University)
1363 o Stuart Cheshire (Apple)
1365 o Vincent Cheval (University of Birmingham)
1367 o Benoit Claise (Cisco)
1369 o Alissa Cooper (Cisco)
1371 o Dave Crocker (Brandenburg InternetWorking)
1373 o Leslie Daigle (Internet Society)
1375 o George Danezis (University College London)
1377 o Spencer Dawkins (Huawei)
1378 o Mark Donnelly (Painless Security)
1380 o Nick Doty (W3C)
1382 o Dan Druta (AT&T)
1384 o Peter Eckersley (Electronic Frontier Foundation)
1386 o Lars Eggert (NetApp)
1388 o Kai Engert (Red Hat)
1390 o Monika Ermert
1392 o Stephen Farrell (Trinity College Dublin)
1394 o Barbara Fraser (Cisco)
1396 o Virginie Galindo (gemalto)
1398 o Stefanie Gerdes (Uni Bremen TZI)
1400 o Daniel Kahn Gillmor (ACLU)
1402 o Wendy M. Grossman
1404 o Christian Grothoff (The GNUnet Project)
1406 o Oliver Hahm (INRIA)
1408 o Joseph Lorenzo Hall (Center for Democracy & Technology)
1410 o Phillip Hallam-Baker
1412 o Harry Halpin (W3C/MIT and IRI)
1414 o Ted Hardie (Google)
1416 o Joe Hildebrand (Cisco Systems)
1418 o Russ Housley (Vigil Security, LLC)
1420 o Cullen Jennings (CISCO)
1422 o Leif Johansson (SUNET)
1424 o Harold Johnson (Irdeto)
1425 o Alan Johnston (Avaya)
1427 o L. Aaron Kaplan (CERT.at)
1429 o Steve Kent (BBN Technologies)
1431 o Achim Klabunde (European Data Protection Supervisor)
1433 o Hans Kuhn (NOC)
1435 o Christian de Larrinaga
1437 o Ben Laurie (Google)
1439 o Eliot Lear (Cisco Ssytems)
1441 o Barry Leiba (Huawei Technologies)
1443 o Sebastian Lekies (SAP AG)
1445 o Orit Levin (Microsoft Corporation)
1447 o Carlo Von LynX (#youbroketheinternet)
1449 o Xavier Marjou (Orange)
1451 o Larry Masinter (Adobe)
1453 o John Mattsson (Ericsson)
1455 o Patrick McManus (Mozilla)
1457 o Doug Montgomery (NIST)
1459 o Kathleen Moriarty (EMC)
1461 o Alec Muffett (Facebook)
1463 o Suhas Nandakumar (Cisco Systems)
1465 o Linh Nguyen (ERCIM/W3C)
1467 o Linus Nordberg (NORDUnet)
1469 o Mark Nottingham
1471 o Karen O'Donoghue (Internet Society)
1472 o Piers O'Hanlon (Oxford Internet Institute)
1474 o Kenny Paterson (Royal Holloway, University of London)
1476 o Jon Peterson (Neustar)
1478 o Joshua Phillips (University of Birmingham)
1480 o Alfredo Pironti (INRIA)
1482 o Dana Polatin-Reuben (University of Oxford)
1484 o Prof. Johan Pouwelse (Delft University of Technology)
1486 o Max Pritikin (Cisco)
1488 o Eric Rescorla (Mozilla)
1490 o Pete Resnick (Qualcomm Technologies, Inc.)
1492 o Tom Ristenpart (University of Wisconsin)
1494 o Andrei Robachevsky (Internet Society)
1496 o David Rogers (Copper Horse)
1498 o Scott Rose (NIST)
1500 o Christine Runnegar (Internet Society)
1502 o Philippe De Ryck (DistriNet - KU Leuven)
1504 o Peter Saint-Andre (&yet)
1506 o Runa A. Sandvik (Center for Democracy and Technology)
1508 o Jakob Schlyter
1510 o Dr. Jan Seedorf (NEC Laboratories Europe)
1512 o Wendy Seltzer (W3C)
1514 o Melinda Shore (No Mountain Software)
1516 o Dave Thaler (Microsoft)
1518 o Brian Trammell (ETH Zurich)
1519 o Hannes Tschofenig (ARM Limited)
1521 o Sean Turner (IECA, Inc.)
1523 o Matthias Waehlisch (Freie Universitaet Berlin)
1525 o Greg Walton (Oxford University)
1527 o Rigo Wenning (W3C)
1529 o Tara Whalen (Apple Inc.)
1531 o Greg Wood (Internet Society)
1533 o Jiangshan Yu (University of Birmingham)
1535 o Aaron Zauner
1537 o Dacheng Zhang (Huawei)
1539 o Phil Zimmermann (Silent Circle LLC)
1541 o Juan-Carlos Zuniga (InterDigital)
1543 Authors' Addresses
1545 Stephen Farrell
1546 Trinity College, Dublin
1548 Email: stephen.farrell@cs.tcd.ie
1550 Rigo Wenning
1551 World Wide Web Consortium
1552 2004, route des Lucioles
1553 B.P. 93
1554 Sophia-Antipolis 06902
1555 France
1557 Email: rigo@w3.org
1558 Bert Bos
1559 World Wide Web Consortium
1560 2004, route des Lucioles
1561 B.P. 93
1562 Sophia-Antipolis 06902
1563 France
1565 Email: bert@w3org
1567 Marc Blanchet
1568 Viagenie
1569 246 Aberdeen
1570 Quebec, QC G1R 2E1
1571 Canada
1573 Email: Marc.Blanchet@viagenie.ca
1574 URI: http://viagenie.ca
1576 Hannes Tschofenig
1577 ARM Ltd.
1578 110 Fulbourn Rd
1579 Cambridge CB1 9NJ
1580 Great Britain
1582 Email: Hannes.tschofenig@gmx.net
1583 URI: http://www.tschofenig.priv.at