idnits 2.17.1
draft-iab-strint-report-00.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 800: '...s are labelled as MUST in the standard...'
RFC 2119 keyword, line 801: '... 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 (April 28, 2014) is 3651 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC4778' is mentioned on line 2092, but not defined
== Outdated reference: A later version (-01) exists of
draft-barnes-pervasive-problem-00
-- Obsolete informational reference (is this intentional?): RFC 6962
(Obsoleted by RFC 9162)
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: October 30, 2014 B. Bos
6 W3C
7 M. Blanchet
8 Viagenie
9 H. Tschofenig
10 ARM Ltd.
11 April 28, 2014
13 STRINT workshop report
14 draft-iab-strint-report-00
16 Abstract
18 The STRINT workshop assembled one hundred participants in London for
19 two days in early 2014 to discuss how the technical community, and in
20 particular the IETF and the W3C, should react to Pervasive Monitoring
21 and more generally how to strengthen the Internet in the face of such
22 attacks. The discussions covered issues of terminology, the role of
23 user interfaces, classes of mitigation, some specific use cases,
24 transition strategies (including opportunistic encryption), and more.
25 The workshop ended with a few high-level recommendations, which it is
26 believed could be implemented and which could help strengthen the
27 Internet. This is the report of that workshop.
29 Status of this Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on October 30, 2014.
46 Copyright Notice
48 Copyright (c) 2014 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document.
58 Table of Contents
60 1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Workshop goals . . . . . . . . . . . . . . . . . . . . . . . . 5
63 4. Workshop structure . . . . . . . . . . . . . . . . . . . . . . 5
64 5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 6. After the workshop . . . . . . . . . . . . . . . . . . . . . . 20
66 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
67 8. Security considerations . . . . . . . . . . . . . . . . . . . 21
68 9. Informative references . . . . . . . . . . . . . . . . . . . . 21
69 Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . . 24
70 Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 25
71 Appendix C. The submitted papers . . . . . . . . . . . . . . . . 28
72 Appendix D. Workshop chairs & program committee . . . . . . . . . 44
73 Appendix E. Participants . . . . . . . . . . . . . . . . . . . . 45
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
76 1. Context
78 [[Editorial note: This version was produced from the minutes, and
79 then edited. It quite likely has some inaccuracies, so the authors
80 would welcome corrections from those who attended the workshop. If
81 you're a github person, https://github.com/sftcd/strint-report has
82 this so you can contribute there.]]
84 The Vancouver IETF plenary concluded [vancouverplenary] that
85 Pervasive Monitoring (PM) represents an attack on the Internet, and
86 the IETF has begun to carry out the more obvious actions required to
87 try to handle this attack. However, there are additional much more
88 complex questions arising that need further consideration before any
89 additional concrete plans can be made.
91 The W3C [1] and IAB [2] therefore decided to host a workshop [3] on
92 the topic of "Strengthening the Internet Against Pervasive
93 Monitoring" before IETF 89 [4] in London in March 2014. The FP7-
94 funded STREWS [5] project organised the STRINT workshop on behalf of
95 the IAB and W3C.
97 The main workshop goal was to discuss what can be done, especially by
98 the two standards organisations IETF and W3C, against PM, both for
99 existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones
100 (WebRTC, HTTP/2, etc.).
102 The starting point for the workshop was the existing IETF consensus
103 that PM is an attack[I-D.farrell-perpass-attack].
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 (see Appendix C),
112 except for a few where authors who couldn't take part in the workshop
113 preferred not to 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. We need to document
137 definition(s) for this term, as it is being used differently by
138 different people and in different contexts. We may also be able
139 to develop a cookbook-like set of related protocol techniques
140 for developers. Since the workshop, the IETF's security area
141 has taken up this work, most recently favouring the generic term
142 "Opportunistic Security" (OS) [I-D.kent-opportunistic-security].
144 6. The technical community could do better in explaining the real
145 technical downsides related to PM in terms that policy makers
146 can understand.
148 7. Many User Interfaces (UI) could be better in terms of how they
149 present security state, though this is a significantly hard
150 problem. There may be benefits if certain dangerous choices
151 were simply not offered anymore. But that could require
152 significant co-ordination among competing software makers,
153 otherwise some will be considered "broken" by users.
155 8. Ways to better integrate UI issues into the processes of IETF
156 and W3C needs further discussion.
158 9. Examples of good software configurations that can be cut-and-
159 paste'd for popular software, etc., can help. This is not
160 necessarily standards work, but maybe the standards
161 organisations can help and can work with those developing such
162 package-specific documentation.
164 10. The IETF and W3C can do more so that default ("out-of-the-box")
165 settings for protocols better protect security and privacy.
167 11. Captive portals, [6] (and some firewalls, too) can and should be
168 distinguished from real man-in-the-middle attacks. This might
169 mean establishing common conventions with makers of such
170 middleboxes, but might also need new protocols. However, the
171 incentives for deploying such new middlebox features might not
172 align.
174 3. Workshop goals
176 As stated, the STRINT workshop started from the position that PM is
177 an attack. [I-D.farrell-perpass-attack] While some dissenting voices
178 are expected and need to be heard, that was the baseline assumption
179 for the workshop, and the high-level goal was to provide more
180 consideration of that and how it ought to affect future work within
181 the IETF and W3C.
183 At the next level down the goals of the STRINT workshop were to:
185 o Discuss and hopefully come to agreement among the participants on
186 concepts in PM for both threats and mitigation, e.g.,
187 "opportunistic" as the term applies to cryptography.
189 o Discuss the PM threat model, and how that might be usefully
190 documented for the IETF at least, e.g., via an update to
191 BCP72. [7]
193 o Discuss and progress common understanding in the trade-offs
194 between mitigating and suffering PM.
196 o Identify weak links in the chain of Web security architecture with
197 respect to PM.
199 o Identify potential work items for the IETF, IAB, IRTF and W3C that
200 help mitigate PM.
202 o Discuss the kinds of action outside the IETF/W3C context might
203 help those done within the IETF/W3C.
205 4. Workshop structure
207 The workshop structure was designed to maximise discussion time.
208 There were no direct presentations of submitted papers. Instead, the
209 moderators of each session summarised topics that the Technical
210 Programme Committee (TPC) had agreed based on the submitted papers.
211 These summary presentations took at most 50% of the session and
212 usually less.
214 Because the papers would not be presented during the workshop,
215 participants were asked to read and discuss the papers beforehand, at
216 least those relevant to their fields of interest. (To help people
217 choose papers to read, authors were asked to provide short
218 abstracts.)
220 Most of the sessions had two moderators, one to lead the discussion,
221 while the other managed the queue of people who wanted to speak.
222 This worked well: everybody got a chance to speak and each session
223 still ended on time.
225 The penultimate session consisted of break-outs. (Which turned out
226 to be the most productive sessions of all, most likely simply due to
227 the smaller numbers of people involved.) The subjects for the break-
228 outs were agreed during the earlier sessions and just before the
229 break-out session the participants collectively determined who would
230 attend which.
232 5. Topics
234 The following sections contain summaries of the various sessions.
235 See the minutes (see Appendix B) for more details.
237 5.1. Opening session
239 The first session discussed the goals of the workshop. Possible
240 approaches to improving security in the light of pervasive monitoring
241 include a critical look at what metadata is actually required,
242 whether old (less secure) devices can be replaced with new ones, what
243 are "low-hanging fruit" (issues that can be handled quickly and
244 easily), and what level of security is "good enough": a good solution
245 may be one that is good for 90% of people or 90% of organisations.
247 Some paricipants felt that standards are needed so that people can
248 see if their systems conform to a certain level of security as well
249 as easy to remember names for those standards, so that a buyer can
250 immediately see that a product "conforms to the named intended
251 standard."
253 5.2. Threats
255 One difference between "traditional" attacks and pervasive monitoring
256 is modus-operandi of the attacker: typically, one determines what
257 resources an attacker might want to target and at what cost and then
258 one defends against that threat. But a pervasive attacker has no
259 specific targets, other than to collect everything he can. The
260 calculation of the cost of losing resources vs the cost of protecting
261 them is thus different. And unlike someone motivated to make money,
262 a PM attacker may not be concerned at the cost of the attack (or may
263 even prefer a higher cost, for "empire building" reasons).
265 The terminology used to talk about threats has to be chosen carefully
266 (this was a common theme in several sessions), because we need to
267 explain to people outside the technical community what they need to
268 do or not do. For example, authentication of endpoints doesn't so
269 much "protect against" man-in-the-middle (MITM) attacks as make them
270 visible. The attacker can still attack, but it does not remain
271 invisible while he does so. Somebody on either end of the
272 conversation needs to react to the alert from the system: stop the
273 conversation or find a different channel.
275 An interesting paradox is the role of big repositories of
276 information, such as Facebook, Yahoo, Google, etc. Hopefully, they
277 supervise their security better than the average Internet server, but
278 they are also much more attractive as a target to attack. Avoiding
279 overuse of such repositories for private or sensitive information may
280 be a useful measure that increases the cost of collecting for a
281 pervasive attacker. This is sometimes called the target-dispersal
282 approach.
284 Lack of interoperability between systems is in itself a threat as it
285 leads to work-arounds and compromises that may be less secure. And
286 thus improving interoperability needs to be high on the list of
287 priorities of standards makers and even more for implementers. Of
288 course, testing, such as interop testing, is at some level, part of
289 the process of IETF and W3C; and W3C is currently increasing its
290 testing efforts.
292 5.3. Increase usage of security tools
294 The first session on Communication Security (COMSEC) tools looked at
295 the question why existing security tools aren't used more.
297 The example of HTTPS is informative: it provides encryption and
298 authentication and is widely available. In practice though, it is
299 far from being used as much as it could be. It also has some
300 problems. One problem is that certificate authorities (CA) are a
301 potential weak link in the system. Any CA can issue a certificate
302 for any server, and thus a single compromised CA can give a MITM the
303 power to impersonate any server. Moreover, certificates can cost
304 money, acquiring a certificate requires administrator time and
305 effort, and certificates need to be replaced when they expire, which
306 is not the normal case for web technologies, so many server
307 administrators forget or don't bother, making the certificate
308 infrastructure less relevant, and causing https to provide less
309 security.
311 Some ideas were discussed for improving the CA system, e.g., via
312 cross-certification of CAs and by means of "certificate
313 transparency": a public, permanent log of who issued which
314 certificate. [RFC6962]
316 Using other models than the hierarchical certificate model (as
317 alternative or in combination) may also help. The PGP model, e.g.,
318 is a flat network where people verify the identity (public key) of
319 people they meet. And then they trust, to a certain level, that
320 those people verified the identity of other people. This works for
321 certain types of communication (it was more deployed for e-mail).
322 However, an identity only verified by a friend of a friend provides a
323 lower level of trust.
325 Yet another model is "trust on first use" (TOFU). This is used quite
326 effectively by SSH [RFC4252]. On the first connection, one has no
327 way to verify that the received public key belongs to the server one
328 is contacting, therefore, the key is accepted without further
329 verification. But on the subsequent connections, one can verify that
330 the received key is the same key as the first time. So a MITM has to
331 be there on all connections, including the first, otherwise it will
332 be detected by a key mismatch.
334 This works well for SSH, because people typically use SSH to
335 communicate with a small number of servers over and over again. And,
336 if they want, they may find a separate channel to get the public key
337 (or its fingerprint). It may also work for Web servers used by small
338 groups (the server of a sports club, a department of a company,
339 etc.), but probably works less well for public servers that are
340 visited once or a few times or for large services where many servers
341 may be used.
343 A similar proposal [draft-ietf-websec-key-pinning] for an HTTP header
344 introduces an aspect of TOFU into HTTP: Key pinning tells HTTP
345 clients that for a certain time after receiving this certificate,
346 they should not expect the certificate to change. If it does, even
347 if the new certificate looks valid, the client should assume a
348 security breach.
350 SIP [RFC3261] is a complex protocol, in part because it potentially
351 needs several different intermediaries in different stages of the
352 communication to deal with NAT traversal and to handle policy. SIP
353 provides hop-by-hop encryption and end-to-end authentication in
354 theory, but in practice many SIP providers disable these functions
355 and interoperability for end-to-end security in SIP is perhaps not in
356 a good state. The reasons for disabling end-to-end security here are
357 understandable: to overcome lack of interoperability they often need
358 to change protocol headers and modify protocol data. Some workshop
359 participants argued that SIP would never have taken off if it hadn't
360 been possible for providers to monitor and interfere in
361 communications in this way. Of course, that means an attacker can
362 listen in just as easily.
364 A new protocol for peer-to-peer communication of video and audio (and
365 potentially other data) is WebRTC. WebRTC re-uses many of the same
366 architectural concepts as SIP, but there is a reasonable chance that
367 it can do better in terms of protecting users: The people
368 implementing the protocols and offering the service have different
369 goals and interests. In particular, the first implementers are
370 browser makers, who may have different business models from other
371 more traditional Voice over IP providers.
373 XMPP suffers from yet another problem. It has encryption and
374 authentication, and the OTR ("off the record") extension even
375 provides what is called Perfect Forward Secrecy (PFS, compromising
376 the current communication never gives an attacker enough information
377 to decrypt past communications that he may have recorded). But, in
378 practice, many people don't use XMPP at all, but rather Skype,
379 WhatsApp or other instant-messaging tools with unknown or no
380 security. The problem here seems to be one of user awareness. And
381 though OTR does provide security, it is not well integrated with XMPP
382 and nor is it available as a core feature of XMPP clients.
384 To increase usage of existing solutions, some tasks can be
385 identified, though how those map to actions for e.g. IETF/W3C is not
386 clear:
388 o Improvements to the certificate system, such as CT.
390 o Making it easier (cheaper, quicker) for system administrators to
391 deploy secure solutions.
393 o Improve awareness of the risks. Identify which communities
394 influence which decisions and what is the appropriate message for
395 each.
397 o Provide an upgrade path that doesn't break existing systems or
398 require that everybody upgrade at the same time. Opportunistic
399 Security may be one model for that.
401 5.4. Policy issues and non-technical actions
403 Previous sessions already concluded that the problem isn't just
404 technical, such as getting the right algorithms in the standards,
405 fixing interoperability, or educating implementers and systems
406 administrators. There are user interface issues and education issues
407 too. And there are also legal issues and policy issues for
408 governments.
410 It appears that the public in general demand more privacy and
411 security (e.g., for their children) but are also pessimistic about
412 getting that. They trust that somebody assures that nothing bad
413 happens to them, but they also expect to be spied on all the time.
415 (Perceived) threats of terrorism gave governments a reason to allow
416 widespread surveillance, far beyond what may previously have been
417 considered dangerous for freedom.
419 In this environment, the technical community will have a hard time
420 developing and deploying technologies that fully counter PM. Which
421 means there has to be action in the social and political spheres,
422 too.
424 Technology isn't the only thing that can make life harder for
425 attackers. Government-sponsored PM is indirectly affected by trade
426 agreements and treaties and thus it makes sense to lobby for those to
427 be as privacy-friendly as possible.
429 Court cases on the grounds of human rights can also influence policy,
430 especially if they reach, for example, the European Court of Human
431 Rights.
433 In medicine and law, it is common to have ethics committees, not so
434 in software. Should standards bodies such as IETF and W3C have an
435 ethics committee? While standards such as the Geolocation API
436 [w3c-geo-api] have gotten scrutiny from privacy experts, but only in
437 an ad-hoc manner. (W3C has permanent groups to review standards for
438 accessibility and internationalisation. It also has a Privacy group,
439 but that currently doesn't do the same kind of systematic reviews.)
441 As the Internet Draft draft-barnes-pervasive-problem-00 (included as
442 paper 44 [8]) explains, PM doesn't just monitor the networks, but
443 also attacks at the endpoints, turning organisations or people into
444 (willing, unwilling, or unwitting) collaborators. One technical
445 means of protection is thus to design protocols such that there are
446 fewer potential collaborators, e.g., a provider of cloud storage
447 cannot hand over plaintext for content that is encrypted with a key
448 he doesn't have, and cannot hand over names if his client is
449 anonymous.
451 It is important to distinguish between PM and fighting crime. PM is
452 an attack, but a judge ordering the surveillance of a suspected
453 criminal is not. The latter, often abbreviated in this context as LI
454 (for Lawful Intercept), is outside the scope of this workshop.
456 5.5. Improving the tools
458 An earlier session discussed why existing COMSEC tools weren't used
459 more. This second session on COMSEC therefore discussed what
460 improvements and/or new tools were needed.
462 Discussion at the workshop indicated that an important meta-tool for
463 improving existing security technology could be Opportunistic
464 Security (OS). [I-D.kent-opportunistic-security]. The idea is that
465 software is enhanced with a module that tries to encrypt
466 communications when it detects that the other end also has the same
467 capablility but otherwise leaves the communication continue in the
468 old way. The detailed definition of OS is now being discussed by the
469 IETF security area. [saag]
471 OS would protect against a passive eavesdropper but should also allow
472 for endpoint authentication to protect against an active attacker (a
473 MITM). As OS spreads, more and more communications would be
474 encrypted (and hopefully authenticated) and thus there is less and
475 less for an eavesdropper to collect.
477 Of course, an implementation of OS could give a false sense of
478 security as well: some connections are encrypted, some are not. A
479 user might see something like a padlock icon in browsers, but there
480 was agreement at the workshop that such user interface features ought
481 not be changed because OS is being used.
483 There is also the possibility that a MITM intercepts the reply from a
484 server that says "yes, I can do encryption" and removes it, causing
485 the client to fall back to an unencrypted protocol. Mitigations
486 against this can be to have other channels of finding out a server's
487 capabilities and remembering that a server could do encryption
488 previously.
490 There is also, again, a terminology problem. The technical
491 descriptions of OS talk about "silent fail" when a connection
492 couldn't be encrypted and has to fall back to the old, unencrypted
493 protocol. Actually, it's not a fail, it's no worse then it was
494 before. A successful encryption would rather be a "silent
495 improvement."
497 That raises the question of the UI: How do you explain to a user what
498 their security options are, and, in case an error occurs, how do you
499 explain the implications of the various responses?
501 The people working on encryption are mathematicians and engineers,
502 and typically not the same people who know about UI. We need to
503 involve the experts. We also need to distinguish between usability
504 of the UI, user understanding, and user experience. For an
505 e-commerce site, e.g., it is not just important that the user's data
506 is technically safe, but also that he feels secure. Otherwise he
507 still won't buy anything.
509 When talking about users, we also need to distinguish the end user
510 (who we typically think about when we talk about UI) from the server
511 administrators and other technical people involved in enabling a
512 connection. When something goes wrong (e.g., the user's software
513 detects an invalid certificate), the message usually goes to the end
514 user. But he isn't necessarily the person who can do something about
515 it. E.g., if the problem is a certificate that expired yesterday,
516 the options for the user are to break the connection (the safe
517 choice, but it means he can't get his work done) or continue anyway
518 (there could be a MITM...). The server administrator, on the other
519 hand, could actually solve the problem.
521 Encryption and authentication have a cost, in terms of setting them
522 up, but also in terms of the time it takes for software to do the
523 calculations. The set-up cost can be reduced with sensible defaults,
524 predefined profiles and cut-and-paste configurations. And for some
525 connections, authentication without encryption could be enough, in
526 the case that the data doesn't need to be kept secret, but it is
527 important to know that it is the real data. Most mail UAs already
528 provide independent options for encryption and signing, but Web
529 servers only support authentication if the connection is also
530 encrypted.
532 On the other hand, as e-mail also shows, it is difficult for users to
533 understand what encryption and authentication do separately.
535 And it also has to be kept in mind that encrypting only the
536 "sensitive" data and not the rest decreases the cost for an attacker,
537 too: It becomes easy to know which connections are worth attacking.
538 Selective field confidentiality is also more prone to lead to
539 developer error, as not all developers will know the provenance of
540 values to be processed.
542 One problem with the TOFU model as used by SSH (see explanation
543 above) is that it lacks a solution for key continuity: When a key is
544 changed (which can happen e.g., when a server is replaced or the
545 software upgraded), there is no way to inform the client. (In
546 practice, people use other means, such as calling people on the phone
547 or asking their colleagues in the office, but that doesn't scale and
548 doesn't always happen either.) An improvement in the SSH protocol
549 could thus be a way to transfer a new key to a client in a safe way.
551 5.6. Hiding metadata
553 Encryption and authentication help protect the content of messages.
554 Correctly implemented encryption is very hard to crack. (To get the
555 content, an attacker would rather attempt to steal the keys, corrupt
556 the encoding software, or get the content via a collaborator.) But
557 encrypting the content doesn't hide the fact that you are
558 communicating. This metadata (who talks to whom, when and for how
559 long) is often as interesting as the content itself, and in some
560 cases the size and timing of messages is even an accurate predictor
561 of the content. So how to stop an attacker from collecting metadata,
562 given that much of that data is actually needed by routers and other
563 services to deliver the message to the right place?
565 It is useful to distinguish different kinds of metadata: explicit (or
566 metadata proper) and implicit (sometimes called traffic data).
567 Implicit metadata is things that can be derived from a message or are
568 necessary for its delivery, such as the destination address, the
569 size, the time, or the frequency with which messages pass. Explicit
570 metadata is things like quality ratings, provenance or copyright
571 data: data about the data, useful for an application, but not
572 required to deliver the data to its endpoint.
574 A system like Tor hides much of the metadata by passing through
575 several servers, encrypting all the data except that which a
576 particular server needs to see. Each server thus knows which server
577 a message came from and where he has to send it to, but cannot know
578 where the previous server got it from or where the next server is
579 instructed to send it. However, deliberately passing through
580 multiple servers makes the communication slower than taking the most
581 direct route and increases the amount of traffic the network as a
582 whole has to process.
584 There are three kinds of measures that can be taken to make metadata
585 harder to get: aggregation, contraflow and multipath (see paper
586 4 [9]). New protocols should be designed such that these measures
587 are not inadvertently disallowed, e.g., because the design assumes
588 that the whole of a conversation passes through the same route.
590 _Aggregation_ means collecting conversations from multiple sources
591 into one stream. E.g., if HTTP connections pass through a proxy, all
592 the conversations appear to come from the proxy instead of from their
593 original sources. (This assumes that telltale information in the
594 headers is stripped by the proxy, or that the connection is
595 encrypted.) It also works in the other direction: if multiple Web
596 sites are hosted on the same server, an attacker cannot see which of
597 those Web sites a user is reading. (This assumes that the name of
598 the site is in the path info of the URL and not in the domain name,
599 otherwise watching DNS queries can still reveal the name.)
601 _Contraflow_ means routing a conversation via one or more other
602 servers than the normal route, e.g., by using a tunnel (e.g., with
603 SSH or a VPN) to another server. Tor is an example of this. An
604 attacker must watch more routes and do more effort to correlate
605 conversations. (Again, this assumes that there is no telltale
606 information left in the messages that leave the tunnel.)
608 _Multipath_ splits up a single conversation (or a set of related
609 conversations) and routes the parts in different ways. E.g., send a
610 request via a satellite link and receive the response via a land
611 line; or starting a conversation on a cellular link and continuing it
612 via wifi. This again increases the cost for an attacker, who has to
613 monitor and correlate multiple networks.
615 Protecting metadata automatically with technology at a lower layer
616 than the application layer is difficult. The applications themselves
617 need to pass less data, e.g., use anonymous temporary handles instead
618 of permanent identifiers. There is often no real need for people to
619 use the same identifier on different computers (smartphone, desktop,
620 etc.) other than that the application they use was designed that way.
622 One thing that can be done relatively easily in the short term is
623 going through existing protocols to check what data they send that
624 isn't really necessary. One candidate mentioned for such a study was
625 XMPP.
627 _Fingerprinting_ is the process of distinguishing different senders
628 of messages based on metadata: Clients can be recognised (or at least
629 grouped) because their messages always have a combination of features
630 that other clients do not have. Reducing redundant metadata and
631 reducing the number of optional features in a protocol reduces the
632 variation between clients and thus makes fingerprinting harder.
634 Traffic analysis is a research discipline that produces sometimes
635 surprising findings, which are little known among protocol
636 developers. Some collections of results are
638 o A selected bibliography on anonymity [10] by the Free Haven
639 Project
641 o The yearly Symposium on Privacy Enhancing Technologies
642 (PETS). [11]
644 o The yearly Workshop on Privacy in the Electronic Society
645 (WPES). [12]
647 Techniques that deliberately change the timing or size of messages,
648 such as padding, can also help reduce fingerprinting. Obviously,
649 they make conversations slower and/or use more bandwidth, but in some
650 cases that is not an issue, e.g., if the conversation is limited by
651 the speed of a human user anyway. HTTP/2 has a built-in padding
652 mechanism. However, it is not so easy to use these techniques well,
653 and not actually make messages easier to recognise rather than
654 harder.
656 Different users in different contexts may have different security
657 needs, so maybe the priority can be a user choice. (If that can be
658 done without making high-security users stand out from other users.)
659 Although many people would not understand what their choices are,
660 some do, such as political activists or journalists.
662 5.7. Deployment, intermediaries and middleboxes
664 Secure protocols have often been designed in the past for end-to-end
665 security: Intermediaries cannot read or modify the messages. This is
666 the model behind TLS for example.
668 But in practice people have more or less valid reasons to insist on
669 intermediaries: companies filtering incoming and outgoing traffic for
670 viruses or other reasons, giving priority to certain communications
671 or caching to reduce bandwidth.
673 In the presence of end-to-end encryption and authentication, these
674 intermediaries have two choices: using fake certificates to
675 impersonate the endpoints or having access to the private keys of the
676 endpoints. The former is a MITM attack that is difficult to
677 distinguish from a more malicious one, the latter obviously decreases
678 the security of the endpoints by copying supposedly protected data
679 and concentrating such data in a single place.
681 As mentioned in Section 5.2 above, aggregation of data in a single
682 place makes that place an attractive target. And in the case of PM
683 even if the data is not concentrated physically in one place, but is
684 under control of a single legal entity that can be made into a
685 collaborator.
687 The way Web communication with TLS typically works is that the client
688 authenticates the server, but the server does not authenticate the
689 client at the TLS layer. (If the client needs to be identified, that
690 is mainly done at the application layer via passwords or cookies.)
691 Thus the presence of a MITM (middlebox) could be detected by the
692 client (because of the incorrect certificate), but not by the server.
693 If the client doesn't immediately close the connection, (which they
694 do not in many cases), the server may thus disclose information that
695 the user would rather not have disclosed.
697 One widespread example of middleboxes is captive portals, as found on
698 the wifi hotspots in hotels, airports, etc. Even the hotspots
699 offering free access often intercept communications to redirect the
700 user to a login or policy page.
702 When the communication they intercept is, e.g., the automatic update
703 of your calendar program or a chat session, the redirect obviously
704 doesn't work: these applications don't know how to display a Web
705 page. With the increasing use of apps, it may be a while before the
706 user actually opens a browser. The flood of error messages may also
707 have as a result that the user no longer reads the errors, allowing
708 an actual malicious attack to go unnoticed.
710 Some operating systems now come with heuristics that try to recognise
711 captive portals and either automatically login or show their login
712 page in a separate application. (But some hotspot providers
713 apparently don't want automatic logins and actually reverse-
714 engineered the heuristics to try and fool them.)
716 It seems some protocol is missing in this case. Captive portals
717 shouldn't have to do MITM attacks to be noticed. Maybe something
718 like an extension to DHCP that tells a connecting device about the
719 login page can help, although that still doesn't solve the problem
720 for devices that do not have a Web browser, such as game consoles or
721 SIP phones. HTTP response code 511 (defined in [RFC6585]) is another
722 attempt at a solution. (Partial, because it can only work at the
723 moment the user uses a browser to connect to a Web site and doesn't
724 use HTTPS.)
726 A practical problem with deployment of such a protocol may be that
727 many such captive portals are very old and never updated. The hotel
728 staff only knows how to reboot the system and as long as it works,
729 the hotel has no incentive to buy a new one. As evidence of this:
730 how many such systems require you to get a password and the ticket
731 shows the price as zero? This is typically because the owner doesn't
732 know how to reconfigure the hotspot, but he does know how to change
733 the price in his cash register...
735 5.8. Break-out 1 - research
737 Despite some requests earlier in the workshop, the research break-out
738 did not discuss clean-slate approaches. The challenge was rather
739 that the relation between security research and standardisation needs
740 improvement. Research on linkability is not yet well known in the
741 IETF. But the other side of the coin needs improvement too: While
742 doing protocol design, standardisation should indicate what specific
743 problems are in need of more research.
745 The break-out then made a non exclusive list of topics that are in
746 need of further research:
748 o The interaction of compression and encryption as demonstrated by
749 the CRIME SSL/TLS vulnerability [13]
751 o A more proactive deprecation of algorithms based on research
752 results.
754 o Mitigation for return oriented programming attacks
756 o How to better obfuscate so called "metadata", how to make the
757 existence of traffic and their endpoints stealthy
759 5.9. Break-out 2 - clients
761 Browsers are the first clients one thinks of when talking about
762 encrypted connections, authentication and certificates, but there are
763 many others.
765 Another common case of "false" alarms for MITM (after captive
766 portals) is expired and mis-configured certificates. This is quite
767 common in intranets, when the sysadmin hasn't bothered updating a
768 certificate and rather tells his handful of users to just "click
769 continue." The problem is on the one hand that users may not
770 understand the difference between this case and the same error
771 message when they connect to a server outside the company, and on the
772 other hand that the incorrect certificate installed by the sysadmin
773 is not easily distinguishable from an incorrect certificate from a
774 MITM. The error message is almost the same and the user may just
775 click continue again.
777 One way to get rid of such certificates is if client software no
778 longer offers the option to continue after a certificate error. That
779 requires that all major clients (such as browsers) change their
780 behaviour at the same time, otherwise the first one to do so will be
781 considered broken by users, because the others still work. Also it
782 requires a period in which that software gives increasingly strong
783 warnings about the cut-off date after which the connection will fail
784 with this certificate.
786 Yet another source of error messages is self-signed certificates.
787 Such certificates are actually only errors for sites that are not
788 expected to have them. If a message about a self-signed certificate
789 appears when connecting to Facebook or Google, you're clearly not
790 connected to the real Facebook or Google. But for a personal Website
791 it shouldn't cause such scary warnings. There may be ways to improve
792 the explanations in the error message and provide an easy way to
793 verify the certificate (by e-mail, over the phone or some other
794 channel) and import it.
796 5.10. Break-out 3 - on by default
798 One step in improving security is to require the relevant features,
799 in particular encryption and authentication, to be implemented in
800 compliant products: The features are labelled as MUST in the standard
801 rather than MAY. This is sometimes referred to as MTI, Mandatory To
802 Implement and is the current practice for IETF protocols. [RFC3365]
804 But that may not be enough to counter PM. It may be that the
805 features are there, but not used, because only very knowledgeable
806 users or sysadmins turn them on. Or it may be that implementations
807 do not actually follow the MTI parts of specifications. Or it may be
808 that some security features are implemented but interoperability for
809 those doesn't really work. Or, even worse, it may be that protocol
810 designers have only followed the letter of the MTI best practice and
811 not its spirit, with the result that security features are hard to
812 use or make deployment harder. One can thus argue that such features
813 should be defined to be on by default.
815 Going further one might argue that these features should not even be
816 options, i.e., there should be no way to turn them off. This is
817 sometimes called MTU, Mandatory To Use.
819 The question raised at this session was for what protocols on-by-
820 default is appropriate, and how to explain to the developers of such
821 protocols that it is needed?
823 There would of course be resistance to MTU security from implemeters
824 and deployments that practice deep packet inspection (DPI) and also
825 perhaps from some governments. On the other hand, there may also be
826 governments that outlaw protocols _without_ proper encryption.
828 This break-out concluded that there could be value in attempting to
829 document a new Best Current Practice for the IETF that moves from the
830 current MTI position to one where security features are on-by-
831 default. Some of the workshop participants expressed interest in
832 authoring a draft for such a new BCP and progressing that through the
833 IETF consensus process. (Where it would no doubt be controversial.)
835 5.11. Break-out 4 - measurement
837 There was a small break-out on the idea of measurement as a way to
838 encourage or gamify the increased use of security mechanisms. [[We
839 don't currently have notes from that.]]
841 5.12. Break-out 5 - opportunistic
843 This break out considered the use of the term "opportunistic" as it
844 applies to crytpgraphic security and attempted to progress the work
845 towards arriving at an agreed definition for use of that term, at it
846 applies to IETF and W3C work.
848 While various terms had been used, with many people talking about
849 opportunistic encryption, that usage was felt to be problematic both
850 because it conflicted with the use of the same term in [RFC4322] and
851 because it was being used differently in different parts of the
852 community.
854 At the session it was felt that the term "opportunistic keying" was
855 better, but as explained above subsequent list discussion resulted in
856 a move to the term "Opportunistic Security" (OS).
858 Aside from terminology, disussion focused on the use of Diffie-
859 Hellman (D-H) key exchange as the preferred mechanism of OS, with
860 fall back to cleartext if D-H doesn't succeed as a counter for
861 passive attacks.
863 There was also of course the desire to be able to easily escalate
864 from countering passive attacks to also handling endpoint
865 authentication and thereby also countering MITM attacks.
867 Making OS visible to users was again considered to be undesirable, as
868 users could not be expected to distinguish between cleartext, OS and
869 (one-sided or mutal) endpoint authentication.
871 Finally, it was noted that it may take some effort to establish how
872 middleboxes might affect OS at different layers and that OS really is
873 not suitable as the only migitation to use for high-sensitivity
874 sessions such as financial transactions.
876 5.13. Unofficial Transport/Routing Break-out
878 Some routing and transport area directors felt a little left out by
879 all the application layer break-outs:-) So they had their own
880 brainstorm about what could be done at the Transport and Routing
881 layers from which these notes resulted.
883 The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer
884 service that is reordering and delay insensitive. Use of LDEBAT
885 could offer the following benefits for an application:
887 a. Because it is reordering insensitive, traffic can be sprayed
888 across a large number of forwarding paths. Assuming such
889 different paths exist, this would make it more challenging to
890 capture and analyze a full interaction.
892 b. The application can vary the paths by indicating per packet a
893 different microflow. In IPv6, this can be done via different
894 IPv6 flow labels. For IPv4, this can be done by encapsulating
895 the IP packet into UDP and varying the UDP src port.
897 c. Since LEDBAT is delay insensitive and applications using it would
898 need to be as well, it would be possible to obfuscate the
899 application signatures by varying the packet lengths and
900 frequency.
902 d. This can also hide the transport header (for IP in UDP).
904 e. If we could fix the reverse SPF check problem, perhaps the source
905 could be hidden - but that has assumptions on trusted perimeters.
907 f. The use of LEDBAT is orthogonal to the use of encryption and
908 provides different benefits (harder to intercept the whole
909 conversation, ability to obfuscate the traffic analysis), and
910 also has different costs (longer latency, new transport protocol
911 usage) to its users.
913 We also discussed the idea of encrypting traffic from CE to CE as
914 part of a L3VPN or such. This could allow hiding of addresses,
915 including source, and headers. From my further conversation with Ron
916 Bonica, some customers already do encryption (though not hiding the
917 source address) like this. So, I'm not sure this is very practically
918 useful as an enhancement except for encouraging deployment and use.
920 Finally, we discussed whether it would be useful to have a means of
921 communicating where and what layers are doing encryption on an
922 application's traffic path. The initial idea of augmenting ICMP has
923 some issues (not visible to application, ICMP packets frequently
924 filtered) as well as potential work (determining how to trust the
925 report of encryption). It would be interesting to understand if such
926 communication is actually needed and what the requirements would be.
928 6. After the workshop
930 Holding the workshop just before the IETF had the intended effect: a
931 number of people went to both the workshop and the IETF. And they
932 took the opportunity of being together at the IETF to continue the
933 discussions.
935 Working groups of the IETF who met in London took the recommendations
936 from the workshop into account. It was even the first item in the
937 report about the IETF meeting by the IETF chair, Jari Arkko:
939 _"Strengthening the security and privacy of the Internet continued
940 to draw a lot of attention. The STRINT workshop organised by the
941 IAB and W3C just before the IETF attracted 100 participants and
942 over 60 papers. Even more people would have joined us, but there
943 was no space. During the IETF meeting, we continued discussing
944 the topic at various working groups. A while ago we created the
945 first working group specifically aimed at addressing some of the
946 issues surrounding pervasive monitoring. The Using TLS for
947 Applications (UTA) working group had its first meeting in London.
948 But many other working groups also address these issues in their
949 own work. The TCPM working group discussed a proposal to add
950 opportunistic keying mechanisms directly onto the TCP protocol.
951 And the DNSE BOF considered the possibility of adding
952 confidentiality support to DNS queries. Finally, there is an
953 ongoing effort to review old specifications to search for areas
954 that might benefit from taking privacy and data minimisation
955 better into account."_ - [Arkko1]
957 Two papers that were written for the workshop, but not finished in
958 time, are worth mentioning, too: One by the same Jari Arkko, titled
959 "Privacy and Networking Functions" [Arkko2]; and one by Johan
960 Pouwelse, "The Shadow Internet: liberation from Surveillance,
961 Censorship and Servers" [draft-pouwelse-perpass-shadow-internet]
963 7. IANA considerations
965 There are none. We hope the RFC editor deletes this section.
967 8. Security considerations
969 This document does not define a technology but is all about security
970 and privacy.
972 Plenary.
973 (C) Stonehouse Photographic [14]
975 9. Informative references
977 [Arkko1] Arkko, J., "IETF-89 Summary", March 2014,
978 .
980 [Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014,
981 .
984 (Work in progress.)
986 [I-D.barnes-pervasive-problem]
987 Barnes, R., Schneier, B., Jennings, C., and T. Hardie,
988 "Pervasive Attack: A Threat Model and Problem Statement",
989 draft-barnes-pervasive-problem-00 (work in progress),
990 January 2014.
992 [I-D.farrell-perpass-attack]
993 Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an
994 Attack", draft-farrell-perpass-attack-06 (work in
995 progress), February 2014.
997 [I-D.kent-opportunistic-security]
998 Kent, S., "Opportunistic Security as a Countermeasure to
999 Pervasive Monitoring",
1000 draft-kent-opportunistic-security-01 (work in progress),
1001 April 2014.
1003 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1004 A., Peterson, J., Sparks, R., Handley, M., and E.
1005 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1006 June 2002.
1008 [RFC3365] Schiller, J., "Strong Security Requirements for Internet
1009 Engineering Task Force Standard Protocols", BCP 61,
1010 RFC 3365, August 2002.
1012 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1013 Text on Security Considerations", BCP 72, RFC 3552,
1014 July 2003.
1016 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
1017 Authentication Protocol", RFC 4252, January 2006.
1019 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic
1020 Encryption using the Internet Key Exchange (IKE)",
1021 RFC 4322, December 2005.
1023 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
1024 Codes", RFC 6585, April 2012.
1026 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
1027 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
1028 December 2012.
1030 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1031 Transparency", RFC 6962, June 2013.
1033 [draft-ietf-websec-key-pinning]
1034 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
1035 Extension for HTTP", February 2014.
1037 (Work in progress.)
1039 [draft-pouwelse-perpass-shadow-internet]
1040 Pouwelse, J., Ed., "The Shadow Internet: liberation from
1041 Surveillance, Censorship and Servers", February 2014, .
1045 (Work in progress.)
1047 [saag] Area, S., "IETF Security Area mailing list", March 2014, <
1048 https://www.ietf.org/mail-archive/web/saag/current/
1049 maillist.html>.
1051 [vancouverplenary]
1052 IETF, "IETF 88 Technical Plenary Minutes", .
1056 [w3c-geo-api]
1057 Popescu, A., "Geolocation API Specification",
1058 October 2013, .
1060 [1]
1062 [2]
1064 [3]
1066 [4]
1068 [5]
1070 [6]
1072 [7]
1074 [8]
1076 [9]
1078 [10]
1080 [11]
1083 [12]
1086 [13]
1089 [14]
1091 [15]
1093 [16]
1095 [17]
1097 [18]
1099 [19]
1101 [20]
1103 [21]
1105 [22]
1107 [23]
1109 [24]
1111 [25]
1113 [26]
1116 [27]
1119 [28]
1122 [29]
1124 [30]
1126 [31]
1128 [32]
1130 [33]
1132 [34]
1134 [35]
1136 [36]
1138 [37]
1141 [38]
1145 [39]
1147 [40]
1149 [41]
1151 [42]
1153 [43]
1155 [44]
1157 [45]
1159 [46]
1161 [47]
1163 [48]
1165 [49]
1167 [50]
1169 [51]
1171 [52]
1173 [53]
1175 [54]
1177 [55]
1179 [56]
1181 [57]
1183 [58]
1185 [59]
1187 [60]
1189 [61]
1191 [62]
1193 [63]
1195 [64]
1197 [65]
1199 [66]
1201 [67]
1203 [68]
1205 [69]
1207 [70]
1209 [71]
1211 [72]
1213 [73]
1215 [74]
1217 [75]
1219 [76]
1221 [77]
1223 [78]
1225 [79]
1227 [80]
1229 [81]
1231 [82]
1233 [83]
1235 [84]
1237 [85]
1239 [86]
1241 [87]
1243 [88]
1245 [89]
1247 [90]
1249 [91]
1251 [92]
1253 [93]
1255 [94]
1257 [95]
1259 [96]
1261 [97]
1263 Appendix A. Logistics
1265 The workshop was organised by the STREWS [5] project (a research
1266 project funded under the European Union's 7th Framework
1267 Programme [15]), as the first of two workshops in its work plan. The
1268 organisers were supported by the IAB and W3C, and, for the local
1269 organisation, by Telefonica Digital. [16]
1271 One of the suggestions in the project description of the STREWS
1272 project was to attach the first workshop to an IETF meeting. The
1273 best opportunity was IETF 89 [4] in London, which would begin on
1274 Sunday March 2, 2014. Telefonica Digital offered meeting rooms at
1275 its offices in central London for the preceding Friday and Saturday,
1276 just minutes away from the IETF's location.
1278 The room held 100 people, which was thought to be sufficient. There
1279 turned out to be more interest than expected and we could have filled
1280 a larger room, but 100 people is probably an upper limit for good
1281 discussions anyway.
1283 Apart from the usual equipment in the room (projector, white boards,
1284 microphones, coffee...), we also set up some extra communication
1285 channels:
1287 o A mailing list where participants could discuss the agenda and the
1288 published papers about three weeks in advance of the workshop
1289 itself. (Only participants were allowed to write to the mailing
1290 list, but the archive [17] is public.)
1292 o Publicly advertised streaming audio (one-way only). At some
1293 point, no less than 165 people were listening.
1295 o An IRC channel for live minute taking, passing links and other
1296 information, and as a help for remote participants to follow the
1297 proceedings.
1299 o An Etherpad, where the authors of papers could provide an abstract
1300 of their submissions, to help participants who could not read all
1301 66 papers in full in advance of the workshop. (The abstracts were
1302 also used on the workshop's Web site and are reproduced in this
1303 report (Appendix C).)
1305 o A "Twitter hashtag" (#strint). Four weeks after the workshop,
1306 there were still a few new messages [18] about events related to
1307 workshop topics.
1309 Appendix B. Agenda
1311 This was the final agenda of the workshop, as determined by the TPC
1312 and participants on the mailing list prior to the workshop. The
1313 included links are to the slides that the moderators used to
1314 introduce each discussion topic and to the minutes.
1316 B.1. Friday 28 February
1318 (minutes [19])
1320 13:00 Registration, Coffee, play with n/w, power, find seat
1322 14:00 Workshop starts, welcome, logistics, opening/overview
1323 [slides] [20]
1325 * Goal is to plan how we respond to PM threats
1327 * Specific questions to be discussed in sessions
1329 * Outcomes are actions for IETF, W3C, IRTF, etc.
1331 14:30 I. Threats - What problem are we trying to solve? (Presenter:
1332 Richard Barnes; Moderator: Cullen Jennings) [slides] [21]
1334 * What attacks have been described? (Attack taxonomy)
1336 * What should we assume the attackers' capabilities are?
1338 * When is it really "pervasive monitoring" and when is it not?
1340 * Scoping - what's in and what's out? (for IETF/W3C)
1342 15:30 Break
1344 16:00 II. COMSEC 1 - How can we increase usage of current COMSEC
1345 tools? (Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
1346 [slides] [22]
1348 * Whirlwind catalog of current tools
1350 * Why aren't people using them? In what situations are / aren't
1351 they used?
1353 * Securing AAA and management protocols - why not?
1355 * How can we (IETF/W3C/community) encourage more/better use?
1357 17:30 Break
1359 17:45 III. Policy - What policy / legal/ other issues need to be
1360 taken into account? (Presenter: Christine Runnegar; Moderator:
1361 Rigo Wenning) [slides] [23]
1362 * What non-technical activities do we need to be aware of?
1364 * How might such non-technical activities impact on IETF/W3C?
1366 * How might IETF/W3C activities impact on those non-technical
1367 activities?
1369 18:30 Session IV - Saturday plan, open-mic, wrap up day
1371 19:00 Social event
1373 Break out.
1374 (C) Stonehouse Photographic [14]
1376 B.2. Saturday 1 March
1378 (minutes [24])
1380 09:00 Welcome again, logistics
1382 09:15 IV. COMSEC 2 - What improvements to COMSEC tools are
1383 needed?(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
1384 [slides] [25]
1386 * Opportunistic encryption - what is it and where it might apply
1388 * Mitigations aiming to block PM vs. detect PM - when to try
1389 which?
1391 10:30 Break
1393 10:45 V. Metadata - How can we reduce the metadata that protocols
1394 expose? (Presenter: Alfredo Pironti [slides] [26] / Ted Hardie
1395 [slides] [27]; Moderator: Alissa Cooper [slides] [28])
1397 * Meta-data, fingerprinting, minimisation
1399 * What's out there?
1401 * How can we do better?
1403 12:00 Lunch (Buffet)
1405 13:00 VI. Deployment - How can we address PM in deployment /
1406 operations? (Presenter: Eliot Lear; Moderator: Barry Leiba)
1407 [slides] [29]
1408 * "Mega"-commercial services (clouds, large scale email & SN,
1409 SIP, WebRTC...)
1411 * Target dispersal - good goal or wishful thinking?
1413 * Middleboxes: when a help and when a hindrance?
1415 14:30 Break
1417 15:00 VII. 3 x Break-out Sessions / Bar-Camp style (Hannes
1418 Tschofenig)
1420 * Content to be defined during meeting, as topics come up
1422 * Sum up at the end to gather conclusions for report
1424 15:00 Break-outs:
1426 1. Research Questions (Moderator: Kenny Paterson)
1428 + Do we need more/different crypto tools?
1430 + How can applications make better use of COMSEC tools?
1432 + What research topics could be handled in IRTF?
1434 + What other research would help?
1436 2. clients
1438 3. on by default
1440 4. measuring
1442 5. opportunistic
1444 16:15 VIII. Break-out reports, Open mic & Conclusions - What are we
1445 going to do to address PM? [slides] [30]
1447 * Gather conclusions / recommendations / goals from earlier
1448 sessions
1450 17:15 End
1451 Whiteboard notes.
1452 (C) Stonehouse Photographic [14]
1454 Appendix C. The submitted papers
1456 [[sort-papers: Group the papers by (rough) topic? --Bert]]
1458 The following papers were submitted to the workshop. The abstracts
1459 were provided by the authors themselves. (We set up an editable page
1460 ("Etherpad") [31] where the authors could insert them.)
1462 C.1. Privacy Protected Email - Phillip Hallam-Baker
1464 01.pdf [32] - This proposal is two things: First it shows that with
1465 some small adjustments to S/MIME and PGP we can merge two competing
1466 end-to-end security proposals that are too hard for people to use
1467 into one scheme that provides a useful degree of security with no
1468 thought from the user. In cases where the user has security concerns
1469 they can easily determine that they are met. The second part of the
1470 proposal is that it the Trust set deployed to secure email encryption
1471 can be leveraged to solve pretty much every other end-to-end security
1472 requirement. If people generate keys for their email we can secure
1473 chat, video, 2-factor authentication as well.
1475 C.2. Opportunistic Encryption for MPLS - Stephen Farrell, Adrian
1476 Farrrell
1478 02.pdf [33] - This is an early proposal for a way to do open-channel
1479 D-H key agreement and encryption in MPLS. Two things are maybe
1480 interesting: a) its an example of trying to add confidentiality to an
1481 existing protocol with making PM harder as a specific goal and b)
1482 maybe it shows that there could be a benefit in a generic protocol
1483 for after-the-fact MITM detection for such cases. It'd probably be
1484 most interesting to discuss (a) as one example of something we want
1485 to do more generally and not the specifics of MPLS at the workshop;
1486 and I'd be interested in whether or not (b) is tractable (I'm not
1487 sure).
1489 C.3. Overcoming the Friend-or-Foe Paradigm in Secure Communication -
1490 Sebastian Gajek, Jan Seedorf, Marc Fischlin, Oezguer Dagdalen
1492 03.pdf [34] - Essentially, our point is that with the existing end-
1493 to-end client-server security paradigm, e.g. as instantiated in TLS,
1494 the "good guys" often actually have to mount attacks in order for
1495 middleboxes (which are on the path between client ans server being
1496 able) to perform their job. The good guys are thus technically
1497 indistinguishable from the bad guys.
1499 Concretely, we are proposing to extend TLS in a way that would allow
1500 authorized modification of certain, dedicated parts of the TLS
1501 payload by middleboxes, while still allowing for integrity
1502 verification by clients. The crypto for such "Interferable Secure
1503 Communication" exists and we think it is feasible to extend TLS in
1504 this way in a reasonable timeframe.
1506 C.4. Flows and Pervasive Monitoring - Ted Hardie
1508 04.pdf [9] - This document describes methods that may hinder a
1509 pervasive monitor's efforts to derive metadata from flows. There are
1510 three main methods discussed in the paper: aggregation, contraflow,
1511 and multipath. These are largely side-effects of other efforts at
1512 this time, but the paper discusses how they might fit into the design
1513 space of efforts intended to combat pervasive monitoring and the
1514 related consequences for network operations.
1516 C.5. BetterCrypto.org Applied Crypto Hardening - Aaron Zauner, L. Aaron
1517 Kaplan
1519 05.pdf [35] - BetterCrypto is a community-driven project where
1520 admins, engineers, cryptographers, security researchers alike
1521 participate in finding well researched best-practices for commonly
1522 deployed networked applications and infrastructure. We try to
1523 outline a proper interim solution until better protocols and
1524 standards are widely deployed. Our hope is that we can contribute to
1525 a safer internet for all and better understanding of cryptographic
1526 primitives for the operations community that needs to deploy sound
1527 security on the public internet. Our focus group: sysadmins / ops.
1529 C.6. A Complimentary Analysis (The Danger Of The New Internet Choke
1530 Points) - Andrei Robachevsky, Christine Runnegar, Karen
1531 O'Donoghue, Mat Ford
1533 06.pdf [36] - The ongoing disclosures of pervasive surveillance of
1534 Internet users' communications and data by national signals
1535 intelligence agencies have prompted protocol designers, software and
1536 hardware vendors, as well as Internet service and content providers,
1537 to re-evaluate prevailing security and privacy threat models and to
1538 refocus on providing more effective security and confidentiality. At
1539 IETF88, there was consensus to address pervasive monitoring as an
1540 attack and to consider the pervasive attack threat model when
1541 designing a protocol. In this paper, we offer a complimentary
1542 analysis. We identify some of the components of the Internet
1543 architecture that provide attractive opportunities for wholesale
1544 monitoring and/or interception, and, therefore, represent
1545 architectural vulnerabilities, or choke points. We also suggest
1546 possible mitigation strategies and pose some of the questions that
1547 need to be considered if the Internet is to evolve to reduce such
1548 vulnerabilities. Finally, we identify some significant areas of
1549 tension or trade-offs, and we consider possible areas for additional
1550 efforts. Also: danger-new-internet-choke-points [37] and
1551 mind_the_step_function [38]
1553 C.7. Trust Issues with Opportunistic Encryption - Scott Rose, Stephen
1554 Nightingale, Doug Montgomery
1556 07.pdf [39] - "Once is happenstance. Twice is coincidence. Three
1557 times is enemy action"
1559 The lack of authentication in opportunistic encryption could have the
1560 perverse affect of putting more end users at risk: thinking that they
1561 are "secure", an end user may divulge private information to an
1562 imposter instead of the service they believe they have contacted.
1563 When adding protection mechanisms to protocols, designers and
1564 implementers should not downplay the importance of authentication in
1565 order to make opportunistic encryption easier to deploy. We advocate
1566 that while opportunistic encryption can solve one set of problems,
1567 authentication is often desired by end users.
1569 C.8. Challenges with End-to-End Email Encryption - Jiangshan Yu,
1570 Vincent Cheval, Mark Ryan
1572 08.pdf [40] - In this paper we show how the use of an extended
1573 certificate transparency can build a secure end-to-end email or
1574 messaging system using PKI without requiring trusted parties nor
1575 complex p2p key-signing arrangements such as PGP. This makes end-to-
1576 end encrypted mail possible, and users do not need to understand or
1577 concern themselves with keys or certificates. In addition, we
1578 briefly present some related concerns i.e. metadata protection, key
1579 loss mitigation, spam detection, and the security of webmail.
1581 C.9. Strengthening the path and strengthening the end-points - Xavier
1582 Marjou, Emile Stephan, Jean-Michel Combes, Iuniana Oprescu
1584 09.pdf [41] - Internet data is more and more subject to pervasive
1585 monitoring. This paper investigates ways of enhancing this situation
1586 depending on where such pervasive monitoring may occur. There are
1587 two different locations to secure: the endpoints and the path between
1588 these endpoints. In the present document, we also emphasize the fact
1589 that encryption, although bringing additional data confidentiality,
1590 might in some cases contradict security's two other pillars, which
1591 are availability and integrity.
1593 C.10. SIP is Difficult - Jon Peterson
1595 10.pdf [42] - While SIP is widely used as a protocol for real-time
1596 communications, it is very difficult to secure from pervasive
1597 monitoring. In fact, one could argue that SIP's susceptibility to
1598 mass surveillance was essential to its success in the marketplace.
1599 This paper shows why SIP's design left the door open for
1600 eavesdropping, and what lessons RTCWeb could learn from this.
1602 C.11. Thoughts of Strengthening Network Devices in the Face of
1603 Pervasive Surveillance - Dacheng Zhang, Fuyou Miao
1605 11.pdf [43] - The material released by Edward Snowden has raised
1606 serious concerns about pervasive surveillance. People worry that
1607 their privacy is not properly protected when they are using the
1608 Internet. Network product vendors also encounter the doubts on the
1609 security of their products (e.g., routers, switches, firewalls).
1610 Such doubts are seriously damaging the Internet ecosystem. In this
1611 paper we try to analyze the affects brought by the Snowden scandal on
1612 our ability to trust products at the core of the Internet and discuss
1613 what the standard organization can do to help vendors address these
1614 security concerns.
1616 C.12. Opportunistic Encryption for HTTP URIs - Mark Nottingham
1618 12.pdf [44] - This is a proposed method for using TLS with http://
1619 URIs under discussion in the HTTPbis WG, in particular for HTTP/2 but
1620 also applicable to HTTP/1. One of the biggest decisions to make is
1621 whether or not to require the certs to validate in this scenario.
1623 C.13. Cyberdefense-Oriented Multilayer Threat Analysis - Yuji Sekiya,
1624 Daisuke Miyamoto, Hajime Tazaki
1626 13.pdf [45]
1628 C.14. A Threat Model for Pervasive Passive Surveillance - Brian
1629 Trammell, Daniel Borkmann, Christian Huitema
1631 14.pdf [46] - This document elaborates a threat model for pervasive
1632 surveillance, assuming an adversary with an interest in
1633 indiscriminate eavesdropping that can passively observe network
1634 traffic at every layer at every point in the network between the
1635 endpoints. We provide guidelines on evaluating the observability and
1636 inferability of information and metainformation radiated from
1637 Internet protocols. The central message to protocol designers:
1638 pervasive encryption for confidentiality, protocol and implementation
1639 design for simplicity and auditability, flexibility to allow
1640 fingerprinting resistance, and moving away from static identifiers
1641 can increase protocol-level resistance to pervasive surveillance.
1643 C.15. Why Provable Transparency is Useful Against Surveillance - Ben
1644 Laurie
1646 15.pdf [47]
1648 C.16. Withheld
1650 C.17. Monitoring message size to break privacy - Current issues and
1651 proposed solutions - Alfredo Pironti
1653 17.pdf [48] - One of the Internet traffic features that can be easily
1654 collected by passive pervasive monitoring is the size of the
1655 exchanged messages, or the total bandwidth used by a conversation.
1656 Several works have showed that careful analysis of this data can
1657 break users' expected privacy, even for encrypted traffic. Despite
1658 this, little has been done in practice to hide message sizes, perhaps
1659 because deemed too inefficient or not a realistic threat.
1661 In this short paper, we contextualize message size analysis in the
1662 wider pervasive monitoring scenario, which encompasses other powerful
1663 analysis techniques, and we re-state the severity of the privacy
1664 breach that message size analysis constitutes. We finally discuss
1665 proposals to fix this issue, considering practical aspects such as
1666 required developer awareness, ease of deployment, efficiency, and
1667 interaction with other countermeasures.
1669 C.18. Withheld
1671 C.19. Making The Internet Secure By Default - Michael H. Behringer, Max
1672 Pritkin, Steinthor Bjarnason
1674 19.pdf [49] - Pervasive monitoring on the Internet is enabled by the
1675 lack of general, fundamental security. In his presentation at the
1676 88th IETF Bruce Schneier called for ubiquitous use of security
1677 technologies to make pervasive monitoring too expensive and thus
1678 impractical. However, today security is too operationally expensive,
1679 and thus only used where strictly required. In this position paper
1680 we argue that all network transactions can be secure by default, with
1681 minimal or no operator involvement. This requires an autonomic
1682 approach where all devices in a domain enrol automatically in a trust
1683 domain. Once they share a common trust anchor they can secure
1684 communications between themselves, following a domain policy which is
1685 by default secure. The focus of this proposal is the network itself,
1686 with all protocols between network elements, including control plane
1687 protocols (e.g., routing protocols) and management plane protocols
1688 (e.g., SSH, netconf, etc). The proposal is evolutionary and allows a
1689 smooth migration from today's Internet technology, device by device.
1691 C.20. Increasing HTTP Transport Confidentiality with TLS Based
1692 Alternate Services - Patrick McManus
1694 20.pdf [50]
1696 C.21. Balance - Societal security versus individual liberty - Scott
1697 Cadzow
1699 21.pdf [51]
1701 C.22. Strengthening the Extensible Messaging and Presence Protocol
1702 (XMPP) - Peter Saint-Andre
1704 22.pdf [52] - This document describes existing and potential future
1705 efforts at strengthening the Extensible Messaging and Presence
1706 Protocol (XMPP), for discussion at the W3C/IAB workshop on
1707 Strengthening the Internet Against Pervasive Monitoring (STRINT).
1709 C.23. The Internet We Want or the Internet We Deserve? - David Rogers
1711 23.pdf [53]
1713 C.24. Beyond Encrypt Everything: Passive Monitoring - Mark Donnelly,
1714 Sam Hartman
1716 24.pdf [54]
1718 C.25. Examining Proxies to Mitigate Pervasive Surveillance - Eliot
1719 Lear, Barbara Fraser
1721 25.pdf [55] - The notion of pervasive surveillance assumes that it is
1722 possible for an attacker to have access to all links and devices
1723 between end points, as well as end points themselves. We examine
1724 this threat is some detail with an eye toward whether trusted
1725 intermediaries can provide relief from the attack. We go on to
1726 examine the costs associated with the various remediation methods.
1727 In at least one case, we challenge the notion that one should encrypt
1728 absolutely everything in all cases, as was implied in at least one
1729 threat analysis. Finally we summarize in a set of four principles
1730 that should be considered in future work.
1732 C.26. Spontaneous Wireless Networking to Counter Pervasive Monitoring -
1733 Emmanuel Baccelli, Oliver Hahm, Matthias Waehlisch
1735 26.pdf [56] - Several approaches can be employed to counter pervasive
1736 monitoring at large scale on the Internet. One category of
1737 approaches aims to harden the current Internet architecture and to
1738 increase the security of high profile targets (data centers, exchange
1739 points etc.). Another category of approaches aims instead for target
1740 dispersal, i.e. disabling systematic mass surveillance via the
1741 elimination of existing vantage points, thus forcing surveillance
1742 efforts to be more specific and personalized. This paper argues how
1743 networking approaches that do not rely on central entities - but
1744 rather on spontaneous interaction, as locally as possible, between
1745 autonomous peer entities - can help realize target dispersal and thus
1746 counter pervasive monitoring.
1748 C.27. Is Opportunistic Encryption the Answer? Practical Benefits and
1749 Disadvantages - John Mattsson
1751 27.pdf [57] - In this paper, we give an overview of various
1752 opportunistic and unauthenticated encryption techniques, and discuss
1753 their benefits, limits, and disadvantages. We recommend the Internet
1754 community to clearly define the term "opportunistic encryption" or to
1755 use other terms. We conclude that while opportunistic and
1756 unauthenticated encryption certainly has its uses and may with the
1757 right choices provide good enough security for a low cost, general
1758 deployment of unauthenticated encryption is not an effective way to
1759 thwart pervasive monitoring.
1761 C.28. Clearing off the Cloud over the Internet of Things - Carsten
1762 Bormann, Stefanie Gerdes, Olaf Bergmann
1764 28.pdf [58] - As was foreshadowed by product introductions in 2013,
1765 the Consumer Electronics Show 2014 has seen the introduction of a
1766 large number of "Internet of Things" (IoT) innovations. Almost all
1767 of these have in common that they are meant to operate via Cloud-
1768 based services. In the light of the recent attention to threats by
1769 state-level tenacious attackers with significant infrastructure
1770 (STASI), in particular to their practice of pervasive monitoring, we
1771 discuss the implications of a cloud-centric IoT landscape, and
1772 attempt to outline a set of principles as a program to improve the
1773 long-term outlook.
1775 C.29. Withheld
1777 C.30. The Trust-to-Trust Model of Cloud Services - Alissa Cooper,
1778 Cullen Jennings
1780 30.pdf [59]
1782 C.31. Linkability Considered Harmful - Leif Johansson
1784 31.pdf [60] - Current debate on pervasive monitoring often focus on
1785 passive attacks on the protocol and transport layers but even if
1786 these issues were eliminated through the judicious use of encryption,
1787 roughly the same information would still be available to an attacker
1788 who is able to (legally or otherwize) obtain access to linked data
1789 sets which are being maintained by large content and service
1790 providers.
1792 C.32. Simple Opportunistic Encryption - Andrea Bittau, Michael Hamburg,
1793 Mark Handley, David Mazieres, Dan Boneh
1795 32.pdf [61] - Network traffic encryption is becoming a requirement,
1796 not an option. Enabling encryption will be a communal effort so a
1797 solution that gives partial benefits until fully deployed is needed.
1798 A solution that requires little changes to existing infrastructure
1799 will also help as it can be quickly deployed to give immediate short-
1800 term benefits. We argue that tcpcrypt, a TCP option for
1801 opportunistic encryption is the path of least-resistance for a
1802 solution against large-scale traffic encryption. Tcpcrypt requires
1803 no changes to applications, is compatible with existing networks
1804 (works with NATs), and just works by default. It is high
1805 performance, so it can be deployed on servers without much concern.
1806 tcpcrypt attempts to maximize security for any given setting. By
1807 default, it will protect against passive eavesdropping, and also
1808 allows detecting large scale interception. With authentication,
1809 tcpcrypt can provide full security against active attackers and so it
1810 is a complete solution both for the short-term and long-term.
1812 C.33. An Architecture for a Secure Cloud Collaboration System - Cullen
1813 Jennings, Suhas Nandakumar
1815 33.pdf [62] - The Internet technical community is looking at ways to
1816 address pervasive attacks as described in several other internet
1817 drafts. [I-D.barnes-pervasive-problem] describes threat model to
1818 characterize various pervasive attacks on the Internet
1819 communications. There are many systems that need to be secured
1820 against such attacks but this paper considers one possible way to
1821 secure cloud based collaborations systems. At a high level, this
1822 paper sugests that users or enterprises could run a key server that
1823 manages the keys to access their content. The cloud service provider
1824 would not have access to decrypt the data stored in the cloud but
1825 various users of the cloud service could get the keys to encrypt and
1826 decrypt the contents of collaboration sessions facilitated by the
1827 cloud service. This does not protect the meta data of who is talking
1828 to who but can help protect the content of the conversations.
1830 C.34. Security and Simplicity - Steven Bellovin
1832 34.pdf [63]
1834 C.35. Privacy at the Link Layer - Piers O'Hanlon, Joss Wright, Ian
1835 Brown
1837 35.pdf [64] - This paper gives an overview of the privacy issues
1838 around the use of link layer identifiers and associated protocols.
1839 Whilst the IETF generally specifies IP level protocols it does also
1840 address the link layer in protocols such as address resolution,
1841 network attachment detection, tunnelling and router redundancy.
1843 The indiscriminate broadcast of a device's MAC address, a unique and
1844 effectively personal identifier, allows for unregulated and broad-
1845 scale tracking of individuals via their personal devices, whether or
1846 not those devices have made use of a particular service or not.
1847 These addresses typically remain unchanged for the lifetime of a
1848 device, creating a persistent, lifelong tracking capability. The
1849 collation of such addresses, primarily WiFi and Bluetooth, has been
1850 been gathering pace and is already in use by organisations such as
1851 security agencies and advertisers.
1853 Ephemeral addresses are used further up the stack so why not at the
1854 link layer? As default devices should use a randomised MAC address
1855 and any higher level associations can be maintained as and when
1856 approved by the user. Moreover various other 'performance enhancing'
1857 approaches further degrade the privacy of individuals such as
1858 proactive discovery of WLAN SSIDs, Detection of Network Attachment
1859 (DNA), Wireless ISP roaming (WISPr), name lookups and so on.
1861 All these mechanisms need to be re-examined in the light of pervasive
1862 monitoring.
1864 C.36. Erosion of the moral authority of middleboxes - Joe Hildebrand
1866 36.pdf [65] - Many middleboxes on the Internet attempt to add value
1867 to the connections that traverse that point on the network. Problems
1868 in their implementations erode the moral authority that otherwise
1869 might accrue to the legitimate value that they add.
1871 C.37. Policy Responses, Implications and Opportunities - Joseph Lorenzo
1872 Hall & Runa Sandvik
1874 37.pdf [66] - We raise issues for discussion that lie in the
1875 interface between policy and technology. Specifically, we discuss 1)
1876 routing, processing and data localization policy mandates (i.e., new
1877 laws that may affect how data flows through the 'net; 2) the
1878 uncertain possibility of dilution of credibility of IETF and w3c
1879 given what we've seen with NIST after NSA-coziness allegations; 3)
1880 the claim that strenghtening the internet and web will "help the bad
1881 guys" and the dubious need for "lawful intercept" funcationality; and
1882 3) abusive content, cryptography as a controlled export technology,
1883 and the need to standardize more anonymity primitives (onion routing,
1884 pluggable transport protocols). We also highlight our own work in
1885 ensuring that technologists have a voice in policy environments and
1886 discuss a few interventions we coordinated over the past year,
1887 focusing on software backdoors and NSA surviellance.
1889 C.38. Is it time to bring back the hosts file? - Peter Eckersley
1891 38.pdf [67]
1893 C.39. Metaphors matter; application-layer; distribute more - Larry
1894 Masinter
1896 39.pdf [68] -
1898 1. Dont say Attack: IETF should stay away from political theatre:
1899 changing protocols or workflows not because the change works but
1900 just to say you did something. Metaphors matter.
1902 2. For most relevant threats, traffic analysis is enough, and
1903 encyption doesnt mitigate.
1905 3. The only deployable protection - if that is what is wanted -
1906 means shifting architecture from client-server to mesh.
1908 C.40. Levels of Opportunistic Privacy Protection for Messaging-Oriented
1909 Architectures - Dave Crocker, Pete Resnick
1911 40.pdf [69] - Messaging protection against pervasive monitoring (PM)
1912 needs to cover primary payload, descriptive meta-data, and traffic-
1913 related analysis. Complete protection against PM, for traffic
1914 through complex handling sequences, has not yet been achieved
1915 reliably in real-world operation. Consequently, this document
1916 considers a range of end-to-end, object-based mechanisms, distinct
1917 from channel-based mechanisms. Each approach offers incremental
1918 protection levels that can be provided with existing, or low-risk,
1919 component technologies, such as through the DNS and MIME conventions.
1921 C.41. Fingerprinting Guidance for Web Specification Authors - Nick Doty
1923 41.pdf [70] - http://w3c.github.io/fingerprinting-guidance/ -
1924 Exposure of settings and characteristics of browsers can impact user
1925 privacy by allowing for browser fingerprinting. This document
1926 defines different types of fingerprinting, considers distinct levels
1927 of mitigation for the related privacy risks and provides guidance for
1928 Web specification authors on how to balance these concerns when
1929 designing new Web features.
1931 C.42. Eradicating Bearer Tokens for Session Management - Philippe De
1932 Ryck, Lieven Desmet, Frank Piessens, Wouter Joosen
1934 42.pdf [71] - Session management is a crucial component in every
1935 modern web application. It links multiple requests and temporary
1936 stateful information together, enabling a rich and interactive user
1937 experience. The de facto cookie-based session management mechanism
1938 is however flawed by design, enabling the theft of the session cookie
1939 through simple eavesdropping or script injection attacks. Possession
1940 of the session cookie gives an adversary full control the user's
1941 sover ession, allowing him to impersonate the user to the target
1942 application and perform transactions in the user's name. While
1943 several alternatives for secure session management exist, they fail
1944 to be adopted due to the introduction of additional roundtrips and
1945 overhead, as well as incompatibility with current Web technologies,
1946 such as third-party authentication providers, or widely deployed
1947 middleboxes, such as web caches. We identify four key objectives for
1948 a secure session management mechanism, aiming to be compatible with
1949 the current and future Web. We propose SecSess, a lightweight session
1950 management mechanism based on a shared secret between client and
1951 server, used to authenticate each request. SecSess ensures that a
1952 session remains under control of the parties that established it, and
1953 only introduces limited overhead. During session establishment,
1954 SecSess introduces no additional roundtrips and only adds 4.3
1955 milliseconds to client-side and server-side processing. Once a
1956 session is established, the overhead becomes negligible (<0.1ms), and
1957 the average size of the request headers is even smaller than with
1958 common session cookies. Additionally, SecSess works well with
1959 currently deployed systems, such as web caches and third-party
1960 services. SecSess also supports a gradual migration path, while
1961 remaining compatible with currently existing applications.
1963 C.43. STREWS Web-platform security guide: security assessment of the
1964 Web ecosystem - Martin Johns, Lieven Desmet
1966 43.pdf [72] - In this document, we report on the Web-platform
1967 security guide, which has been developed within the EC-FP7 project
1968 STREWS. Based on their research, the STREWS consortium argues that
1969 in order to strengthening the Internet (e.g. against pervasive
1970 monitoring), it is crucial to also strengthen the web application
1971 ecosystem, the de-facto Internet application platform.
1973 C.44. Pervasive Attack: A Threat Model and Problem Statement - Richard
1974 Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie
1976 44.pdf [8] - Documents published in 2013 have revealed several
1977 classes of "pervasive" attack on Internet communications. In this
1978 document, we review the main attacks that have been published, and
1979 develop a threat model that describes these pervasive attacks. Based
1980 on this threat model, we discuss the techniques that can be employed
1981 in Internet protocol design to increase the protocols robustness to
1982 pervasive attacks.
1984 C.45. Cryptech - Building a More Assured HSM with a More Assured Tool-
1985 Chain - Randy Bush
1987 45.pdf [73]
1989 C.46. Replacing passwords on the Internet AKA post-Snowden
1990 Opportunistic Encryption - Ben Laurie, Ian Goldberg
1992 46.pdf [74]
1994 C.47. End-User Concerns about Pervasive Internet Monitoring: Principles
1995 and Practice - Tara Whalen, Stuart Cheshire, David Singer
1997 47.pdf [75] - This position paper will discuss pervasive monitoring
1998 on the Internet from the perspective of end users: what are
1999 overarching concerns around pervasive monitoring, and what are some
2000 steps that could be taken to address those concerns? We begin by
2001 exploring a preliminary set of characteristics of systemic
2002 surveillance, which can be used to pinpoint dominant concerns of end
2003 users that should be addressed through technical means. We then
2004 illustrate one specific significant problem facing end users, namely
2005 that of certificate errors, which can be exploited to facilitate
2006 pervasive surveillance. We suggest that users should not be required
2007 to determine whether a certificate error is valid, but instead to
2008 block access to websites that generate such errors. We believe this
2009 approach would be more effective in protecting end users in an
2010 environment of persistent network threats.
2012 C.48. Developer-Resistant Cryptography - Kelsey Cairns, Graham Steel
2014 48.pdf [76] - "Properly implemented strong crypto systems are one of
2015 the few things that you can rely on" - Edward Snowden. So why is
2016 mass surveillance so successful? One (big) problem is endpoint
2017 security. Another is that strong crypto systems are sufficiently
2018 difficult to implement that often either mistakes are made resulting
2019 in catastrophic loss of security, or cryptography is not used at all.
2020 What can we do to make cryptography easier to use and more resistant
2021 to developer errors?
2023 C.49. Improving the reliability of key ownership assertions - Kai
2024 Engert
2026 49.pdf [77] - A majority of today's secure Internet connections rely
2027 on Certificate Authorities not being abused for issueing false
2028 certificates (key ownership assertions), which might get abused for
2029 interception purposes, despite the risk of detection. I suggest to
2030 enhance Internet protocols with protective mechanisms to detect false
2031 key ownership assertions. Ideas: (1) Using a network of proxy
2032 services, for example as implemented by the The Onion Router (Tor),
2033 consistency checking chould be performed by individual clients, in
2034 order to detect assertions that are likely false, prior to allowing a
2035 connection (see Detector.io). (2) Extend the idea that notary
2036 services provide a second opinion about the correctness of key
2037 ownership assertions, by requiring CAs to run such services (kuix.de/
2038 mecai). (3) Implement protocol extensions, where client software
2039 reports previously seen key ownership assertions to the operators of
2040 services, allowing the discovery of false ownership assertions.
2042 C.50. Mike O'Neill's Position Paper - Mike O'Neill
2044 50.pdf [78]
2046 C.51. Detecting MITM Attacks on Ephemeral Diffie-Hellman without
2047 Relying on a PKI in Real-Time Communications - Alan Johnston
2049 51.pdf [79] - With the recent revelations about pervasive
2050 surveillance on the Internet, there is renewed interest in techniques
2051 that protect against passive eavesdropping without relying on a
2052 Public Key Infrastructure (PKI). An ephemeral Diffie-Hellman (DH)
2053 key agreement can provide such protection, but (without
2054 authentication) the exchange is vulnerable to a Man in the Middle
2055 (MitM) attack. An example of a protocol that has MitM protection for
2056 a DH key agreement is ZRTP, RFC 6189, "ZRTP: Media Path Key Agreement
2057 for Unicast Secure RTP." ZRTP provides pervasive surveillance
2058 resistant security for Voice over IP (VoIP), video communication, and
2059 other real-time communication services. This paper describes the
2060 techniques used by ZRTP to detect MitM attacks, and explores whether
2061 these techniques could be used to develop a general MitM detection
2062 protocol to be used by other non-real-time communication protocols.
2063 An example of how ZRTP can provide MitM detection for another
2064 protocol, DTLS-SRTP, Datagram Transport Layer Security - Secure Real-
2065 time Transport Protocol, is given.
2067 C.52. Trust & Usability on the Web, a Social/Legal perspective - Rigo
2068 Wenning, Bert Bos
2070 52.pdf [80] - (1) The browsers' UIs for security are very technical
2071 and seem to avoid saying anything useful, maybe so that the browsers
2072 and CAs cannot be held responsible. (2) A user wanting to configure
2073 security has difficulty finding the UI and then often discovers that
2074 settings are hard-coded or unclear. (3) The security model is based
2075 on trusting a few commercial entities and mistrusting the user, who
2076 ends up without control over his software if one of those entities is
2077 compromised or doesn't share his goals. Conclusion: We need better
2078 UIs, which in turn requires a PKI that has the metadata and social
2079 aspects that help users understand and explore the keys and the
2080 organizations behind them.
2082 C.53. Hardening Operations and Management Against Passive Eavesdropping
2083 - Bernard Aboba
2085 53.pdf [81] - Today within service providers protocols used for
2086 operations and management frequently send data in the clear, enabling
2087 the data to be collected by passive eavesdroppers. Examples of
2088 operations and management protocols include Authentication,
2089 Authorization and Accounting (AAA), syslog and Simple Networking
2090 Monitoring Protocol (SNMP). Since the publication of "Operational
2091 Security Current Practices in Internet Service Provider Environments"
2092 [RFC4778], the IETF has developed specifications that enable per-
2093 packet confidentiality to be applied to operations and management
2094 protocols. By developing updated operational guidance recommending
2095 deployment of per-packet confidentiality based on recent IETF Request
2096 for Comments (RFCs) and work-in-progress, the IETF can assist in
2097 bringing customer and regulatory pressure to bear in improving
2098 operational practices.
2100 C.54. A few theses regarding privacy and security - Andreas Kuckartz
2102 54.pdf [82]
2104 C.55. Meet the new threat model, same as the old threat model - Eric
2105 Rescorla
2107 55.pdf [83] - The Internet environment has a fairly well understood
2108 threat model. In general, we assume that the end-systems engaging in
2109 a protocol exchange have not themselves been compromised. Protecting
2110 against an attack when one of the end-systems has been compromised is
2111 extraordinarily difficult. It is, however, possible to design
2112 protocols which minimize the extent of the damage done under these
2113 circumstances.
2115 By contrast, we assume that the attacker has nearly complete control
2116 of the communications channel over which the end-systems communicate.
2117 This means that the attacker can read any PDU (Protocol Data Unit) on
2118 the network and undetectably remove, change, or inject forged packets
2119 onto the wire. This includes being able to generate packets that
2120 appear to be from a trusted machine. Thus, even if the end-system
2121 with which you wish to communicate is itself secure, the Internet
2122 environment provides no assurance that packets which claim to be from
2123 that system in fact are. - [RFC3552]
2125 C.56. It's Time for Application-Centric Security - Yuan Gu, Harold
2126 Johnson
2128 56.pdf [84] - An 'application' is an organized data/executable-code
2129 compound performing a specific function or service. We hold that
2130 applications should be protected intrinsically (by obfuscated,
2131 tamper-resistant code and data), as well as extrinsically (by
2132 encrypted communication, hardened hardware platforms, authenticated
2133 access). (1) Cloud-based applications are vulnerable to their hosting
2134 services or neighbors. (2) Peripheral-based applications (on phones,
2135 pads, PDAs, or more generally in the Internet of Things) are
2136 vulnerable because hardware security is inconsistent and very
2137 expensive to repair. (3) Browser-based applications are vulnerable
2138 because they run on potentially hostile or malware-infected browsers
2139 or platforms which we don't control. Application obfuscations such
2140 as homomorphic transforms on data and computation (motto: avoid data
2141 or computation in plain form) and increased interdependency (motto:
2142 aggressive fragility under tampering) can effectively address these
2143 vulnerabilities.
2145 C.57. Sabatini Monatesti position paper - Sabatine Monatesti
2147 57.pdf [85]
2149 C.58. Trust problems in pervasive monitoring - Melinda Shore, Karen
2150 O'Donoghue
2152 58.pdf [86]
2154 C.59. Beyond "Just TLS Everywhere": From Client-encrypted Messaging to
2155 Defending the Social Graph - Harry Halpin, George Danezis
2157 59.pdf [87]
2159 C.60. Network Security as a Public Good - Wendy Seltzer
2161 60.pdf [88] - Network security depends on cooperation of multiple
2162 actors in the Internet ecosystem. Standards consortia should support
2163 and help coordinate activity to protect the commons.
2165 C.61. Statement of Interest on behalf of the W3C TAG - Dan Appelquist
2167 61.pdf [89]
2169 C.62. Improving Security on the Internet - Hannes Tschofenig
2171 62.pdf [90] - Securing the Internet has been an on-going activity
2172 since the early days of the IETF and a variety of technical
2173 specifications have been standardized. Someone reading through IETF
2174 RFCs might easily get the impression that the Internet should be very
2175 secure. This is, however, not the entire story as the never-ending
2176 series of breaches and recently the Snowden revelations have
2177 illustrated. While on paper everything looks pretty good many
2178 problems can be found in implementations and with deployments.
2180 In this position paper the author makes the argument that improving
2181 the collaboration between different communities in the Internet
2182 software development life-cycle will be crucial for improving
2183 security on the Internet.
2185 C.63. Protecting customer data from government snooping - Orit Levin
2187 63.pdf [91]
2189 C.64. Privacy Aware Internet Development Initiative 2014 - Achim
2190 Klabunde
2192 64.pdf [92] - Protecting privacy on the Internet requires more than
2193 using encryption. Protocols, implementations and applications must
2194 minimise the amount of personal data that is distributed and
2195 collected. Work is required to develop and disseminate privacy aware
2196 design and impmementation techniques to the actual developers. The
2197 paper is a call for interest for an initiative aiming to address this
2198 need, supported by privacy and technology experts.
2200 C.65. The Internet is Broken: Idealistic Ideas for Building a NEWGNU
2201 Network - Christian Grothoff, Bartlomiej Polot, Carlo von Loesch
2203 65.pdf [93] - This paper describes issues for security and privacy at
2204 all layers of the Internet stack and proposes radical changes to the
2205 architecture to build a network that offers strong security and
2206 privacy by default.
2208 C.66. Opportunistic Keying as a Countermeasure to Pervasive Monitoring
2209 - Stephen Kent
2211 66.pdf [94] - This document was prepared as part of the IETF response
2212 to concerns about "pervasive monitoring" as articulated in
2213 [draft-farrell-perpass-attack]. It begins by exploring terminology
2214 that has been used in IETF standards (and in academic publications)
2215 to describe encryption and key management techniques, with a focus on
2216 authentication vs. anonymity. Based on this analysis, it propose a
2217 new term, "opportunistic keying" (OK) to describe a goal for IETF
2218 security protocols, one possible countermeasure to pervasive
2219 monitoring. It reviews key management mechanisms used in IETF
2220 security protocol standards, with respect to these properties, to
2221 identify what changes might be needed to offer OK with minimal
2222 changes. The document ends by examining possible impediments to and
2223 potential adverse effects associated with deployment and use of
2224 techniques that would increase the use of encryption, even when keys
2225 are distributed in an unauthenticated manner.
2227 Appendix D. Workshop chairs & program committee
2229 The workshop chairs were three: Stephen Farrell [95] (TCD) and Rigo
2230 Wenning [96] (W3C) from the STREWS project, and Hannes
2231 Tschofenig [97] (ARM) from the STREWS Interest Group.
2233 A program committee (PC) was charged with evaluating the submitted
2234 papers. It was made up of the members of the STREWS project, the
2235 members of the STREWS Interest Group, plus invited experts: Bernard
2236 Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard
2237 Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen
2238 O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP),
2239 Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal
2240 Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler
2241 (Microsoft) and Sean Turner (IECA).
2243 Appendix E. Participants
2245 The participants to the workshop were:
2247 o *Bernard Aboba* (Microsoft Corporation)
2249 o *Thijs Alkemade* (Adium)
2251 o *Daniel Appelquist* (Telefonica Digital)
2252 o *Jari Arkko* (Ericsson)
2254 o *Alia Atlas* (Juniper Networks)
2256 o *Emmanuel Baccelli* (INRIA)
2258 o *Mary Barnes*
2260 o *Richard Barnes* (Mozilla)
2262 o *Steve Bellovin* (Columbia University)
2264 o *Andrea Bittau* (Stanford University)
2266 o *Marc Blanchet* (Viagenie)
2268 o *Carsten Bormann* (Uni Bremen TZI)
2270 o *Bert Bos* (W3C)
2272 o *Ian Brown* (Oxford University)
2274 o *Stewart Bryant* (Cisco Systems)
2276 o *Randy Bush* (IIJ / Dragon Research Labs)
2278 o *Kelsey Cairns* (Washington State University)
2280 o *Stuart Cheshire* (Apple)
2282 o *Vincent Cheval* (University of Birmingham)
2284 o *Benoit Claise* (Cisco)
2286 o *Alissa Cooper* (Cisco)
2288 o *Dave Crocker* (Brandenburg InternetWorking)
2290 o *Leslie Daigle* (Internet Society)
2292 o *George Danezis* (University College London)
2294 o *Spencer Dawkins* (Huawei)
2296 o *Mark Donnelly* (Painless Security)
2298 o *Nick Doty* (W3C)
2299 o *Dan Druta* (AT&T)
2301 o *Peter Eckersley* (Electronic Frontier Foundation)
2303 o *Lars Eggert* (NetApp)
2305 o *Kai Engert* (Red Hat)
2307 o *Monika Ermert*
2309 o *Stephen Farrell* (Trinity College Dublin)
2311 o *Barbara Fraser* (Cisco)
2313 o *Virginie Galindo* (gemalto)
2315 o *Stefanie Gerdes* (Uni Bremen TZI)
2317 o *Daniel Kahn Gillmor* (ACLU)
2319 o *Wendy M. Grossman*
2321 o *Christian Grothoff* (The GNUnet Project)
2323 o *Oliver Hahm* (INRIA)
2325 o *Joseph Lorenzo Hall* (Center for Democracy & Technology)
2327 o *Phillip Hallam-Baker*
2329 o *Harry Halpin* (W3C/MIT and IRI)
2331 o *Ted Hardie* (Google)
2333 o *Joe Hildebrand* (Cisco Systems)
2335 o *Russ Housley* (Vigil Security, LLC)
2337 o *Cullen Jennings* (CISCO)
2339 o *Leif Johansson* (SUNET)
2341 o *Harold Johnson* (Irdeto)
2343 o *Alan Johnston* (Avaya)
2345 o *L. Aaron Kaplan* (CERT.at)
2346 o *Steve Kent* (BBN Technologies)
2348 o *Achim Klabunde* (European Data Protection Supervisor)
2350 o *Hans Kuhn* (NOC)
2352 o *Christian de Larrinaga*
2354 o *Ben Laurie* (Google)
2356 o *Eliot Lear* (Cisco Ssytems)
2358 o *Barry Leiba* (Huawei Technologies)
2360 o *Sebastian Lekies* (SAP AG)
2362 o *Orit Levin* (Microsoft Corporation)
2364 o *carlo von lynX* (#youbroketheinternet)
2366 o *Xavier Marjou* (Orange)
2368 o *Larry Masinter* (Adobe)
2370 o *John Mattsson* (Ericsson)
2372 o *Patrick McManus* (Mozilla)
2374 o *Doug Montgomery* (NIST)
2376 o *Kathleen Moriarty* (EMC)
2378 o *Alec Muffett* (Facebook)
2380 o *Suhas Nandakumar* (Cisco Systems)
2382 o *Linh Nguyen* (ERCIM/W3C)
2384 o *Linus Nordberg* (NORDUnet)
2386 o *Mark Nottingham*
2388 o *Karen O'Donoghue* (Internet Society)
2390 o *Piers O'Hanlon* (Oxford Internet Institute)
2392 o *Kenny Paterson* (Royal Holloway, University of London)
2393 o *Jon Peterson* (Neustar)
2395 o *Joshua Phillips* (University of Birmingham)
2397 o *Alfredo Pironti* (INRIA)
2399 o *Dana Polatin-Reuben* (University of Oxford)
2401 o *Prof. Johan Pouwelse* (Delft University of Technology)
2403 o *Max Pritikin* (Cisco)
2405 o *Eric Rescorla* (Mozilla)
2407 o *Pete Resnick* (Qualcomm Technologies, Inc.)
2409 o *Tom Ristenpart* (University of Wisconsin)
2411 o *Andrei Robachevsky* (Internet Society)
2413 o *David Rogers* (Copper Horse)
2415 o *Scott Rose* (NIST)
2417 o *Christine Runnegar* (Internet Society)
2419 o *Philippe De Ryck* (DistriNet - KU Leuven)
2421 o *Peter Saint-Andre* (&yet)
2423 o *Runa A. Sandvik* (Center for Democracy and Technology)
2425 o *Jakob Schlyter* (キレイ)
2427 o *Dr. Jan Seedorf* (NEC Laboratories Europe)
2429 o *Wendy Seltzer* (W3C)
2431 o *Melinda Shore* (No Mountain Software)
2433 o *Dave Thaler* (Microsoft)
2435 o *Brian Trammell* (ETH Zurich)
2437 o *Hannes Tschofenig* (ARM Limited)
2439 o *Sean Turner* (IECA, Inc.)
2440 o *Matthias Waehlisch* (Freie Universitaet Berlin)
2442 o *Greg Walton* (Oxford University)
2444 o *Rigo Wenning* (W3C)
2446 o *Tara Whalen* (Apple Inc.)
2448 o *Greg Wood* (Internet Society)
2450 o *Jiangshan Yu* (University of Birmingham)
2452 o *Aaron Zauner*
2454 o *Dacheng Zhang* (Huawei)
2456 o *Phil Zimmermann* (Silent Circle LLC)
2458 o *Juan-Carlos Zuniga* (InterDigital)
2460 Authors' Addresses
2462 Stephen Farrell
2463 Trinity College, Dublin
2465 Email: stephen.farrell@cs.tcd.ie
2467 Rigo Wenning
2468 World Wide Web Consortium
2469 2004, route des Lucioles
2470 B.P. 93
2471 Sophia-Antipolis 06902
2472 France
2474 Email: rigo@w3.org
2476 Bert Bos
2477 World Wide Web Consortium
2478 2004, route des Lucioles
2479 B.P. 93
2480 Sophia-Antipolis 06902
2481 France
2483 Email: bert@w3org
2484 Marc Blanchet
2485 Viagenie
2486 246 Aberdeen
2487 Quebec, QC G1R 2E1
2488 Canada
2490 Email: Marc.Blanchet@viagenie.ca
2491 URI: http://viagenie.ca
2493 Hannes Tschofenig
2494 ARM Ltd.
2495 110 Fulbourn Rd
2496 Cambridge CB1 9NJ
2497 Great Britain
2499 Email: Hannes.tschofenig@gmx.net
2500 URI: http://www.tschofenig.priv.at