draft-iab-strint-report-00.txt   draft-iab-strint-report-01.txt 
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College, Dublin Internet-Draft Trinity College, Dublin
Intended status: Informational R. Wenning Intended status: Informational R. Wenning
Expires: October 30, 2014 B. Bos Expires: November 24, 2015 B. Bos
W3C W3C
M. Blanchet M. Blanchet
Viagenie Viagenie
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
April 28, 2014 May 23, 2015
STRINT workshop report Report from the Strengthening the Internet (STRINT) workshop
draft-iab-strint-report-00 draft-iab-strint-report-01
Abstract Abstract
The STRINT workshop assembled one hundred participants in London for The Strengthening the Internet (STRINT) workshop assembled one
two days in early 2014 to discuss how the technical community, and in hundred participants in London for two days in early 2014 to discuss
particular the IETF and the W3C, should react to Pervasive Monitoring how the technical community, and in particular the IETF and the W3C,
and more generally how to strengthen the Internet in the face of such should react to Pervasive Monitoring and more generally how to
attacks. The discussions covered issues of terminology, the role of strengthen the Internet in the face of such attacks. The discussions
user interfaces, classes of mitigation, some specific use cases, covered issues of terminology, the role of user interfaces, classes
transition strategies (including opportunistic encryption), and more. of mitigation, some specific use cases, transition strategies
The workshop ended with a few high-level recommendations, which it is (including opportunistic encryption), and more. The workshop ended
believed could be implemented and which could help strengthen the with a few high-level recommendations, which it is believed could be
Internet. This is the report of that workshop. implemented and which could help strengthen the Internet. This is
the report of that workshop.
Status of this Memo Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2015.
This Internet-Draft will expire on October 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Workshop goals . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Workshop goals . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop structure . . . . . . . . . . . . . . . . . . . . . . 5 4. Workshop structure . . . . . . . . . . . . . . . . . . . . . 5
5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. After the workshop . . . . . . . . . . . . . . . . . . . . . . 20 6. After the workshop . . . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security considerations . . . . . . . . . . . . . . . . . . . 21 8. Security considerations . . . . . . . . . . . . . . . . . . . 21
9. Informative references . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix C. The submitted papers . . . . . . . . . . . . . . . . 28 Appendix C. The submitted papers . . . . . . . . . . . . . . . . 31
Appendix D. Workshop chairs & program committee . . . . . . . . . 44 Appendix D. Workshop chairs & program committee . . . . . . . . 47
Appendix E. Participants . . . . . . . . . . . . . . . . . . . . 45 Appendix E. Participants . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Context 1. Context
[[Editorial note: This version was produced from the minutes, and The Vancouver IETF plenary[vancouverplenary] concluded that Pervasive
then edited. It quite likely has some inaccuracies, so the authors Monitoring (PM) represents an attack on the Internet, and the IETF
would welcome corrections from those who attended the workshop. If has begun to carry out the more obvious actions required to try to
you're a github person, https://github.com/sftcd/strint-report has handle this attack. However, there are additional much more complex
this so you can contribute there.]] questions arising that need further consideration before any
The Vancouver IETF plenary concluded [vancouverplenary] that
Pervasive Monitoring (PM) represents an attack on the Internet, and
the IETF has begun to carry out the more obvious actions required to
try to handle this attack. However, there are additional much more
complex questions arising that need further consideration before any
additional concrete plans can be made. additional concrete plans can be made.
The W3C [1] and IAB [2] therefore decided to host a workshop [3] on The W3C [1] and IAB [2] therefore decided to host a workshop [3] on
the topic of "Strengthening the Internet Against Pervasive the topic of "Strengthening the Internet Against Pervasive
Monitoring" before IETF 89 [4] in London in March 2014. The FP7- Monitoring" before IETF 89 [4] in London in March 2014. The
funded STREWS [5] project organised the STRINT workshop on behalf of FP7-funded STREWS [5] project organised the STRINT workshop on behalf
the IAB and W3C. of the IAB and W3C.
The main workshop goal was to discuss what can be done, especially by The main workshop goal was to discuss what can be done, especially by
the two standards organisations IETF and W3C, against PM, both for the two standards organisations IETF and W3C, against PM, both for
existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones
(WebRTC, HTTP/2, etc.). (WebRTC, HTTP/2, etc.).
The starting point for the workshop was the existing IETF consensus The starting point for the workshop was the existing IETF consensus
that PM is an attack[I-D.farrell-perpass-attack]. that PM is an attack[RFC7258] (the text of which had achieved IEFF
consensus at the time of the workshop, even though the RFC had yet to
be published).
2. Summary 2. Summary
The workshop was well attended (registration closed when the maximum The workshop was well attended (registration closed when the maximum
capacity of 100 was reached, but more than 150 expressed a desire to capacity of 100 was reached, but more than 150 expressed a desire to
register) and several people (about 165 at the maximum) listened to register) and several people (about 165 at the maximum) listened to
the streaming audio. The submitted papers (67 in total) were the streaming audio. The submitted papers (67 in total) were
generally of good quality and all were published (see Appendix C), generally of good quality and all were published (see Appendix C),
except for a few where authors who couldn't take part in the workshop except for a few where authors who couldn't take part in the workshop
preferred not to publish. preferred not to publish.
skipping to change at page 4, line 19 skipping to change at page 3, line 46
3. Work should continue on progressing the PM threat model 3. Work should continue on progressing the PM threat model
draft[I-D.barnes-pervasive-problem] discussed in the workshop. draft[I-D.barnes-pervasive-problem] discussed in the workshop.
4. Later, the IETF may be in a position to start to develop an 4. Later, the IETF may be in a position to start to develop an
update to BCP 72 [RFC3552], most likely as a new RFC enhancing update to BCP 72 [RFC3552], most likely as a new RFC enhancing
that BCP and dealing with recommendations on how to mitigate PM that BCP and dealing with recommendations on how to mitigate PM
and how to reflect that in IETF work. and how to reflect that in IETF work.
5. The term "Opportunistic" has been widely used to refer to a 5. The term "Opportunistic" has been widely used to refer to a
possible mitigation strategy for PM. We need to document possible mitigation strategy for PM. The community need to
definition(s) for this term, as it is being used differently by document definition(s) for this term, as it is being used
different people and in different contexts. We may also be able differently by different people and in different contexts. We
to develop a cookbook-like set of related protocol techniques may also be able to develop a cookbook-like set of related
for developers. Since the workshop, the IETF's security area protocol techniques for developers. Since the workshop, the
has taken up this work, most recently favouring the generic term IETF's security area has taken up this work, most recently
"Opportunistic Security" (OS) [I-D.kent-opportunistic-security]. favouring the generic term "Opportunistic Security" (OS)
[I-D.kent-opportunistic-security]. Subsequent work on this
topic resulted in the publication of a definition of OS in
[RFC7435].
6. The technical community could do better in explaining the real 6. The technical community could do better in explaining the real
technical downsides related to PM in terms that policy makers technical downsides related to PM in terms that policy makers
can understand. can understand.
7. Many User Interfaces (UI) could be better in terms of how they 7. Many User Interfaces (UI) could be better in terms of how they
present security state, though this is a significantly hard present security state, though this is a significantly hard
problem. There may be benefits if certain dangerous choices problem. There may be benefits if certain dangerous choices
were simply not offered anymore. But that could require were simply not offered anymore. But that could require
significant co-ordination among competing software makers, significant co-ordination among competing software makers,
otherwise some will be considered "broken" by users. otherwise some will be considered "broken" by users.
8. Ways to better integrate UI issues into the processes of IETF 8. Further discussion is needed on ways to better integrate UI
and W3C needs further discussion. issues into the processes of IETF and W3C.
9. Examples of good software configurations that can be cut-and- 9. Examples of good software configurations that can be cut-and-
paste'd for popular software, etc., can help. This is not paste'd for popular software, etc., can help. This is not
necessarily standards work, but maybe the standards necessarily standards work, but maybe the standards
organisations can help and can work with those developing such organisations can help and can work with those developing such
package-specific documentation. package-specific documentation.
10. The IETF and W3C can do more so that default ("out-of-the-box") 10. The IETF and W3C can do more so that default ("out-of-the-box")
settings for protocols better protect security and privacy. settings for protocols better protect security and privacy.
11. Captive portals, [6] (and some firewalls, too) can and should be 11. Captive portals [6] (and some firewalls, too) can and should be
distinguished from real man-in-the-middle attacks. This might distinguished from real man-in-the-middle attacks. This might
mean establishing common conventions with makers of such mean establishing common conventions with makers of such
middleboxes, but might also need new protocols. However, the middleboxes, but might also need new protocols. However, the
incentives for deploying such new middlebox features might not incentives for deploying such new middlebox features might not
align. align.
3. Workshop goals 3. Workshop goals
As stated, the STRINT workshop started from the position that PM is As stated, the STRINT workshop started from the position [RFC7258]
an attack. [I-D.farrell-perpass-attack] While some dissenting voices that PM is an attack. While some dissenting voices are expected and
are expected and need to be heard, that was the baseline assumption need to be heard, that was the baseline assumption for the workshop,
for the workshop, and the high-level goal was to provide more and the high-level goal was to provide more consideration of that and
consideration of that and how it ought to affect future work within how it ought to affect future work within the IETF and W3C.
the IETF and W3C.
At the next level down the goals of the STRINT workshop were to: At the next level down the goals of the STRINT workshop were to:
o Discuss and hopefully come to agreement among the participants on o Discuss and hopefully come to agreement among the participants on
concepts in PM for both threats and mitigation, e.g., concepts in PM for both threats and mitigation, e.g.,
"opportunistic" as the term applies to cryptography. "opportunistic" as the term applies to cryptography.
o Discuss the PM threat model, and how that might be usefully o Discuss the PM threat model, and how that might be usefully
documented for the IETF at least, e.g., via an update to documented for the IETF at least, e.g., via an update to BCP72.
BCP72. [7] [7]
o Discuss and progress common understanding in the trade-offs o Discuss and progress common understanding in the trade-offs
between mitigating and suffering PM. between mitigating and suffering PM.
o Identify weak links in the chain of Web security architecture with o Identify weak links in the chain of Web security architecture with
respect to PM. respect to PM.
o Identify potential work items for the IETF, IAB, IRTF and W3C that o Identify potential work items for the IETF, IAB, IRTF and W3C that
help mitigate PM. would help mitigate PM.
o Discuss the kinds of action outside the IETF/W3C context might o Discuss the kinds of action outside the IETF/W3C context might
help those done within the IETF/W3C. help those done within the IETF/W3C.
4. Workshop structure 4. Workshop structure
The workshop structure was designed to maximise discussion time. The workshop structure was designed to maximise discussion time.
There were no direct presentations of submitted papers. Instead, the There were no direct presentations of submitted papers. Instead, the
moderators of each session summarised topics that the Technical moderators of each session summarised topics that the Technical
Programme Committee (TPC) had agreed based on the submitted papers. Programme Committee (TPC) had agreed based on the submitted papers.
skipping to change at page 6, line 13 skipping to change at page 5, line 41
participants were asked to read and discuss the papers beforehand, at participants were asked to read and discuss the papers beforehand, at
least those relevant to their fields of interest. (To help people least those relevant to their fields of interest. (To help people
choose papers to read, authors were asked to provide short choose papers to read, authors were asked to provide short
abstracts.) abstracts.)
Most of the sessions had two moderators, one to lead the discussion, Most of the sessions had two moderators, one to lead the discussion,
while the other managed the queue of people who wanted to speak. while the other managed the queue of people who wanted to speak.
This worked well: everybody got a chance to speak and each session This worked well: everybody got a chance to speak and each session
still ended on time. still ended on time.
The penultimate session consisted of break-outs. (Which turned out The penultimate session consisted of break-outs (which turned out to
to be the most productive sessions of all, most likely simply due to be the most productive sessions of all, most likely simply due to the
the smaller numbers of people involved.) The subjects for the break- smaller numbers of people involved). The subjects for the break-outs
outs were agreed during the earlier sessions and just before the were agreed during the earlier sessions and just before the break-out
break-out session the participants collectively determined who would session the participants collectively determined who would attend
attend which. which.
5. Topics 5. Topics
The following sections contain summaries of the various sessions. The following sections contain summaries of the various sessions.
See the minutes (see Appendix B) for more details. See the minutes (see Appendix B) for more details.
5.1. Opening session 5.1. Opening session
The first session discussed the goals of the workshop. Possible The first session discussed the goals of the workshop. Possible
approaches to improving security in the light of pervasive monitoring approaches to improving security in the light of pervasive monitoring
include a critical look at what metadata is actually required, include a critical look at what metadata is actually required,
whether old (less secure) devices can be replaced with new ones, what whether old (less secure) devices can be replaced with new ones, what
are "low-hanging fruit" (issues that can be handled quickly and are "low-hanging fruit" (issues that can be handled quickly and
easily), and what level of security is "good enough": a good solution easily), and what level of security is "good enough": a good solution
may be one that is good for 90% of people or 90% of organisations. may be one that is good for 90% of people or 90% of organisations.
Some paricipants felt that standards are needed so that people can Some participants felt that standards are needed so that people can
see if their systems conform to a certain level of security as well see if their systems conform to a certain level of security, and easy
as easy to remember names for those standards, so that a buyer can to remember names are needed for those standards, so that a buyer can
immediately see that a product "conforms to the named intended immediately see that a product "conforms to the named intended
standard." standard."
5.2. Threats 5.2. Threats
One difference between "traditional" attacks and pervasive monitoring One difference between "traditional" attacks and pervasive monitoring
is modus-operandi of the attacker: typically, one determines what is modus-operandi of the attacker: typically, one determines what
resources an attacker might want to target and at what cost and then resources an attacker might want to target and at what cost and then
one defends against that threat. But a pervasive attacker has no one defends against that threat. But a pervasive attacker has no
specific targets, other than to collect everything he can. The specific targets, other than to collect everything he can. The
calculation of the cost of losing resources vs the cost of protecting calculation of the cost of losing resources vs. the cost of
them is thus different. And unlike someone motivated to make money, protecting them is thus different. And unlike someone motivated to
a PM attacker may not be concerned at the cost of the attack (or may make money, a PM attacker may not be concerned at the cost of the
even prefer a higher cost, for "empire building" reasons). attack (or may even prefer a higher cost, for "empire building"
reasons").
The terminology used to talk about threats has to be chosen carefully The terminology used to talk about threats has to be chosen carefully
(this was a common theme in several sessions), because we need to (this was a common theme in several sessions), because we need to
explain to people outside the technical community what they need to explain to people outside the technical community what they need to
do or not do. For example, authentication of endpoints doesn't so do or not do. For example, authentication of endpoints doesn't so
much "protect against" man-in-the-middle (MITM) attacks as make them much "protect against" man-in-the-middle (MITM) attacks as make them
visible. The attacker can still attack, but it does not remain visible. The attacker can still attack, but it does not remain
invisible while he does so. Somebody on either end of the invisible while he does so. Somebody on either end of the
conversation needs to react to the alert from the system: stop the conversation needs to react to the alert from the system: stop the
conversation or find a different channel. conversation or find a different channel.
skipping to change at page 7, line 49 skipping to change at page 7, line 29
authentication and is widely available. In practice though, it is authentication and is widely available. In practice though, it is
far from being used as much as it could be. It also has some far from being used as much as it could be. It also has some
problems. One problem is that certificate authorities (CA) are a problems. One problem is that certificate authorities (CA) are a
potential weak link in the system. Any CA can issue a certificate potential weak link in the system. Any CA can issue a certificate
for any server, and thus a single compromised CA can give a MITM the for any server, and thus a single compromised CA can give a MITM the
power to impersonate any server. Moreover, certificates can cost power to impersonate any server. Moreover, certificates can cost
money, acquiring a certificate requires administrator time and money, acquiring a certificate requires administrator time and
effort, and certificates need to be replaced when they expire, which effort, and certificates need to be replaced when they expire, which
is not the normal case for web technologies, so many server is not the normal case for web technologies, so many server
administrators forget or don't bother, making the certificate administrators forget or don't bother, making the certificate
infrastructure less relevant, and causing https to provide less infrastructure less relevant, and causing HTTPS to provide less
security. security.
Some ideas were discussed for improving the CA system, e.g., via Some ideas were discussed for improving the CA system, e.g., via
cross-certification of CAs and by means of "certificate cross-certification of CAs and by means of "certificate
transparency": a public, permanent log of who issued which transparency": a public, permanent log of who issued which
certificate. [RFC6962] certificate. [RFC6962]
Using other models than the hierarchical certificate model (as Using other models than the hierarchical certificate model (as
alternative or in combination) may also help. The PGP model, e.g., alternative or in combination) may also help. The PGP model, e.g.,
is a flat network where people verify the identity (public key) of is a flat network where people verify the identity (public key) of
skipping to change at page 9, line 18 skipping to change at page 8, line 46
A new protocol for peer-to-peer communication of video and audio (and A new protocol for peer-to-peer communication of video and audio (and
potentially other data) is WebRTC. WebRTC re-uses many of the same potentially other data) is WebRTC. WebRTC re-uses many of the same
architectural concepts as SIP, but there is a reasonable chance that architectural concepts as SIP, but there is a reasonable chance that
it can do better in terms of protecting users: The people it can do better in terms of protecting users: The people
implementing the protocols and offering the service have different implementing the protocols and offering the service have different
goals and interests. In particular, the first implementers are goals and interests. In particular, the first implementers are
browser makers, who may have different business models from other browser makers, who may have different business models from other
more traditional Voice over IP providers. more traditional Voice over IP providers.
XMPP suffers from yet another problem. It has encryption and XMPP[RFC6120] suffers from yet another problem. It has encryption
authentication, and the OTR ("off the record") extension even and authentication, and the OTR ("off the record") extension even
provides what is called Perfect Forward Secrecy (PFS, compromising provides what is called Perfect Forward Secrecy (PFS, compromising
the current communication never gives an attacker enough information the current communication never gives an attacker enough information
to decrypt past communications that he may have recorded). But, in to decrypt past communications that he may have recorded). But, in
practice, many people don't use XMPP at all, but rather Skype, practice, many people don't use XMPP at all, but rather Skype,
WhatsApp or other instant-messaging tools with unknown or no WhatsApp or other instant-messaging tools with unknown or no
security. The problem here seems to be one of user awareness. And security. The problem here seems to be one of user awareness. And
though OTR does provide security, it is not well integrated with XMPP though OTR does provide security, it is not well integrated with XMPP
and nor is it available as a core feature of XMPP clients. and nor is it available as a core feature of XMPP clients.
To increase usage of existing solutions, some tasks can be To increase usage of existing solutions, some tasks can be
identified, though how those map to actions for e.g. IETF/W3C is not identified, though how those map to actions for e.g. IETF/W3C is not
clear: clear:
o Improvements to the certificate system, such as CT. o Improvements to the certificate system, such as certificate
transparency (CT).
o Making it easier (cheaper, quicker) for system administrators to o Making it easier (cheaper, quicker) for system administrators to
deploy secure solutions. deploy secure solutions.
o Improve awareness of the risks. Identify which communities o Improve awareness of the risks. Identify which communities
influence which decisions and what is the appropriate message for influence which decisions and what is the appropriate message for
each. each.
o Provide an upgrade path that doesn't break existing systems or o Provide an upgrade path that doesn't break existing systems or
require that everybody upgrade at the same time. Opportunistic require that everybody upgrade at the same time. Opportunistic
skipping to change at page 10, line 17 skipping to change at page 9, line 46
It appears that the public in general demand more privacy and It appears that the public in general demand more privacy and
security (e.g., for their children) but are also pessimistic about security (e.g., for their children) but are also pessimistic about
getting that. They trust that somebody assures that nothing bad getting that. They trust that somebody assures that nothing bad
happens to them, but they also expect to be spied on all the time. happens to them, but they also expect to be spied on all the time.
(Perceived) threats of terrorism gave governments a reason to allow (Perceived) threats of terrorism gave governments a reason to allow
widespread surveillance, far beyond what may previously have been widespread surveillance, far beyond what may previously have been
considered dangerous for freedom. considered dangerous for freedom.
In this environment, the technical community will have a hard time In this environment, the technical community will have a hard time
developing and deploying technologies that fully counter PM. Which developing and deploying technologies that fully counter PM, which
means there has to be action in the social and political spheres, means there has to be action in the social and political spheres,
too. too.
Technology isn't the only thing that can make life harder for Technology isn't the only thing that can make life harder for
attackers. Government-sponsored PM is indirectly affected by trade attackers. Government-sponsored PM is indirectly affected by trade
agreements and treaties and thus it makes sense to lobby for those to agreements and treaties and thus it makes sense to lobby for those to
be as privacy-friendly as possible. be as privacy-friendly as possible.
Court cases on the grounds of human rights can also influence policy, Court cases on the grounds of human rights can also influence policy,
especially if they reach, for example, the European Court of Human especially if they reach, for example, the European Court of Human
Rights. Rights.
In medicine and law, it is common to have ethics committees, not so In medicine and law, it is common to have ethics committees, not so
in software. Should standards bodies such as IETF and W3C have an in software. Should standards bodies such as IETF and W3C have an
ethics committee? While standards such as the Geolocation API ethics committee? While Standards such as the Geolocation API
[w3c-geo-api] have gotten scrutiny from privacy experts, but only in [w3c-geo-api] have gotten scrutiny from privacy experts, but only in
an ad-hoc manner. (W3C has permanent groups to review standards for an ad-hoc manner. (W3C has permanent groups to review standards for
accessibility and internationalisation. It also has a Privacy group, accessibility and internationalisation. It also has a Privacy group,
but that currently doesn't do the same kind of systematic reviews.) but that currently doesn't do the same kind of systematic reviews.)
As the Internet Draft draft-barnes-pervasive-problem-00 (included as As the Internet Draft draft-barnes-pervasive-problem-00 (included as
paper 44 [8]) explains, PM doesn't just monitor the networks, but paper 44 [8]) explains, PM doesn't just monitor the networks, but
also attacks at the endpoints, turning organisations or people into also attacks at the endpoints, turning organisations or people into
(willing, unwilling, or unwitting) collaborators. One technical (willing, unwilling, or unwitting) collaborators. One technical
means of protection is thus to design protocols such that there are means of protection is thus to design protocols such that there are
skipping to change at page 11, line 13 skipping to change at page 10, line 42
(for Lawful Intercept), is outside the scope of this workshop. (for Lawful Intercept), is outside the scope of this workshop.
5.5. Improving the tools 5.5. Improving the tools
An earlier session discussed why existing COMSEC tools weren't used An earlier session discussed why existing COMSEC tools weren't used
more. This second session on COMSEC therefore discussed what more. This second session on COMSEC therefore discussed what
improvements and/or new tools were needed. improvements and/or new tools were needed.
Discussion at the workshop indicated that an important meta-tool for Discussion at the workshop indicated that an important meta-tool for
improving existing security technology could be Opportunistic improving existing security technology could be Opportunistic
Security (OS). [I-D.kent-opportunistic-security]. The idea is that Security (OS) [I-D.kent-opportunistic-security]. The idea is that
software is enhanced with a module that tries to encrypt software is enhanced with a module that tries to encrypt
communications when it detects that the other end also has the same communications when it detects that the other end also has the same
capablility but otherwise leaves the communication continue in the capablility but otherwise leaves the communication continue in the
old way. The detailed definition of OS is now being discussed by the old way. The detailed definition of OS is being discussed by the
IETF security area. [saag] IETF security area at the time of this workshop [saag].
OS would protect against a passive eavesdropper but should also allow OS would protect against a passive eavesdropper but should also allow
for endpoint authentication to protect against an active attacker (a for endpoint authentication to protect against an active attacker (a
MITM). As OS spreads, more and more communications would be MITM). As OS spreads, more and more communications would be
encrypted (and hopefully authenticated) and thus there is less and encrypted (and hopefully authenticated) and thus there is less and
less for an eavesdropper to collect. less for an eavesdropper to collect.
Of course, an implementation of OS could give a false sense of Of course, an implementation of OS could give a false sense of
security as well: some connections are encrypted, some are not. A security as well: some connections are encrypted, some are not. A
user might see something like a padlock icon in browsers, but there user might see something like a padlock icon in browsers, but there
skipping to change at page 11, line 42 skipping to change at page 11, line 23
There is also the possibility that a MITM intercepts the reply from a There is also the possibility that a MITM intercepts the reply from a
server that says "yes, I can do encryption" and removes it, causing server that says "yes, I can do encryption" and removes it, causing
the client to fall back to an unencrypted protocol. Mitigations the client to fall back to an unencrypted protocol. Mitigations
against this can be to have other channels of finding out a server's against this can be to have other channels of finding out a server's
capabilities and remembering that a server could do encryption capabilities and remembering that a server could do encryption
previously. previously.
There is also, again, a terminology problem. The technical There is also, again, a terminology problem. The technical
descriptions of OS talk about "silent fail" when a connection descriptions of OS talk about "silent fail" when a connection
couldn't be encrypted and has to fall back to the old, unencrypted couldn't be encrypted and has to fall back to the old, unencrypted
protocol. Actually, it's not a fail, it's no worse then it was protocol. Actually, it's not a fail; it's no worse than it was
before. A successful encryption would rather be a "silent before. A successful encryption would rather be a "silent
improvement." improvement."
That raises the question of the UI: How do you explain to a user what That raises the question of the UI: How do you explain to a user what
their security options are, and, in case an error occurs, how do you their security options are, and, in case an error occurs, how do you
explain the implications of the various responses? explain the implications of the various responses?
The people working on encryption are mathematicians and engineers, The people working on encryption are mathematicians and engineers,
and typically not the same people who know about UI. We need to and typically not the same people who know about UI. We need to
involve the experts. We also need to distinguish between usability involve the experts. We also need to distinguish between usability
skipping to change at page 12, line 27 skipping to change at page 12, line 11
choice, but it means he can't get his work done) or continue anyway choice, but it means he can't get his work done) or continue anyway
(there could be a MITM...). The server administrator, on the other (there could be a MITM...). The server administrator, on the other
hand, could actually solve the problem. hand, could actually solve the problem.
Encryption and authentication have a cost, in terms of setting them Encryption and authentication have a cost, in terms of setting them
up, but also in terms of the time it takes for software to do the up, but also in terms of the time it takes for software to do the
calculations. The set-up cost can be reduced with sensible defaults, calculations. The set-up cost can be reduced with sensible defaults,
predefined profiles and cut-and-paste configurations. And for some predefined profiles and cut-and-paste configurations. And for some
connections, authentication without encryption could be enough, in connections, authentication without encryption could be enough, in
the case that the data doesn't need to be kept secret, but it is the case that the data doesn't need to be kept secret, but it is
important to know that it is the real data. Most mail UAs already important to know that it is the real data. Most mail user agents
provide independent options for encryption and signing, but Web (UA) already provide independent options for encryption and signing,
servers only support authentication if the connection is also but Web servers only support authentication if the connection is also
encrypted. encrypted.
On the other hand, as e-mail also shows, it is difficult for users to On the other hand, as e-mail also shows, it is difficult for users to
understand what encryption and authentication do separately. understand what encryption and authentication do separately.
And it also has to be kept in mind that encrypting only the And it also has to be kept in mind that encrypting only the
"sensitive" data and not the rest decreases the cost for an attacker, "sensitive" data and not the rest decreases the cost for an attacker,
too: It becomes easy to know which connections are worth attacking. too: It becomes easy to know which connections are worth attacking.
Selective field confidentiality is also more prone to lead to Selective field confidentiality is also more prone to lead to
developer error, as not all developers will know the provenance of developer error, as not all developers will know the provenance of
values to be processed. values to be processed.
One problem with the TOFU model as used by SSH (see explanation One problem with the TOFU model as used by SSH (see explanation
above) is that it lacks a solution for key continuity: When a key is above) is that it lacks a solution for key continuity: When a key is
changed (which can happen e.g., when a server is replaced or the changed (which can happen, e.g., when a server is replaced or the
software upgraded), there is no way to inform the client. (In software upgraded), there is no way to inform the client. (In
practice, people use other means, such as calling people on the phone practice, people use other means, such as calling people on the phone
or asking their colleagues in the office, but that doesn't scale and or asking their colleagues in the office, but that doesn't scale and
doesn't always happen either.) An improvement in the SSH protocol doesn't always happen either.) An improvement in the SSH protocol
could thus be a way to transfer a new key to a client in a safe way. could thus be a way to transfer a new key to a client in a safe way.
5.6. Hiding metadata 5.6. Hiding metadata
Encryption and authentication help protect the content of messages. Encryption and authentication help protect the content of messages.
Correctly implemented encryption is very hard to crack. (To get the Correctly implemented encryption is very hard to crack. (To get the
skipping to change at page 13, line 28 skipping to change at page 13, line 9
It is useful to distinguish different kinds of metadata: explicit (or It is useful to distinguish different kinds of metadata: explicit (or
metadata proper) and implicit (sometimes called traffic data). metadata proper) and implicit (sometimes called traffic data).
Implicit metadata is things that can be derived from a message or are Implicit metadata is things that can be derived from a message or are
necessary for its delivery, such as the destination address, the necessary for its delivery, such as the destination address, the
size, the time, or the frequency with which messages pass. Explicit size, the time, or the frequency with which messages pass. Explicit
metadata is things like quality ratings, provenance or copyright metadata is things like quality ratings, provenance or copyright
data: data about the data, useful for an application, but not data: data about the data, useful for an application, but not
required to deliver the data to its endpoint. required to deliver the data to its endpoint.
A system like Tor hides much of the metadata by passing through A system such as Tor hides much of the metadata by passing through
several servers, encrypting all the data except that which a several servers, encrypting all the data except that which a
particular server needs to see. Each server thus knows which server particular server needs to see. Each server thus knows which server
a message came from and where he has to send it to, but cannot know a message came from and where he has to send it to, but cannot know
where the previous server got it from or where the next server is where the previous server got it from or where the next server is
instructed to send it. However, deliberately passing through instructed to send it. However, deliberately passing through
multiple servers makes the communication slower than taking the most multiple servers makes the communication slower than taking the most
direct route and increases the amount of traffic the network as a direct route and increases the amount of traffic the network as a
whole has to process. whole has to process.
There are three kinds of measures that can be taken to make metadata There are three kinds of measures that can be taken to make metadata
harder to get: aggregation, contraflow and multipath (see paper harder to get: aggregation, contraflow and multipath (see paper 4
4 [9]). New protocols should be designed such that these measures [9]). New protocols should be designed such that these measures are
are not inadvertently disallowed, e.g., because the design assumes not inadvertently disallowed, e.g., because the design assumes that
that the whole of a conversation passes through the same route. the whole of a conversation passes through the same route.
_Aggregation_ means collecting conversations from multiple sources "Aggregation" means collecting conversations from multiple sources
into one stream. E.g., if HTTP connections pass through a proxy, all into one stream. E.g., if HTTP connections pass through a proxy, all
the conversations appear to come from the proxy instead of from their the conversations appear to come from the proxy instead of from their
original sources. (This assumes that telltale information in the original sources. (This assumes that telltale information in the
headers is stripped by the proxy, or that the connection is headers is stripped by the proxy, or that the connection is
encrypted.) It also works in the other direction: if multiple Web encrypted.) It also works in the other direction: if multiple Web
sites are hosted on the same server, an attacker cannot see which of sites are hosted on the same server, an attacker cannot see which of
those Web sites a user is reading. (This assumes that the name of those Web sites a user is reading. (This assumes that the name of
the site is in the path info of the URL and not in the domain name, the site is in the path info of the URL and not in the domain name,
otherwise watching DNS queries can still reveal the name.) otherwise watching DNS queries can still reveal the name.)
_Contraflow_ means routing a conversation via one or more other "Contraflow" means routing a conversation via one or more other
servers than the normal route, e.g., by using a tunnel (e.g., with servers than the normal route, e.g., by using a tunnel (e.g., with
SSH or a VPN) to another server. Tor is an example of this. An SSH or a VPN) to another server. Tor is an example of this. An
attacker must watch more routes and do more effort to correlate attacker must watch more routes and do more effort to correlate
conversations. (Again, this assumes that there is no telltale conversations. (Again, this assumes that there is no telltale
information left in the messages that leave the tunnel.) information left in the messages that leave the tunnel.)
_Multipath_ splits up a single conversation (or a set of related "Multipath" splits up a single conversation (or a set of related
conversations) and routes the parts in different ways. E.g., send a conversations) and routes the parts in different ways. E.g., send a
request via a satellite link and receive the response via a land request via a satellite link and receive the response via a land
line; or starting a conversation on a cellular link and continuing it line; or starting a conversation on a cellular link and continuing it
via wifi. This again increases the cost for an attacker, who has to via Wi-Fi. This again increases the cost for an attacker, who has to
monitor and correlate multiple networks. monitor and correlate multiple networks.
Protecting metadata automatically with technology at a lower layer Protecting metadata automatically with technology at a lower layer
than the application layer is difficult. The applications themselves than the application layer is difficult. The applications themselves
need to pass less data, e.g., use anonymous temporary handles instead need to pass less data, e.g., use anonymous temporary handles instead
of permanent identifiers. There is often no real need for people to of permanent identifiers. There is often no real need for people to
use the same identifier on different computers (smartphone, desktop, use the same identifier on different computers (smartphone, desktop,
etc.) other than that the application they use was designed that way. etc.) other than that the application they use was designed that way.
One thing that can be done relatively easily in the short term is One thing that can be done relatively easily in the short term is to
going through existing protocols to check what data they send that go through existing protocols to check what data they send that isn't
isn't really necessary. One candidate mentioned for such a study was really necessary. One candidate mentioned for such a study was XMPP.
XMPP.
_Fingerprinting_ is the process of distinguishing different senders "Fingerprinting" is the process of distinguishing different senders
of messages based on metadata: Clients can be recognised (or at least of messages based on metadata: Clients can be recognised (or at least
grouped) because their messages always have a combination of features grouped) because their messages always have a combination of features
that other clients do not have. Reducing redundant metadata and that other clients do not have. Reducing redundant metadata and
reducing the number of optional features in a protocol reduces the reducing the number of optional features in a protocol reduces the
variation between clients and thus makes fingerprinting harder. variation between clients and thus makes fingerprinting harder.
Traffic analysis is a research discipline that produces sometimes Traffic analysis is a research discipline that produces sometimes
surprising findings, which are little known among protocol surprising findings, which are little known among protocol
developers. Some collections of results are developers. Some collections of results are
o A selected bibliography on anonymity [10] by the Free Haven o A selected bibliography on anonymity [10] by the Free Haven
Project Project,
o The yearly Symposium on Privacy Enhancing Technologies o The yearly Symposium on Privacy Enhancing Technologies (PETS)
(PETS). [11] [11], and
o The yearly Workshop on Privacy in the Electronic Society o The yearly Workshop on Privacy in the Electronic Society (WPES)
(WPES). [12] [12].
Techniques that deliberately change the timing or size of messages, Techniques that deliberately change the timing or size of messages,
such as padding, can also help reduce fingerprinting. Obviously, such as padding, can also help reduce fingerprinting. Obviously,
they make conversations slower and/or use more bandwidth, but in some they make conversations slower and/or use more bandwidth, but in some
cases that is not an issue, e.g., if the conversation is limited by cases that is not an issue, e.g., if the conversation is limited by
the speed of a human user anyway. HTTP/2 has a built-in padding the speed of a human user anyway. HTTP/2 has a built-in padding
mechanism. However, it is not so easy to use these techniques well, mechanism. However, it is not so easy to use these techniques well,
and not actually make messages easier to recognise rather than and not actually make messages easier to recognise rather than
harder. harder.
Different users in different contexts may have different security Different users in different contexts may have different security
needs, so maybe the priority can be a user choice. (If that can be needs, so maybe the priority can be a user choice (if that can be
done without making high-security users stand out from other users.) done without making high-security users stand out from other users).
Although many people would not understand what their choices are, Although many people would not understand what their choices are,
some do, such as political activists or journalists. some do, such as political activists or journalists.
5.7. Deployment, intermediaries and middleboxes 5.7. Deployment, intermediaries and middleboxes
Secure protocols have often been designed in the past for end-to-end Secure protocols have often been designed in the past for end-to-end
security: Intermediaries cannot read or modify the messages. This is security: Intermediaries cannot read or modify the messages. This is
the model behind TLS for example. the model behind TLS for example.
But in practice people have more or less valid reasons to insist on In practice, however, people have more or less valid reasons to
intermediaries: companies filtering incoming and outgoing traffic for insist on intermediaries: companies filtering incoming and outgoing
viruses or other reasons, giving priority to certain communications traffic for viruses or other reasons, giving priority to certain
or caching to reduce bandwidth. communications or caching to reduce bandwidth.
In the presence of end-to-end encryption and authentication, these In the presence of end-to-end encryption and authentication, these
intermediaries have two choices: using fake certificates to intermediaries have two choices: use fake certificates to impersonate
impersonate the endpoints or having access to the private keys of the the endpoints or have access to the private keys of the endpoints.
endpoints. The former is a MITM attack that is difficult to The former is a MITM attack that is difficult to distinguish from a
distinguish from a more malicious one, the latter obviously decreases more malicious one, and the latter obviously decreases the security
the security of the endpoints by copying supposedly protected data of the endpoints by copying supposedly protected data and
and concentrating such data in a single place. concentrating such data in a single place.
As mentioned in Section 5.2 above, aggregation of data in a single As mentioned in Section 5.2 above, aggregation of data in a single
place makes that place an attractive target. And in the case of PM place makes that place an attractive target. And in the case of PM
even if the data is not concentrated physically in one place, but is even if the data is not concentrated physically in one place, it is
under control of a single legal entity that can be made into a under control of a single legal entity that can be made into a
collaborator. collaborator.
The way Web communication with TLS typically works is that the client The way Web communication with TLS typically works is that the client
authenticates the server, but the server does not authenticate the authenticates the server, but the server does not authenticate the
client at the TLS layer. (If the client needs to be identified, that client at the TLS layer. (If the client needs to be identified, that
is mainly done at the application layer via passwords or cookies.) is mainly done at the application layer via passwords or cookies.)
Thus the presence of a MITM (middlebox) could be detected by the Thus the presence of a MITM (middlebox) could be detected by the
client (because of the incorrect certificate), but not by the server. client (because of the incorrect certificate), but not by the server.
If the client doesn't immediately close the connection, (which they If the client doesn't immediately close the connection (which they do
do not in many cases), the server may thus disclose information that not in many cases), the server may thus disclose information that the
the user would rather not have disclosed. user would rather not have disclosed.
One widespread example of middleboxes is captive portals, as found on One widespread example of middleboxes is captive portals, as found on
the wifi hotspots in hotels, airports, etc. Even the hotspots the Wi-Fi hotspots in hotels, airports, etc. Even the hotspots
offering free access often intercept communications to redirect the offering free access often intercept communications to redirect the
user to a login or policy page. user to a login or policy page.
When the communication they intercept is, e.g., the automatic update When the communication they intercept is, e.g., the automatic update
of your calendar program or a chat session, the redirect obviously of your calendar program or a chat session, the redirect obviously
doesn't work: these applications don't know how to display a Web doesn't work: these applications don't know how to display a Web
page. With the increasing use of apps, it may be a while before the page. With the increasing use of applications, it may be a while
user actually opens a browser. The flood of error messages may also before the user actually opens a browser. The flood of error
have as a result that the user no longer reads the errors, allowing messages may also have as a result that the user no longer reads the
an actual malicious attack to go unnoticed. errors, allowing an actual malicious attack to go unnoticed.
Some operating systems now come with heuristics that try to recognise Some operating systems now come with heuristics that try to recognise
captive portals and either automatically login or show their login captive portals and either automatically login or show their login
page in a separate application. (But some hotspot providers page in a separate application. (But some hotspot providers
apparently don't want automatic logins and actually reverse- apparently don't want automatic logins and actually reverse-
engineered the heuristics to try and fool them.) engineered the heuristics to try and fool them.)
It seems some protocol is missing in this case. Captive portals It seems some protocol is missing in this case. Captive portals
shouldn't have to do MITM attacks to be noticed. Maybe something shouldn't have to do MITM attacks to be noticed. something like an
like an extension to DHCP that tells a connecting device about the extension to DHCP that tells a connecting device about the login page
login page can help, although that still doesn't solve the problem may help, although that still doesn't solve the problem for devices
for devices that do not have a Web browser, such as game consoles or that do not have a Web browser, such as game consoles or SIP phones.
SIP phones. HTTP response code 511 (defined in [RFC6585]) is another HTTP response code 511 (defined in [RFC6585]) is another attempt at a
attempt at a solution. (Partial, because it can only work at the partial solution (Partial, because it can only work at the moment the
moment the user uses a browser to connect to a Web site and doesn't user uses a browser to connect to a Web site and doesn't use HTTPS).
use HTTPS.)
A practical problem with deployment of such a protocol may be that A practical problem with deployment of such a protocol may be that
many such captive portals are very old and never updated. The hotel many such captive portals are very old and never updated. The hotel
staff only knows how to reboot the system and as long as it works, staff only knows how to reboot the system and as long as it works,
the hotel has no incentive to buy a new one. As evidence of this: the hotel has no incentive to buy a new one. As evidence of this:
how many such systems require you to get a password and the ticket how many such systems require you to get a password and the ticket
shows the price as zero? This is typically because the owner doesn't shows the price as zero? This is typically because the owner doesn't
know how to reconfigure the hotspot, but he does know how to change know how to reconfigure the hotspot, but he does know how to change
the price in his cash register... the price in his cash register.
5.8. Break-out 1 - research 5.8. Break-out 1 - research
Despite some requests earlier in the workshop, the research break-out Despite some requests earlier in the workshop, the research break-out
did not discuss clean-slate approaches. The challenge was rather did not discuss clean-slate approaches. The challenge was rather
that the relation between security research and standardisation needs that the relationship between security research and standardisation
improvement. Research on linkability is not yet well known in the needs improvement. Research on linkability is not yet well known in
IETF. But the other side of the coin needs improvement too: While the IETF. But the other side of the coin needs improvement too:
doing protocol design, standardisation should indicate what specific While doing protocol design, standardisation should indicate what
problems are in need of more research. specific problems are in need of more research.
The break-out then made a non exclusive list of topics that are in The break-out then made a non-exclusive list of topics that are in
need of further research: need of further research:
o The interaction of compression and encryption as demonstrated by o The interaction of compression and encryption as demonstrated by
the CRIME SSL/TLS vulnerability [13] the CRIME SSL/TLS vulnerability [13]
o A more proactive deprecation of algorithms based on research o A more proactive deprecation of algorithms based on research
results. results
o Mitigation for return oriented programming attacks o Mitigation for return-oriented programming attacks
o How to better obfuscate so called "metadata", how to make the o How to better obfuscate so called "metadata"
existence of traffic and their endpoints stealthy
o How to make the existence of traffic and their endpoints stealthy
5.9. Break-out 2 - clients 5.9. Break-out 2 - clients
Browsers are the first clients one thinks of when talking about Browsers are the first clients one thinks of when talking about
encrypted connections, authentication and certificates, but there are encrypted connections, authentication and certificates, but there are
many others. many others.
Another common case of "false" alarms for MITM (after captive Other common case of "false" alarms for MITM (after captive portals)
portals) is expired and mis-configured certificates. This is quite include expired and mis-configured certificates. This is quite
common in intranets, when the sysadmin hasn't bothered updating a common in intranets, when the sysadmin hasn't bothered updating a
certificate and rather tells his handful of users to just "click certificate and rather tells his handful of users to just "click
continue." The problem is on the one hand that users may not continue." The problem is on the one hand that users may not
understand the difference between this case and the same error understand the difference between this case and the same error
message when they connect to a server outside the company, and on the message when they connect to a server outside the company, and on the
other hand that the incorrect certificate installed by the sysadmin other hand that the incorrect certificate installed by the sysadmin
is not easily distinguishable from an incorrect certificate from a is not easily distinguishable from an incorrect certificate from a
MITM. The error message is almost the same and the user may just MITM. The error message is almost the same and the user may just
click continue again. click continue again.
skipping to change at page 18, line 7 skipping to change at page 17, line 40
with this certificate. with this certificate.
Yet another source of error messages is self-signed certificates. Yet another source of error messages is self-signed certificates.
Such certificates are actually only errors for sites that are not Such certificates are actually only errors for sites that are not
expected to have them. If a message about a self-signed certificate expected to have them. If a message about a self-signed certificate
appears when connecting to Facebook or Google, you're clearly not appears when connecting to Facebook or Google, you're clearly not
connected to the real Facebook or Google. But for a personal Website connected to the real Facebook or Google. But for a personal Website
it shouldn't cause such scary warnings. There may be ways to improve it shouldn't cause such scary warnings. There may be ways to improve
the explanations in the error message and provide an easy way to the explanations in the error message and provide an easy way to
verify the certificate (by e-mail, over the phone or some other verify the certificate (by e-mail, over the phone or some other
channel) and import it. channel) and trust it.
5.10. Break-out 3 - on by default 5.10. Break-out 3 - on by default
One step in improving security is to require the relevant features, One step in improving security is to require the relevant features,
in particular encryption and authentication, to be implemented in in particular encryption and authentication, to be implemented in
compliant products: The features are labelled as MUST in the standard compliant products: The features are labelled as MUST in the standard
rather than MAY. This is sometimes referred to as MTI, Mandatory To rather than MAY. This is sometimes referred to as Mandatory To
Implement and is the current practice for IETF protocols. [RFC3365] Implement (MTI) and is the current practice for IETF
protocols[RFC3365].
But that may not be enough to counter PM. It may be that the But that may not be enough to counter PM. It may be that the
features are there, but not used, because only very knowledgeable features are there, but not used, because only very knowledgeable
users or sysadmins turn them on. Or it may be that implementations users or sysadmins turn them on. Or it may be that implementations
do not actually follow the MTI parts of specifications. Or it may be do not actually follow the MTI parts of specifications. Or it may be
that some security features are implemented but interoperability for that some security features are implemented but interoperability for
those doesn't really work. Or, even worse, it may be that protocol those doesn't really work. Or, even worse, it may be that protocol
designers have only followed the letter of the MTI best practice and designers have only followed the letter of the MTI best practice and
not its spirit, with the result that security features are hard to not its spirit, with the result that security features are hard to
use or make deployment harder. One can thus argue that such features use or make deployment harder. One can thus argue that such features
should be defined to be on by default. should be defined to be on by default.
Going further one might argue that these features should not even be Going further one might argue that these features should not even be
options, i.e., there should be no way to turn them off. This is options, i.e., there should be no way to turn them off. This is
sometimes called MTU, Mandatory To Use. sometimes called Mandatory To Use (MTU).
The question raised at this session was for what protocols on-by- The question raised at this session was for what protocols on-by-
default is appropriate, and how to explain to the developers of such default is appropriate, and how can one explain to the developers of
protocols that it is needed? such protocols that it is needed?
There would of course be resistance to MTU security from implemeters There would of course be resistance to MTU security from implemeters
and deployments that practice deep packet inspection (DPI) and also and deployments that practice deep packet inspection (DPI) and also
perhaps from some governments. On the other hand, there may also be perhaps from some governments. On the other hand, there may also be
governments that outlaw protocols _without_ proper encryption. governments that outlaw protocols without proper encryption.
This break-out concluded that there could be value in attempting to This break-out concluded that there could be value in attempting to
document a new Best Current Practice for the IETF that moves from the document a new Best Current Practice for the IETF that moves from the
current MTI position to one where security features are on-by- current MTI position to one where security features are on-by-
default. Some of the workshop participants expressed interest in default. Some of the workshop participants expressed interest in
authoring a draft for such a new BCP and progressing that through the authoring a draft for such a new BCP and progressing that through the
IETF consensus process. (Where it would no doubt be controversial.) IETF consensus process (where it would no doubt be controversial).
5.11. Break-out 4 - measurement 5.11. Break-out 4 - measurement
There was a small break-out on the idea of measurement as a way to There was a small break-out on the idea of measurement as a way to
encourage or gamify the increased use of security mechanisms. [[We encourage or gamify the increased use of security mechanisms.
don't currently have notes from that.]]
5.12. Break-out 5 - opportunistic 5.12. Break-out 5 - opportunistic
This break out considered the use of the term "opportunistic" as it This break out considered the use of the term "opportunistic" as it
applies to crytpgraphic security and attempted to progress the work applies to crytographic security and attempted to progress the work
towards arriving at an agreed definition for use of that term, at it towards arriving at an agreed-upon definition for use of that term,
applies to IETF and W3C work. at it applies to IETF and W3C work.
While various terms had been used, with many people talking about While various terms had been used, with many people talking about
opportunistic encryption, that usage was felt to be problematic both opportunistic encryption, that usage was felt to be problematic both
because it conflicted with the use of the same term in [RFC4322] and because it conflicted with the use of the same term in [RFC4322] and
because it was being used differently in different parts of the because it was being used differently in different parts of the
community. community.
At the session it was felt that the term "opportunistic keying" was At the session it was felt that the term "opportunistic keying" was
better, but as explained above subsequent list discussion resulted in better, but as explained above subsequent list discussion resulted in
a move to the term "Opportunistic Security" (OS). a move to the term "Opportunistic Security" (OS).
skipping to change at page 19, line 34 skipping to change at page 19, line 20
Hellman (D-H) key exchange as the preferred mechanism of OS, with Hellman (D-H) key exchange as the preferred mechanism of OS, with
fall back to cleartext if D-H doesn't succeed as a counter for fall back to cleartext if D-H doesn't succeed as a counter for
passive attacks. passive attacks.
There was also of course the desire to be able to easily escalate There was also of course the desire to be able to easily escalate
from countering passive attacks to also handling endpoint from countering passive attacks to also handling endpoint
authentication and thereby also countering MITM attacks. authentication and thereby also countering MITM attacks.
Making OS visible to users was again considered to be undesirable, as Making OS visible to users was again considered to be undesirable, as
users could not be expected to distinguish between cleartext, OS and users could not be expected to distinguish between cleartext, OS and
(one-sided or mutal) endpoint authentication. (one-sided or mutual) endpoint authentication.
Finally, it was noted that it may take some effort to establish how Finally, it was noted that it may take some effort to establish how
middleboxes might affect OS at different layers and that OS really is middleboxes might affect OS at different layers and that OS really is
not suitable as the only migitation to use for high-sensitivity not suitable as the only migitation to use for high-sensitivity
sessions such as financial transactions. sessions such as financial transactions.
5.13. Unofficial Transport/Routing Break-out 5.13. Unofficial Transport/Routing Break-out
Some routing and transport area directors felt a little left out by Some routing and transport area directors felt a little left out by
all the application layer break-outs:-) So they had their own all the application layer break-outs, so they had their own
brainstorm about what could be done at the Transport and Routing brainstorm about what could be done at the Transport and Routing
layers from which these notes resulted. layers from which these notes resulted.
The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer
service that is reordering and delay insensitive. Use of LDEBAT service that is reordering and delay insensitive. Use of LDEBAT
could offer the following benefits for an application: could offer the following benefits for an application:
a. Because it is reordering insensitive, traffic can be sprayed a. Because it is reordering-insensitive, traffic can be sprayed
across a large number of forwarding paths. Assuming such across a large number of forwarding paths. Assuming such
different paths exist, this would make it more challenging to different paths exist, this would make it more challenging to
capture and analyze a full interaction. capture and analyze a full interaction.
b. The application can vary the paths by indicating per packet a b. The application can vary the paths by indicating per packet a
different microflow. In IPv6, this can be done via different different flow. In IPv6, this can be done via different IPv6
IPv6 flow labels. For IPv4, this can be done by encapsulating flow labels. For IPv4, this can be done by encapsulating the IP
the IP packet into UDP and varying the UDP src port. packet into UDP and varying the UDP source port.
c. Since LEDBAT is delay insensitive and applications using it would c. Since LEDBAT is delay-insensitive and applications using it would
need to be as well, it would be possible to obfuscate the need to be as well, it would be possible to obfuscate the
application signatures by varying the packet lengths and application signatures by varying the packet lengths and
frequency. frequency.
d. This can also hide the transport header (for IP in UDP). d. This can also hide the transport header (for IP in UDP).
e. If we could fix the reverse SPF check problem, perhaps the source e. If the Reverse Path Forwarding(RPF)[RFC3704] check problem can be
could be hidden - but that has assumptions on trusted perimeters. fixed, perhaps the source could be hidden, however it assumes the
trafic is within trusted perimeters.
f. The use of LEDBAT is orthogonal to the use of encryption and f. The use of LEDBAT is orthogonal to the use of encryption and
provides different benefits (harder to intercept the whole provides different benefits (harder to intercept the whole
conversation, ability to obfuscate the traffic analysis), and conversation, ability to obfuscate the traffic analysis), and
also has different costs (longer latency, new transport protocol also has different costs (longer latency, new transport protocol
usage) to its users. usage) to its users.
We also discussed the idea of encrypting traffic from CE to CE as The idea of encrypting traffic from customer edge (CE) to CE as part
part of a L3VPN or such. This could allow hiding of addresses, of an L3VPN or such was also discussed. This could allow hiding of
including source, and headers. From my further conversation with Ron addresses, including source, and headers. From conversation with Ron
Bonica, some customers already do encryption (though not hiding the Bonica, some customers already do encryption (though not hiding the
source address) like this. So, I'm not sure this is very practically source address) like this. So, it is unclear that this is very
useful as an enhancement except for encouraging deployment and use. practically useful as an enhancement except for encouraging
deployment and use.
Finally, we discussed whether it would be useful to have a means of Finally, it was discussed whether it would be useful to have a means
communicating where and what layers are doing encryption on an of communicating where and what layers are doing encryption on an
application's traffic path. The initial idea of augmenting ICMP has application's traffic path. The initial idea of augmenting ICMP has
some issues (not visible to application, ICMP packets frequently some issues (not visible to application, ICMP packets frequently
filtered) as well as potential work (determining how to trust the filtered) as well as potential work (determining how to trust the
report of encryption). It would be interesting to understand if such report of encryption). It would be interesting to understand if such
communication is actually needed and what the requirements would be. communication is actually needed and what the requirements would be.
6. After the workshop 6. After the workshop
Holding the workshop just before the IETF had the intended effect: a Holding the workshop just before the IETF had the intended effect: a
number of people went to both the workshop and the IETF. And they number of people went to both the workshop and the IETF, and they
took the opportunity of being together at the IETF to continue the took the opportunity of being together at the IETF to continue the
discussions. discussions.
Working groups of the IETF who met in London took the recommendations IETF Working groups meeting in London took the recommendations from
from the workshop into account. It was even the first item in the the workshop into account. It was even the first item in the report
report about the IETF meeting by the IETF chair, Jari Arkko: about the IETF meeting by the IETF chair, Jari Arkko:
_"Strengthening the security and privacy of the Internet continued "Strengthening the security and privacy of the Internet continued
to draw a lot of attention. The STRINT workshop organised by the to draw a lot of attention. The STRINT workshop organised by the
IAB and W3C just before the IETF attracted 100 participants and IAB and W3C just before the IETF attracted 100 participants and
over 60 papers. Even more people would have joined us, but there over 60 papers. Even more people would have joined us, but there
was no space. During the IETF meeting, we continued discussing was no space. During the IETF meeting, we continued discussing
the topic at various working groups. A while ago we created the the topic at various working groups. A while ago we created the
first working group specifically aimed at addressing some of the first working group specifically aimed at addressing some of the
issues surrounding pervasive monitoring. The Using TLS for issues surrounding pervasive monitoring. The Using TLS for
Applications (UTA) working group had its first meeting in London. Applications (UTA) working group had its first meeting in London.
But many other working groups also address these issues in their But many other working groups also address these issues in their
own work. The TCPM working group discussed a proposal to add own work. The TCPM working group discussed a proposal to add
opportunistic keying mechanisms directly onto the TCP protocol. opportunistic keying mechanisms directly onto the TCP protocol.
And the DNSE BOF considered the possibility of adding And the DNSE BOF considered the possibility of adding
confidentiality support to DNS queries. Finally, there is an confidentiality support to DNS queries. Finally, there is an
ongoing effort to review old specifications to search for areas ongoing effort to review old specifications to search for areas
that might benefit from taking privacy and data minimisation that might benefit from taking privacy and data minimisation
better into account."_ - [Arkko1] better into account."[Arkko1]
Two papers that were written for the workshop, but not finished in Two papers that were written for the workshop, but not finished in
time, are worth mentioning, too: One by the same Jari Arkko, titled time, are worth mentioning, too: One by the same Jari Arkko, titled
"Privacy and Networking Functions" [Arkko2]; and one by Johan "Privacy and Networking Functions" [Arkko2]; and one by Johan
Pouwelse, "The Shadow Internet: liberation from Surveillance, Pouwelse, "The Shadow Internet: liberation from Surveillance,
Censorship and Servers" [draft-pouwelse-perpass-shadow-internet] Censorship and Servers" [draft-pouwelse-perpass-shadow-internet]
7. IANA considerations 7. IANA considerations
There are none. We hope the RFC editor deletes this section. There are none. We hope the RFC editor deletes this section.
8. Security considerations 8. Security considerations
This document does not define a technology but is all about security This document does not define a technology but is all about security
and privacy. and privacy.
Plenary. 9. References
(C) Stonehouse Photographic [14]
9. Informative references 9.1. Informative references
[Arkko1] Arkko, J., "IETF-89 Summary", March 2014, [Arkko1] Arkko, J., "IETF-89 Summary", March 2014,
<http://www.ietf.org/blog/2014/03/ietf-89-summary/>. <http://www.ietf.org/blog/2014/03/ietf-89-summary/>.
[Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014, [Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014,
<http://www.arkko.com/ietf/strint/ <http://www.arkko.com/ietf/strint/
draft-arkko-strint-networking-functions.txt>. draft-arkko-strint-networking-functions.txt>.
(Work in progress.) (Work in progress.)
[draft-ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", February 2014.
(Work in progress.)
[draft-pouwelse-perpass-shadow-internet]
Pouwelse, J., Ed., "The Shadow Internet: liberation from
Surveillance, Censorship and Servers", February 2014,
<https://datatracker.ietf.org/doc/draft-pouwelse-perpass-
shadow-internet/>.
(Work in progress.)
[I-D.barnes-pervasive-problem] [I-D.barnes-pervasive-problem]
Barnes, R., Schneier, B., Jennings, C., and T. Hardie, Barnes, R., Schneier, B., Jennings, C., and T. Hardie,
"Pervasive Attack: A Threat Model and Problem Statement", "Pervasive Attack: A Threat Model and Problem Statement",
draft-barnes-pervasive-problem-00 (work in progress), draft-barnes-pervasive-problem-01 (work in progress), July
January 2014. 2014.
[I-D.farrell-perpass-attack]
Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an
Attack", draft-farrell-perpass-attack-06 (work in
progress), February 2014.
[I-D.kent-opportunistic-security] [I-D.kent-opportunistic-security]
Kent, S., "Opportunistic Security as a Countermeasure to Kent, S., "Opportunistic Security as a Countermeasure to
Pervasive Monitoring", Pervasive Monitoring", draft-kent-opportunistic-
draft-kent-opportunistic-security-01 (work in progress), security-01 (work in progress), April 2014.
April 2014.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, Engineering Task Force Standard Protocols", BCP 61, RFC
RFC 3365, August 2002. 3365, August 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552, July
July 2003. 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)", Encryption using the Internet Key Exchange (IKE)", RFC
RFC 4322, December 2005. 4322, December 2005.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012. Codes", RFC 6585, April 2012.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012. December 2012.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013. Transparency", RFC 6962, June 2013.
[draft-ietf-websec-key-pinning] [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Attack", BCP 188, RFC 7258, May 2014.
Extension for HTTP", February 2014.
(Work in progress.)
[draft-pouwelse-perpass-shadow-internet]
Pouwelse, J., Ed., "The Shadow Internet: liberation from
Surveillance, Censorship and Servers", February 2014, <htt
ps://datatracker.ietf.org/doc/
draft-pouwelse-perpass-shadow-internet/>.
(Work in progress.) [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, December 2014.
[saag] Area, S., "IETF Security Area mailing list", March 2014, < [saag] Area, S., "IETF Security Area mailing list", March 2014,
https://www.ietf.org/mail-archive/web/saag/current/ <https://www.ietf.org/mail-archive/web/saag/current/
maillist.html>. maillist.html>.
[vancouverplenary] [vancouverplenary]
IETF, "IETF 88 Technical Plenary Minutes", <http:// IETF, , "IETF 88 Technical Plenary Minutes",
www.ietf.org/proceedings/88/minutes/ <http://www.ietf.org/proceedings/88/minutes/
minutes-88-iab-techplenary>. minutes-88-iab-techplenary>.
[w3c-geo-api] [w3c-geo-api]
Popescu, A., "Geolocation API Specification", Popescu, A., "Geolocation API Specification", October
October 2013, <http://www.w3.org/TR/geolocation-API/>. 2013, <http://www.w3.org/TR/geolocation-API/>.
[1] <http://www.w3.org/> 9.2. URIs
[2] <https://www.iab.org/> [1] http://www.w3.org/
[3] <https://www.w3.org/2014/strint/Overview.html> [2] https://www.iab.org/
[4] <https://www.ietf.org/meeting/89/index.html> [3] https://www.w3.org/2014/strint/Overview.html
[5] <http://www.strews.eu/> [4] https://www.ietf.org/meeting/89/index.html
[6] <https://en.wikipedia.org/wiki/Captive_portal> [5] http://www.strews.eu/
[7] <http://tools.ietf.org/html/bcp72> [6] https://en.wikipedia.org/wiki/Captive_portal
[8] <https://www.w3.org/2014/strint/papers/44.pdf> [7] http://tools.ietf.org/html/bcp72
[9] <https://www.w3.org/2014/strint/papers/04.pdf> [8] https://www.w3.org/2014/strint/papers/44.pdf
[10] <http://freehaven.net/anonbib/> [9] https://www.w3.org/2014/strint/papers/04.pdf
[11] <http://www.informatik.uni-trier.de/~Ley/db/conf/pet/ [10] http://freehaven.net/anonbib/
index.html>
[12] <http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/ [11] http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html
index.html>
[13] <https://community.qualys.com/blogs/securitylabs/2012/09/14/ [12] http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html
crime -information-leakage-attack-against-ssltls>
[14] <http://www.stonehousephotographic.com/> [13] https://community.qualys.com/blogs/securitylabs/2012/09/14/crime
-information-leakage-attack-against-ssltls
[15] <http://cordis.europa.eu/fp7/ict/> [14] http://www.strews.eu/
[16] <http://blog.digital.telefonica.com/> [15] http://cordis.europa.eu/fp7/ict/
[17] <http://lists.i1b.org/pipermail/strint-attendees-i1b.org/> [16] http://blog.digital.telefonica.com/
[18] <https://twitter.com/search?q=%23strint> [17] https://www.ietf.org/meeting/89/index.html
[19] <http://www.w3.org/2014/02/28-strint-minutes.html> [18] http://lists.i1b.org/pipermail/strint-attendees-i1b.org/
[20] <http://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf> [19] https://twitter.com/search?q=%23strint
[21] <http://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf> [20] http://www.w3.org/2014/02/28-strint-minutes.html
[22] <http://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf> [21] http://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf
[23] <http://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf> [22] http://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf
[24] <http://www.w3.org/2014/03/01-strint-minutes.html> [23] http://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf
[25] <http://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf> [24] http://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf
[26] <http://down.dsg.cs.tcd.ie/strint-slides/ [25] http://www.w3.org/2014/03/01-strint-minutes.html
s5-1metadata-pironti.pdf>
[27] <http://down.dsg.cs.tcd.ie/strint-slides/ [26] http://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf
s5-2metadata-hardie.pdf>
[28] <http://down.dsg.cs.tcd.ie/strint-slides/ [27] http://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf
s5-3metadata-cooper.pdf>
[29] <http://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf> [28] http://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf
[30] <https://www.w3.org/2014/strint/slides/summary.pdf> [29] http://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf
[31] <https://strint.pads.ccc.de/1> [30] http://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf
[32] <https://www.w3.org/2014/strint/papers/01.pdf> [31] https://www.w3.org/2014/strint/slides/summary.pdf
[33] <https://www.w3.org/2014/strint/papers/02.pdf> [32] https://strint.pads.ccc.de/1
[34] <https://www.w3.org/2014/strint/papers/03.pdf> [33] https://www.w3.org/2014/strint/papers/01.pdf
[35] <https://www.w3.org/2014/strint/papers/05.pdf> [34] https://www.w3.org/2014/strint/papers/02.pdf
[36] <https://www.w3.org/2014/strint/papers/06.pdf> [35] https://www.w3.org/2014/strint/papers/03.pdf
[37] <http://www.internetsociety.org/blog/tech-matters/2014/02/ [36] https://www.w3.org/2014/strint/papers/04.pdf
danger-new-internet-choke-points>
[38] <http://www.circleid.com/posts/ [37] https://www.w3.org/2014/strint/papers/05.pdf
20140218_mind_the_step_function_are_we_really_less_secure_than_
a_year_ago/>
[39] <https://www.w3.org/2014/strint/papers/07.pdf> [38] https://www.w3.org/2014/strint/papers/06.pdf
[40] <https://www.w3.org/2014/strint/papers/08.pdf> [39] http://www.internetsociety.org/blog/tech-matters/2014/02/danger-
new-internet-choke-points
[41] <https://www.w3.org/2014/strint/papers/09.pdf> [40] http://www.circleid.com/posts/20140218_mind_the_step_function_ar
e_we_really_less_secure_than_a_year_ago/
[42] <https://www.w3.org/2014/strint/papers/10.pdf> [41] https://www.w3.org/2014/strint/papers/07.pdf
[43] <https://www.w3.org/2014/strint/papers/11.pdf> [42] https://www.w3.org/2014/strint/papers/08.pdf
[44] <https://www.w3.org/2014/strint/papers/12.pdf> [43] https://www.w3.org/2014/strint/papers/09.pdf
[45] <https://www.w3.org/2014/strint/papers/13.pdf> [44] https://www.w3.org/2014/strint/papers/10.pdf
[46] <https://www.w3.org/2014/strint/papers/14.pdf> [45] https://www.w3.org/2014/strint/papers/11.pdf
[47] <https://www.w3.org/2014/strint/papers/15.pdf> [46] https://www.w3.org/2014/strint/papers/12.pdf
[48] <https://www.w3.org/2014/strint/papers/17.pdf> [47] https://www.w3.org/2014/strint/papers/13.pdf
[49] <https://www.w3.org/2014/strint/papers/19.pdf> [48] https://www.w3.org/2014/strint/papers/14.pdf
[50] <https://www.w3.org/2014/strint/papers/20.pdf> [49] https://www.w3.org/2014/strint/papers/15.pdf
[51] <https://www.w3.org/2014/strint/papers/21.pdf> [50] https://www.w3.org/2014/strint/papers/17.pdf
[52] <https://www.w3.org/2014/strint/papers/22.pdf> [51] https://www.w3.org/2014/strint/papers/19.pdf
[53] <https://www.w3.org/2014/strint/papers/23.pdf> [52] https://www.w3.org/2014/strint/papers/20.pdf
[54] <https://www.w3.org/2014/strint/papers/24.pdf> [53] https://www.w3.org/2014/strint/papers/21.pdf
[55] <https://www.w3.org/2014/strint/papers/25.pdf> [54] https://www.w3.org/2014/strint/papers/22.pdf
[56] <https://www.w3.org/2014/strint/papers/26.pdf> [55] https://www.w3.org/2014/strint/papers/23.pdf
[57] <https://www.w3.org/2014/strint/papers/27.pdf> [56] https://www.w3.org/2014/strint/papers/24.pdf
[58] <https://www.w3.org/2014/strint/papers/28.pdf> [57] https://www.w3.org/2014/strint/papers/25.pdf
[59] <https://www.w3.org/2014/strint/papers/30.pdf> [58] https://www.w3.org/2014/strint/papers/26.pdf
[60] <https://www.w3.org/2014/strint/papers/31.pdf> [59] https://www.w3.org/2014/strint/papers/27.pdf
[61] <https://www.w3.org/2014/strint/papers/32.pdf> [60] https://www.w3.org/2014/strint/papers/28.pdf
[62] <https://www.w3.org/2014/strint/papers/33.pdf> [61] https://www.w3.org/2014/strint/papers/30.pdf
[63] <https://www.w3.org/2014/strint/papers/34.pdf> [62] https://www.w3.org/2014/strint/papers/31.pdf
[64] <https://www.w3.org/2014/strint/papers/35.pdf> [63] https://www.w3.org/2014/strint/papers/32.pdf
[65] <https://www.w3.org/2014/strint/papers/36.pdf> [64] https://www.w3.org/2014/strint/papers/33.pdf
[66] <https://www.w3.org/2014/strint/papers/37.pdf> [65] https://www.w3.org/2014/strint/papers/34.pdf
[67] <https://www.w3.org/2014/strint/papers/38.pdf> [66] https://www.w3.org/2014/strint/papers/35.pdf
[68] <https://www.w3.org/2014/strint/papers/39.pdf> [67] https://www.w3.org/2014/strint/papers/36.pdf
[69] <https://www.w3.org/2014/strint/papers/40.pdf> [68] https://www.w3.org/2014/strint/papers/37.pdf
[70] <https://www.w3.org/2014/strint/papers/41.pdf> [69] https://www.w3.org/2014/strint/papers/38.pdf
[71] <https://www.w3.org/2014/strint/papers/42.pdf> [70] https://www.w3.org/2014/strint/papers/39.pdf
[72] <https://www.w3.org/2014/strint/papers/43.pdf> [71] https://www.w3.org/2014/strint/papers/40.pdf
[73] <https://www.w3.org/2014/strint/papers/45.pdf> [72] https://www.w3.org/2014/strint/papers/41.pdf
[74] <https://www.w3.org/2014/strint/papers/46.pdf> [74] https://www.w3.org/2014/strint/papers/42.pdf
[75] <https://www.w3.org/2014/strint/papers/47.pdf> [75] https://www.w3.org/2014/strint/papers/43.pdf
[76] <https://www.w3.org/2014/strint/papers/48.pdf> [76] https://www.w3.org/2014/strint/papers/44.pdf
[77] <https://www.w3.org/2014/strint/papers/49.pdf> [77] https://www.w3.org/2014/strint/papers/45.pdf
[78] <https://www.w3.org/2014/strint/papers/50.pdf> [78] https://www.w3.org/2014/strint/papers/46.pdf
[79] <https://www.w3.org/2014/strint/papers/51.pdf> [79] https://www.w3.org/2014/strint/papers/47.pdf
[80] <https://www.w3.org/2014/strint/papers/52.pdf> [80] https://www.w3.org/2014/strint/papers/48.pdf
[81] <https://www.w3.org/2014/strint/papers/53.pdf> [81] https://www.w3.org/2014/strint/papers/49.pdf
[82] <https://www.w3.org/2014/strint/papers/54.pdf> [82] https://www.w3.org/2014/strint/papers/50.pdf
[83] <https://www.w3.org/2014/strint/papers/55.pdf> [83] https://www.w3.org/2014/strint/papers/51.pdf
[84] <https://www.w3.org/2014/strint/papers/56.pdf> [84] https://www.w3.org/2014/strint/papers/52.pdf
[85] <https://www.w3.org/2014/strint/papers/57.pdf> [85] https://www.w3.org/2014/strint/papers/53.pdf
[86] <https://www.w3.org/2014/strint/papers/58.pdf> [86] https://www.w3.org/2014/strint/papers/54.pdf
[87] <https://www.w3.org/2014/strint/papers/59.pdf> [87] https://www.w3.org/2014/strint/papers/55.pdf
[88] <https://www.w3.org/2014/strint/papers/60.pdf> [88] https://www.w3.org/2014/strint/papers/56.pdf
[89] <https://www.w3.org/2014/strint/papers/61.pdf> [89] https://www.w3.org/2014/strint/papers/57.pdf
[90] <https://www.w3.org/2014/strint/papers/62.pdf> [90] https://www.w3.org/2014/strint/papers/58.pdf
[91] <https://www.w3.org/2014/strint/papers/63.pdf> [91] https://www.w3.org/2014/strint/papers/59.pdf
[92] <https://www.w3.org/2014/strint/papers/64.pdf> [92] https://www.w3.org/2014/strint/papers/60.pdf
[93] <https://www.w3.org/2014/strint/papers/65.pdf> [93] https://www.w3.org/2014/strint/papers/61.pdf
[94] <https://www.w3.org/2014/strint/papers/66.pdf> [94] https://www.w3.org/2014/strint/papers/62.pdf
[95] <https://www.cs.tcd.ie/Stephen.Farrell/> [95] https://www.w3.org/2014/strint/papers/63.pdf
[96] <http://www.w3.org/People/Rigo/> [96] https://www.w3.org/2014/strint/papers/64.pdf
[97] <http://www.tschofenig.priv.at/wp/?page_id=5> [97] https://www.w3.org/2014/strint/papers/65.pdf
[98] https://www.w3.org/2014/strint/papers/66.pdf
[99] https://www.cs.tcd.ie/Stephen.Farrell/
[100] http://www.w3.org/People/Rigo/
[101] http://www.tschofenig.priv.at/wp/?page_id=5
Appendix A. Logistics Appendix A. Logistics
The workshop was organised by the STREWS [5] project (a research The workshop was organised by the STREWS [14] project (a research
project funded under the European Union's 7th Framework project funded under the European Union's 7th Framework Programme
Programme [15]), as the first of two workshops in its work plan. The [15]), as the first of two workshops in its work plan. The
organisers were supported by the IAB and W3C, and, for the local organisers were supported by the IAB and W3C, and, for the local
organisation, by Telefonica Digital. [16] organisation, by Telefonica Digital. [16]
One of the suggestions in the project description of the STREWS One of the suggestions in the project description of the STREWS
project was to attach the first workshop to an IETF meeting. The project was to attach the first workshop to an IETF meeting. The
best opportunity was IETF 89 [4] in London, which would begin on best opportunity was IETF 89 [17] in London, which would begin on
Sunday March 2, 2014. Telefonica Digital offered meeting rooms at Sunday March 2, 2014. Telefonica Digital offered meeting rooms at
its offices in central London for the preceding Friday and Saturday, its offices in central London for the preceding Friday and Saturday,
just minutes away from the IETF's location. just minutes away from the IETF's location.
The room held 100 people, which was thought to be sufficient. There The room held 100 people, which was thought to be sufficient. There
turned out to be more interest than expected and we could have filled turned out to be more interest than expected and we could have filled
a larger room, but 100 people is probably an upper limit for good a larger room, but 100 people is probably an upper limit for good
discussions anyway. discussions anyway.
Apart from the usual equipment in the room (projector, white boards, Apart from the usual equipment in the room (projector, white boards,
microphones, coffee...), we also set up some extra communication microphones, coffee...), we also set up some extra communication
channels: channels:
o A mailing list where participants could discuss the agenda and the o A mailing list where participants could discuss the agenda and the
published papers about three weeks in advance of the workshop published papers about three weeks in advance of the workshop
itself. (Only participants were allowed to write to the mailing itself. (Only participants were allowed to write to the mailing
list, but the archive [17] is public.) list, but the archive [18] is public.)
o Publicly advertised streaming audio (one-way only). At some o Publicly advertised streaming audio (one-way only). At some
point, no less than 165 people were listening. point, no less than 165 people were listening.
o An IRC channel for live minute taking, passing links and other o An IRC channel for live minute taking, passing links and other
information, and as a help for remote participants to follow the information, and as a help for remote participants to follow the
proceedings. proceedings.
o An Etherpad, where the authors of papers could provide an abstract o An Etherpad, where the authors of papers could provide an abstract
of their submissions, to help participants who could not read all of their submissions, to help participants who could not read all
66 papers in full in advance of the workshop. (The abstracts were 66 papers in full in advance of the workshop. (The abstracts were
also used on the workshop's Web site and are reproduced in this also used on the workshop's Web site and are reproduced in this
report (Appendix C).) report (Appendix C).)
o A "Twitter hashtag" (#strint). Four weeks after the workshop, o A "Twitter hashtag" (#strint). Four weeks after the workshop,
there were still a few new messages [18] about events related to there were still a few new messages [19] about events related to
workshop topics. workshop topics.
Appendix B. Agenda Appendix B. Agenda
This was the final agenda of the workshop, as determined by the TPC This was the final agenda of the workshop, as determined by the TPC
and participants on the mailing list prior to the workshop. The and participants on the mailing list prior to the workshop. The
included links are to the slides that the moderators used to included links are to the slides that the moderators used to
introduce each discussion topic and to the minutes. introduce each discussion topic and to the minutes.
B.1. Friday 28 February B.1. Friday 28 February
(minutes [19]) Minutes [20]
13:00 Registration, Coffee, play with n/w, power, find seat
14:00 Workshop starts, welcome, logistics, opening/overview Workshop starts, welcome, logistics, opening/overview [slides]
[slides] [20] [21]
* Goal is to plan how we respond to PM threats * Goal is to plan how we respond to PM threats
* Specific questions to be discussed in sessions * Specific questions to be discussed in sessions
* Outcomes are actions for IETF, W3C, IRTF, etc. * Outcomes are actions for IETF, W3C, IRTF, etc.
14:30 I. Threats - What problem are we trying to solve? (Presenter: I. Threats - What problem are we trying to solve? (Presenter:
Richard Barnes; Moderator: Cullen Jennings) [slides] [21] Richard Barnes; Moderator: Cullen Jennings) [slides] [22]
* What attacks have been described? (Attack taxonomy) * What attacks have been described? (Attack taxonomy)
* What should we assume the attackers' capabilities are? * What should we assume the attackers' capabilities are?
* When is it really "pervasive monitoring" and when is it not? * When is it really "pervasive monitoring" and when is it not?
* Scoping - what's in and what's out? (for IETF/W3C) * Scoping - what's in and what's out? (for IETF/W3C)
15:30 Break II. COMSEC 1 - How can we increase usage of current COMSEC tools?
(Presenter: Hannes Tschofenig; Moderator: Leif Johansson) [slides]
16:00 II. COMSEC 1 - How can we increase usage of current COMSEC [23]
tools? (Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
[slides] [22]
* Whirlwind catalog of current tools * Whirlwind catalog of current tools
* Why aren't people using them? In what situations are / aren't * Why aren't people using them? In what situations are / aren't
they used? they used?
* Securing AAA and management protocols - why not? * Securing AAA and management protocols - why not?
* How can we (IETF/W3C/community) encourage more/better use? * How can we (IETF/W3C/community) encourage more/better use?
17:30 Break III. Policy - What policy / legal/ other issues need to be taken
into account? (Presenter: Christine Runnegar; Moderator: Rigo
Wenning) [slides] [24]
17:45 III. Policy - What policy / legal/ other issues need to be
taken into account? (Presenter: Christine Runnegar; Moderator:
Rigo Wenning) [slides] [23]
* What non-technical activities do we need to be aware of? * What non-technical activities do we need to be aware of?
* How might such non-technical activities impact on IETF/W3C? * How might such non-technical activities impact on IETF/W3C?
* How might IETF/W3C activities impact on those non-technical * How might IETF/W3C activities impact on those non-technical
activities? activities?
18:30 Session IV - Saturday plan, open-mic, wrap up day Session IV - Saturday plan, open-mic, wrap up day
19:00 Social event
Break out.
(C) Stonehouse Photographic [14]
B.2. Saturday 1 March B.2. Saturday 1 March
(minutes [24]) Minutes [25]
09:00 Welcome again, logistics
09:15 IV. COMSEC 2 - What improvements to COMSEC tools are IV. COMSEC 2 - What improvements to COMSEC tools are
needed?(Presenter: Mark Nottingham; Moderator: Steve Bellovin) needed?(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
[slides] [25] [slides] [26]
* Opportunistic encryption - what is it and where it might apply * Opportunistic encryption - what is it and where it might apply
* Mitigations aiming to block PM vs. detect PM - when to try * Mitigations aiming to block PM vs. detect PM - when to try
which? which?
10:30 Break V. Metadata - How can we reduce the metadata that protocols
expose? (Presenter: Alfredo Pironti [slides] [27] / Ted Hardie
10:45 V. Metadata - How can we reduce the metadata that protocols [slides] [28]; Moderator: Alissa Cooper [slides] [29])
expose? (Presenter: Alfredo Pironti [slides] [26] / Ted Hardie
[slides] [27]; Moderator: Alissa Cooper [slides] [28])
* Meta-data, fingerprinting, minimisation * Meta-data, fingerprinting, minimisation
* What's out there? * What's out there?
* How can we do better? * How can we do better?
12:00 Lunch (Buffet) VI. Deployment - How can we address PM in deployment /
13:00 VI. Deployment - How can we address PM in deployment /
operations? (Presenter: Eliot Lear; Moderator: Barry Leiba) operations? (Presenter: Eliot Lear; Moderator: Barry Leiba)
[slides] [29] [slides] [30]
* "Mega"-commercial services (clouds, large scale email & SN, * "Mega"-commercial services (clouds, large scale email & SN,
SIP, WebRTC...) SIP, WebRTC...)
* Target dispersal - good goal or wishful thinking? * Target dispersal - good goal or wishful thinking?
* Middleboxes: when a help and when a hindrance? * Middleboxes: when a help and when a hindrance?
14:30 Break VII. 3 x Break-out Sessions / Bar-Camp style (Hannes Tschofenig)
15:00 VII. 3 x Break-out Sessions / Bar-Camp style (Hannes
Tschofenig)
* Content to be defined during meeting, as topics come up * Content to be defined during meeting, as topics come up
* Sum up at the end to gather conclusions for report * Sum up at the end to gather conclusions for report
15:00 Break-outs: Break-outs:
1. Research Questions (Moderator: Kenny Paterson) 1. Research Questions (Moderator: Kenny Paterson)
+ Do we need more/different crypto tools? + Do we need more/different crypto tools?
+ How can applications make better use of COMSEC tools? + How can applications make better use of COMSEC tools?
+ What research topics could be handled in IRTF? + What research topics could be handled in IRTF?
+ What other research would help? + What other research would help?
skipping to change at page 31, line 37 skipping to change at page 31, line 4
+ What research topics could be handled in IRTF? + What research topics could be handled in IRTF?
+ What other research would help? + What other research would help?
2. clients 2. clients
3. on by default 3. on by default
4. measuring 4. measuring
5. opportunistic 5. opportunistic
16:15 VIII. Break-out reports, Open mic & Conclusions - What are we VIII. Break-out reports, Open mic & Conclusions - What are we
going to do to address PM? [slides] [30] going to do to address PM? [slides] [31]
* Gather conclusions / recommendations / goals from earlier * Gather conclusions / recommendations / goals from earlier
sessions sessions
17:15 End
Whiteboard notes.
(C) Stonehouse Photographic [14]
Appendix C. The submitted papers Appendix C. The submitted papers
[[sort-papers: Group the papers by (rough) topic? --Bert]]
The following papers were submitted to the workshop. The abstracts The following papers were submitted to the workshop. The abstracts
were provided by the authors themselves. (We set up an editable page were provided by the authors themselves. (We set up an editable page
("Etherpad") [31] where the authors could insert them.) ("Etherpad") [32] where the authors could insert them.)
C.1. Privacy Protected Email - Phillip Hallam-Baker C.1. Privacy Protected Email - Phillip Hallam-Baker
01.pdf [32] - This proposal is two things: First it shows that with 01.pdf [33] - This proposal is two things: First it shows that with
some small adjustments to S/MIME and PGP we can merge two competing some small adjustments to S/MIME and PGP we can merge two competing
end-to-end security proposals that are too hard for people to use end-to-end security proposals that are too hard for people to use
into one scheme that provides a useful degree of security with no into one scheme that provides a useful degree of security with no
thought from the user. In cases where the user has security concerns thought from the user. In cases where the user has security concerns
they can easily determine that they are met. The second part of the they can easily determine that they are met. The second part of the
proposal is that it the Trust set deployed to secure email encryption proposal is that it the Trust set deployed to secure email encryption
can be leveraged to solve pretty much every other end-to-end security can be leveraged to solve pretty much every other end-to-end security
requirement. If people generate keys for their email we can secure requirement. If people generate keys for their email we can secure
chat, video, 2-factor authentication as well. chat, video, 2-factor authentication as well.
C.2. Opportunistic Encryption for MPLS - Stephen Farrell, Adrian C.2. Opportunistic Encryption for MPLS - Stephen Farrell, Adrian
Farrrell Farrrell
02.pdf [33] - This is an early proposal for a way to do open-channel 02.pdf [34] - This is an early proposal for a way to do open-channel
D-H key agreement and encryption in MPLS. Two things are maybe D-H key agreement and encryption in MPLS. Two things are maybe
interesting: a) its an example of trying to add confidentiality to an interesting: a) its an example of trying to add confidentiality to an
existing protocol with making PM harder as a specific goal and b) existing protocol with making PM harder as a specific goal and b)
maybe it shows that there could be a benefit in a generic protocol maybe it shows that there could be a benefit in a generic protocol
for after-the-fact MITM detection for such cases. It'd probably be for after-the-fact MITM detection for such cases. It'd probably be
most interesting to discuss (a) as one example of something we want most interesting to discuss (a) as one example of something we want
to do more generally and not the specifics of MPLS at the workshop; to do more generally and not the specifics of MPLS at the workshop;
and I'd be interested in whether or not (b) is tractable (I'm not and I'd be interested in whether or not (b) is tractable (I'm not
sure). sure).
C.3. Overcoming the Friend-or-Foe Paradigm in Secure Communication - C.3. Overcoming the Friend-or-Foe Paradigm in Secure Communication -
Sebastian Gajek, Jan Seedorf, Marc Fischlin, Oezguer Dagdalen Sebastian Gajek, Jan Seedorf, Marc Fischlin, Oezguer Dagdalen
03.pdf [34] - Essentially, our point is that with the existing end- 03.pdf [35] - Essentially, our point is that with the existing end-
to-end client-server security paradigm, e.g. as instantiated in TLS, to-end client-server security paradigm, e.g. as instantiated in TLS,
the "good guys" often actually have to mount attacks in order for the "good guys" often actually have to mount attacks in order for
middleboxes (which are on the path between client ans server being middleboxes (which are on the path between client ans server being
able) to perform their job. The good guys are thus technically able) to perform their job. The good guys are thus technically
indistinguishable from the bad guys. indistinguishable from the bad guys.
Concretely, we are proposing to extend TLS in a way that would allow Concretely, we are proposing to extend TLS in a way that would allow
authorized modification of certain, dedicated parts of the TLS authorized modification of certain, dedicated parts of the TLS
payload by middleboxes, while still allowing for integrity payload by middleboxes, while still allowing for integrity
verification by clients. The crypto for such "Interferable Secure verification by clients. The crypto for such "Interferable Secure
Communication" exists and we think it is feasible to extend TLS in Communication" exists and we think it is feasible to extend TLS in
this way in a reasonable timeframe. this way in a reasonable timeframe.
C.4. Flows and Pervasive Monitoring - Ted Hardie C.4. Flows and Pervasive Monitoring - Ted Hardie
04.pdf [9] - This document describes methods that may hinder a 04.pdf [36] - This document describes methods that may hinder a
pervasive monitor's efforts to derive metadata from flows. There are pervasive monitor's efforts to derive metadata from flows. There are
three main methods discussed in the paper: aggregation, contraflow, three main methods discussed in the paper: aggregation, contraflow,
and multipath. These are largely side-effects of other efforts at and multipath. These are largely side-effects of other efforts at
this time, but the paper discusses how they might fit into the design this time, but the paper discusses how they might fit into the design
space of efforts intended to combat pervasive monitoring and the space of efforts intended to combat pervasive monitoring and the
related consequences for network operations. related consequences for network operations.
C.5. BetterCrypto.org Applied Crypto Hardening - Aaron Zauner, L. Aaron C.5. BetterCrypto.org Applied Crypto Hardening - Aaron Zauner, L.
Kaplan Aaron Kaplan
05.pdf [35] - BetterCrypto is a community-driven project where 05.pdf [37] - BetterCrypto is a community-driven project where
admins, engineers, cryptographers, security researchers alike admins, engineers, cryptographers, security researchers alike
participate in finding well researched best-practices for commonly participate in finding well researched best-practices for commonly
deployed networked applications and infrastructure. We try to deployed networked applications and infrastructure. We try to
outline a proper interim solution until better protocols and outline a proper interim solution until better protocols and
standards are widely deployed. Our hope is that we can contribute to standards are widely deployed. Our hope is that we can contribute to
a safer internet for all and better understanding of cryptographic a safer internet for all and better understanding of cryptographic
primitives for the operations community that needs to deploy sound primitives for the operations community that needs to deploy sound
security on the public internet. Our focus group: sysadmins / ops. security on the public internet. Our focus group: sysadmins / ops.
C.6. A Complimentary Analysis (The Danger Of The New Internet Choke C.6. A Complimentary Analysis (The Danger Of The New Internet Choke
Points) - Andrei Robachevsky, Christine Runnegar, Karen Points) - Andrei Robachevsky, Christine Runnegar, Karen
O'Donoghue, Mat Ford O'Donoghue, Mat Ford
06.pdf [36] - The ongoing disclosures of pervasive surveillance of 06.pdf [38] - The ongoing disclosures of pervasive surveillance of
Internet users' communications and data by national signals Internet users' communications and data by national signals
intelligence agencies have prompted protocol designers, software and intelligence agencies have prompted protocol designers, software and
hardware vendors, as well as Internet service and content providers, hardware vendors, as well as Internet service and content providers,
to re-evaluate prevailing security and privacy threat models and to to re-evaluate prevailing security and privacy threat models and to
refocus on providing more effective security and confidentiality. At refocus on providing more effective security and confidentiality. At
IETF88, there was consensus to address pervasive monitoring as an IETF88, there was consensus to address pervasive monitoring as an
attack and to consider the pervasive attack threat model when attack and to consider the pervasive attack threat model when
designing a protocol. In this paper, we offer a complimentary designing a protocol. In this paper, we offer a complimentary
analysis. We identify some of the components of the Internet analysis. We identify some of the components of the Internet
architecture that provide attractive opportunities for wholesale architecture that provide attractive opportunities for wholesale
monitoring and/or interception, and, therefore, represent monitoring and/or interception, and, therefore, represent
architectural vulnerabilities, or choke points. We also suggest architectural vulnerabilities, or choke points. We also suggest
possible mitigation strategies and pose some of the questions that possible mitigation strategies and pose some of the questions that
need to be considered if the Internet is to evolve to reduce such need to be considered if the Internet is to evolve to reduce such
vulnerabilities. Finally, we identify some significant areas of vulnerabilities. Finally, we identify some significant areas of
tension or trade-offs, and we consider possible areas for additional tension or trade-offs, and we consider possible areas for additional
efforts. Also: danger-new-internet-choke-points [37] and efforts. Also: danger-new-internet-choke-points [39] and
mind_the_step_function [38] mind_the_step_function [40]
C.7. Trust Issues with Opportunistic Encryption - Scott Rose, Stephen C.7. Trust Issues with Opportunistic Encryption - Scott Rose, Stephen
Nightingale, Doug Montgomery Nightingale, Doug Montgomery
07.pdf [39] - "Once is happenstance. Twice is coincidence. Three 07.pdf [41] - "Once is happenstance. Twice is coincidence. Three
times is enemy action" times is enemy action"
The lack of authentication in opportunistic encryption could have the The lack of authentication in opportunistic encryption could have the
perverse affect of putting more end users at risk: thinking that they perverse affect of putting more end users at risk: thinking that they
are "secure", an end user may divulge private information to an are "secure", an end user may divulge private information to an
imposter instead of the service they believe they have contacted. imposter instead of the service they believe they have contacted.
When adding protection mechanisms to protocols, designers and When adding protection mechanisms to protocols, designers and
implementers should not downplay the importance of authentication in implementers should not downplay the importance of authentication in
order to make opportunistic encryption easier to deploy. We advocate order to make opportunistic encryption easier to deploy. We advocate
that while opportunistic encryption can solve one set of problems, that while opportunistic encryption can solve one set of problems,
authentication is often desired by end users. authentication is often desired by end users.
C.8. Challenges with End-to-End Email Encryption - Jiangshan Yu, C.8. Challenges with End-to-End Email Encryption - Jiangshan Yu,
Vincent Cheval, Mark Ryan Vincent Cheval, Mark Ryan
08.pdf [40] - In this paper we show how the use of an extended 08.pdf [42] - In this paper we show how the use of an extended
certificate transparency can build a secure end-to-end email or certificate transparency can build a secure end-to-end email or
messaging system using PKI without requiring trusted parties nor messaging system using PKI without requiring trusted parties nor
complex p2p key-signing arrangements such as PGP. This makes end-to- complex p2p key-signing arrangements such as PGP. This makes end-to-
end encrypted mail possible, and users do not need to understand or end encrypted mail possible, and users do not need to understand or
concern themselves with keys or certificates. In addition, we concern themselves with keys or certificates. In addition, we
briefly present some related concerns i.e. metadata protection, key briefly present some related concerns i.e. metadata protection, key
loss mitigation, spam detection, and the security of webmail. loss mitigation, spam detection, and the security of webmail.
C.9. Strengthening the path and strengthening the end-points - Xavier C.9. Strengthening the path and strengthening the end-points - Xavier
Marjou, Emile Stephan, Jean-Michel Combes, Iuniana Oprescu Marjou, Emile Stephan, Jean-Michel Combes, Iuniana Oprescu
09.pdf [41] - Internet data is more and more subject to pervasive 09.pdf [43] - Internet data is more and more subject to pervasive
monitoring. This paper investigates ways of enhancing this situation monitoring. This paper investigates ways of enhancing this situation
depending on where such pervasive monitoring may occur. There are depending on where such pervasive monitoring may occur. There are
two different locations to secure: the endpoints and the path between two different locations to secure: the endpoints and the path between
these endpoints. In the present document, we also emphasize the fact these endpoints. In the present document, we also emphasize the fact
that encryption, although bringing additional data confidentiality, that encryption, although bringing additional data confidentiality,
might in some cases contradict security's two other pillars, which might in some cases contradict security's two other pillars, which
are availability and integrity. are availability and integrity.
C.10. SIP is Difficult - Jon Peterson C.10. SIP is Difficult - Jon Peterson
10.pdf [42] - While SIP is widely used as a protocol for real-time 10.pdf [44] - While SIP is widely used as a protocol for real-time
communications, it is very difficult to secure from pervasive communications, it is very difficult to secure from pervasive
monitoring. In fact, one could argue that SIP's susceptibility to monitoring. In fact, one could argue that SIP's susceptibility to
mass surveillance was essential to its success in the marketplace. mass surveillance was essential to its success in the marketplace.
This paper shows why SIP's design left the door open for This paper shows why SIP's design left the door open for
eavesdropping, and what lessons RTCWeb could learn from this. eavesdropping, and what lessons RTCWeb could learn from this.
C.11. Thoughts of Strengthening Network Devices in the Face of C.11. Thoughts of Strengthening Network Devices in the Face of
Pervasive Surveillance - Dacheng Zhang, Fuyou Miao Pervasive Surveillance - Dacheng Zhang, Fuyou Miao
11.pdf [43] - The material released by Edward Snowden has raised 11.pdf [45] - The material released by Edward Snowden has raised
serious concerns about pervasive surveillance. People worry that serious concerns about pervasive surveillance. People worry that
their privacy is not properly protected when they are using the their privacy is not properly protected when they are using the
Internet. Network product vendors also encounter the doubts on the Internet. Network product vendors also encounter the doubts on the
security of their products (e.g., routers, switches, firewalls). security of their products (e.g., routers, switches, firewalls).
Such doubts are seriously damaging the Internet ecosystem. In this Such doubts are seriously damaging the Internet ecosystem. In this
paper we try to analyze the affects brought by the Snowden scandal on paper we try to analyze the affects brought by the Snowden scandal on
our ability to trust products at the core of the Internet and discuss our ability to trust products at the core of the Internet and discuss
what the standard organization can do to help vendors address these what the standard organization can do to help vendors address these
security concerns. security concerns.
C.12. Opportunistic Encryption for HTTP URIs - Mark Nottingham C.12. Opportunistic Encryption for HTTP URIs - Mark Nottingham
12.pdf [44] - This is a proposed method for using TLS with http:// 12.pdf [46] - This is a proposed method for using TLS with http://
URIs under discussion in the HTTPbis WG, in particular for HTTP/2 but URIs under discussion in the HTTPbis WG, in particular for HTTP/2 but
also applicable to HTTP/1. One of the biggest decisions to make is also applicable to HTTP/1. One of the biggest decisions to make is
whether or not to require the certs to validate in this scenario. whether or not to require the certs to validate in this scenario.
C.13. Cyberdefense-Oriented Multilayer Threat Analysis - Yuji Sekiya, C.13. Cyberdefense-Oriented Multilayer Threat Analysis - Yuji Sekiya,
Daisuke Miyamoto, Hajime Tazaki Daisuke Miyamoto, Hajime Tazaki
13.pdf [45] 13.pdf [47]
C.14. A Threat Model for Pervasive Passive Surveillance - Brian C.14. A Threat Model for Pervasive Passive Surveillance - Brian
Trammell, Daniel Borkmann, Christian Huitema Trammell, Daniel Borkmann, Christian Huitema
14.pdf [46] - This document elaborates a threat model for pervasive 14.pdf [48] - This document elaborates a threat model for pervasive
surveillance, assuming an adversary with an interest in surveillance, assuming an adversary with an interest in
indiscriminate eavesdropping that can passively observe network indiscriminate eavesdropping that can passively observe network
traffic at every layer at every point in the network between the traffic at every layer at every point in the network between the
endpoints. We provide guidelines on evaluating the observability and endpoints. We provide guidelines on evaluating the observability and
inferability of information and metainformation radiated from inferability of information and metainformation radiated from
Internet protocols. The central message to protocol designers: Internet protocols. The central message to protocol designers:
pervasive encryption for confidentiality, protocol and implementation pervasive encryption for confidentiality, protocol and implementation
design for simplicity and auditability, flexibility to allow design for simplicity and auditability, flexibility to allow
fingerprinting resistance, and moving away from static identifiers fingerprinting resistance, and moving away from static identifiers
can increase protocol-level resistance to pervasive surveillance. can increase protocol-level resistance to pervasive surveillance.
C.15. Why Provable Transparency is Useful Against Surveillance - Ben C.15. Why Provable Transparency is Useful Against Surveillance - Ben
Laurie Laurie
15.pdf [47] 15.pdf [49]
C.16. Withheld C.16. Withheld
C.17. Monitoring message size to break privacy - Current issues and C.17. Monitoring message size to break privacy - Current issues and
proposed solutions - Alfredo Pironti proposed solutions - Alfredo Pironti
17.pdf [48] - One of the Internet traffic features that can be easily 17.pdf [50] - One of the Internet traffic features that can be easily
collected by passive pervasive monitoring is the size of the collected by passive pervasive monitoring is the size of the
exchanged messages, or the total bandwidth used by a conversation. exchanged messages, or the total bandwidth used by a conversation.
Several works have showed that careful analysis of this data can Several works have showed that careful analysis of this data can
break users' expected privacy, even for encrypted traffic. Despite break users' expected privacy, even for encrypted traffic. Despite
this, little has been done in practice to hide message sizes, perhaps this, little has been done in practice to hide message sizes, perhaps
because deemed too inefficient or not a realistic threat. because deemed too inefficient or not a realistic threat.
In this short paper, we contextualize message size analysis in the In this short paper, we contextualize message size analysis in the
wider pervasive monitoring scenario, which encompasses other powerful wider pervasive monitoring scenario, which encompasses other powerful
analysis techniques, and we re-state the severity of the privacy analysis techniques, and we re-state the severity of the privacy
breach that message size analysis constitutes. We finally discuss breach that message size analysis constitutes. We finally discuss
proposals to fix this issue, considering practical aspects such as proposals to fix this issue, considering practical aspects such as
required developer awareness, ease of deployment, efficiency, and required developer awareness, ease of deployment, efficiency, and
interaction with other countermeasures. interaction with other countermeasures.
C.18. Withheld C.18. Withheld
C.19. Making The Internet Secure By Default - Michael H. Behringer, Max C.19. Making The Internet Secure By Default - Michael H. Behringer,
Pritkin, Steinthor Bjarnason Max Pritkin, Steinthor Bjarnason
19.pdf [49] - Pervasive monitoring on the Internet is enabled by the 19.pdf [51] - Pervasive monitoring on the Internet is enabled by the
lack of general, fundamental security. In his presentation at the lack of general, fundamental security. In his presentation at the
88th IETF Bruce Schneier called for ubiquitous use of security 88th IETF Bruce Schneier called for ubiquitous use of security
technologies to make pervasive monitoring too expensive and thus technologies to make pervasive monitoring too expensive and thus
impractical. However, today security is too operationally expensive, impractical. However, today security is too operationally expensive,
and thus only used where strictly required. In this position paper and thus only used where strictly required. In this position paper
we argue that all network transactions can be secure by default, with we argue that all network transactions can be secure by default, with
minimal or no operator involvement. This requires an autonomic minimal or no operator involvement. This requires an autonomic
approach where all devices in a domain enrol automatically in a trust approach where all devices in a domain enrol automatically in a trust
domain. Once they share a common trust anchor they can secure domain. Once they share a common trust anchor they can secure
communications between themselves, following a domain policy which is communications between themselves, following a domain policy which is
by default secure. The focus of this proposal is the network itself, by default secure. The focus of this proposal is the network itself,
with all protocols between network elements, including control plane with all protocols between network elements, including control plane
protocols (e.g., routing protocols) and management plane protocols protocols (e.g., routing protocols) and management plane protocols
(e.g., SSH, netconf, etc). The proposal is evolutionary and allows a (e.g., SSH, netconf, etc). The proposal is evolutionary and allows a
smooth migration from today's Internet technology, device by device. smooth migration from today's Internet technology, device by device.
C.20. Increasing HTTP Transport Confidentiality with TLS Based C.20. Increasing HTTP Transport Confidentiality with TLS Based
Alternate Services - Patrick McManus Alternate Services - Patrick McManus
20.pdf [50] 20.pdf [52]
C.21. Balance - Societal security versus individual liberty - Scott C.21. Balance - Societal security versus individual liberty - Scott
Cadzow Cadzow
21.pdf [51] 21.pdf [53]
C.22. Strengthening the Extensible Messaging and Presence Protocol C.22. Strengthening the Extensible Messaging and Presence Protocol
(XMPP) - Peter Saint-Andre (XMPP) - Peter Saint-Andre
22.pdf [52] - This document describes existing and potential future 22.pdf [54] - This document describes existing and potential future
efforts at strengthening the Extensible Messaging and Presence efforts at strengthening the Extensible Messaging and Presence
Protocol (XMPP), for discussion at the W3C/IAB workshop on Protocol (XMPP), for discussion at the W3C/IAB workshop on
Strengthening the Internet Against Pervasive Monitoring (STRINT). Strengthening the Internet Against Pervasive Monitoring (STRINT).
C.23. The Internet We Want or the Internet We Deserve? - David Rogers C.23. The Internet We Want or the Internet We Deserve? - David Rogers
23.pdf [53] 23.pdf [55]
C.24. Beyond Encrypt Everything: Passive Monitoring - Mark Donnelly, C.24. Beyond Encrypt Everything: Passive Monitoring - Mark Donnelly,
Sam Hartman Sam Hartman
24.pdf [54] 24.pdf [56]
C.25. Examining Proxies to Mitigate Pervasive Surveillance - Eliot C.25. Examining Proxies to Mitigate Pervasive Surveillance - Eliot
Lear, Barbara Fraser Lear, Barbara Fraser
25.pdf [55] - The notion of pervasive surveillance assumes that it is 25.pdf [57] - The notion of pervasive surveillance assumes that it is
possible for an attacker to have access to all links and devices possible for an attacker to have access to all links and devices
between end points, as well as end points themselves. We examine between end points, as well as end points themselves. We examine
this threat is some detail with an eye toward whether trusted this threat is some detail with an eye toward whether trusted
intermediaries can provide relief from the attack. We go on to intermediaries can provide relief from the attack. We go on to
examine the costs associated with the various remediation methods. examine the costs associated with the various remediation methods.
In at least one case, we challenge the notion that one should encrypt In at least one case, we challenge the notion that one should encrypt
absolutely everything in all cases, as was implied in at least one absolutely everything in all cases, as was implied in at least one
threat analysis. Finally we summarize in a set of four principles threat analysis. Finally we summarize in a set of four principles
that should be considered in future work. that should be considered in future work.
C.26. Spontaneous Wireless Networking to Counter Pervasive Monitoring - C.26. Spontaneous Wireless Networking to Counter Pervasive Monitoring -
Emmanuel Baccelli, Oliver Hahm, Matthias Waehlisch Emmanuel Baccelli, Oliver Hahm, Matthias Waehlisch
26.pdf [56] - Several approaches can be employed to counter pervasive 26.pdf [58] - Several approaches can be employed to counter pervasive
monitoring at large scale on the Internet. One category of monitoring at large scale on the Internet. One category of
approaches aims to harden the current Internet architecture and to approaches aims to harden the current Internet architecture and to
increase the security of high profile targets (data centers, exchange increase the security of high profile targets (data centers, exchange
points etc.). Another category of approaches aims instead for target points etc.). Another category of approaches aims instead for target
dispersal, i.e. disabling systematic mass surveillance via the dispersal, i.e. disabling systematic mass surveillance via the
elimination of existing vantage points, thus forcing surveillance elimination of existing vantage points, thus forcing surveillance
efforts to be more specific and personalized. This paper argues how efforts to be more specific and personalized. This paper argues how
networking approaches that do not rely on central entities - but networking approaches that do not rely on central entities - but
rather on spontaneous interaction, as locally as possible, between rather on spontaneous interaction, as locally as possible, between
autonomous peer entities - can help realize target dispersal and thus autonomous peer entities - can help realize target dispersal and thus
counter pervasive monitoring. counter pervasive monitoring.
C.27. Is Opportunistic Encryption the Answer? Practical Benefits and C.27. Is Opportunistic Encryption the Answer? Practical Benefits and
Disadvantages - John Mattsson Disadvantages - John Mattsson
27.pdf [57] - In this paper, we give an overview of various 27.pdf [59] - In this paper, we give an overview of various
opportunistic and unauthenticated encryption techniques, and discuss opportunistic and unauthenticated encryption techniques, and discuss
their benefits, limits, and disadvantages. We recommend the Internet their benefits, limits, and disadvantages. We recommend the Internet
community to clearly define the term "opportunistic encryption" or to community to clearly define the term "opportunistic encryption" or to
use other terms. We conclude that while opportunistic and use other terms. We conclude that while opportunistic and
unauthenticated encryption certainly has its uses and may with the unauthenticated encryption certainly has its uses and may with the
right choices provide good enough security for a low cost, general right choices provide good enough security for a low cost, general
deployment of unauthenticated encryption is not an effective way to deployment of unauthenticated encryption is not an effective way to
thwart pervasive monitoring. thwart pervasive monitoring.
C.28. Clearing off the Cloud over the Internet of Things - Carsten C.28. Clearing off the Cloud over the Internet of Things - Carsten
Bormann, Stefanie Gerdes, Olaf Bergmann Bormann, Stefanie Gerdes, Olaf Bergmann
28.pdf [58] - As was foreshadowed by product introductions in 2013, 28.pdf [60] - As was foreshadowed by product introductions in 2013,
the Consumer Electronics Show 2014 has seen the introduction of a the Consumer Electronics Show 2014 has seen the introduction of a
large number of "Internet of Things" (IoT) innovations. Almost all large number of "Internet of Things" (IoT) innovations. Almost all
of these have in common that they are meant to operate via Cloud- of these have in common that they are meant to operate via Cloud-
based services. In the light of the recent attention to threats by based services. In the light of the recent attention to threats by
state-level tenacious attackers with significant infrastructure state-level tenacious attackers with significant infrastructure
(STASI), in particular to their practice of pervasive monitoring, we (STASI), in particular to their practice of pervasive monitoring, we
discuss the implications of a cloud-centric IoT landscape, and discuss the implications of a cloud-centric IoT landscape, and
attempt to outline a set of principles as a program to improve the attempt to outline a set of principles as a program to improve the
long-term outlook. long-term outlook.
skipping to change at page 38, line 43 skipping to change at page 38, line 4
large number of "Internet of Things" (IoT) innovations. Almost all large number of "Internet of Things" (IoT) innovations. Almost all
of these have in common that they are meant to operate via Cloud- of these have in common that they are meant to operate via Cloud-
based services. In the light of the recent attention to threats by based services. In the light of the recent attention to threats by
state-level tenacious attackers with significant infrastructure state-level tenacious attackers with significant infrastructure
(STASI), in particular to their practice of pervasive monitoring, we (STASI), in particular to their practice of pervasive monitoring, we
discuss the implications of a cloud-centric IoT landscape, and discuss the implications of a cloud-centric IoT landscape, and
attempt to outline a set of principles as a program to improve the attempt to outline a set of principles as a program to improve the
long-term outlook. long-term outlook.
C.29. Withheld C.29. Withheld
C.30. The Trust-to-Trust Model of Cloud Services - Alissa Cooper, C.30. The Trust-to-Trust Model of Cloud Services - Alissa Cooper,
Cullen Jennings Cullen Jennings
30.pdf [59] 30.pdf [61]
C.31. Linkability Considered Harmful - Leif Johansson C.31. Linkability Considered Harmful - Leif Johansson
31.pdf [60] - Current debate on pervasive monitoring often focus on 31.pdf [62] - Current debate on pervasive monitoring often focus on
passive attacks on the protocol and transport layers but even if passive attacks on the protocol and transport layers but even if
these issues were eliminated through the judicious use of encryption, these issues were eliminated through the judicious use of encryption,
roughly the same information would still be available to an attacker roughly the same information would still be available to an attacker
who is able to (legally or otherwize) obtain access to linked data who is able to (legally or otherwize) obtain access to linked data
sets which are being maintained by large content and service sets which are being maintained by large content and service
providers. providers.
C.32. Simple Opportunistic Encryption - Andrea Bittau, Michael Hamburg, C.32. Simple Opportunistic Encryption - Andrea Bittau, Michael Hamburg,
Mark Handley, David Mazieres, Dan Boneh Mark Handley, David Mazieres, Dan Boneh
32.pdf [61] - Network traffic encryption is becoming a requirement, 32.pdf [63] - Network traffic encryption is becoming a requirement,
not an option. Enabling encryption will be a communal effort so a not an option. Enabling encryption will be a communal effort so a
solution that gives partial benefits until fully deployed is needed. solution that gives partial benefits until fully deployed is needed.
A solution that requires little changes to existing infrastructure A solution that requires little changes to existing infrastructure
will also help as it can be quickly deployed to give immediate short- will also help as it can be quickly deployed to give immediate short-
term benefits. We argue that tcpcrypt, a TCP option for term benefits. We argue that tcpcrypt, a TCP option for
opportunistic encryption is the path of least-resistance for a opportunistic encryption is the path of least-resistance for a
solution against large-scale traffic encryption. Tcpcrypt requires solution against large-scale traffic encryption. Tcpcrypt requires
no changes to applications, is compatible with existing networks no changes to applications, is compatible with existing networks
(works with NATs), and just works by default. It is high (works with NATs), and just works by default. It is high
performance, so it can be deployed on servers without much concern. performance, so it can be deployed on servers without much concern.
tcpcrypt attempts to maximize security for any given setting. By tcpcrypt attempts to maximize security for any given setting. By
default, it will protect against passive eavesdropping, and also default, it will protect against passive eavesdropping, and also
allows detecting large scale interception. With authentication, allows detecting large scale interception. With authentication,
tcpcrypt can provide full security against active attackers and so it tcpcrypt can provide full security against active attackers and so it
is a complete solution both for the short-term and long-term. is a complete solution both for the short-term and long-term.
C.33. An Architecture for a Secure Cloud Collaboration System - Cullen C.33. An Architecture for a Secure Cloud Collaboration System - Cullen
Jennings, Suhas Nandakumar Jennings, Suhas Nandakumar
33.pdf [62] - The Internet technical community is looking at ways to 33.pdf [64] - The Internet technical community is looking at ways to
address pervasive attacks as described in several other internet address pervasive attacks as described in several other internet
drafts. [I-D.barnes-pervasive-problem] describes threat model to drafts. [I-D.barnes-pervasive-problem] describes threat model to
characterize various pervasive attacks on the Internet characterize various pervasive attacks on the Internet
communications. There are many systems that need to be secured communications. There are many systems that need to be secured
against such attacks but this paper considers one possible way to against such attacks but this paper considers one possible way to
secure cloud based collaborations systems. At a high level, this secure cloud based collaborations systems. At a high level, this
paper sugests that users or enterprises could run a key server that paper sugests that users or enterprises could run a key server that
manages the keys to access their content. The cloud service provider manages the keys to access their content. The cloud service provider
would not have access to decrypt the data stored in the cloud but would not have access to decrypt the data stored in the cloud but
various users of the cloud service could get the keys to encrypt and various users of the cloud service could get the keys to encrypt and
decrypt the contents of collaboration sessions facilitated by the decrypt the contents of collaboration sessions facilitated by the
cloud service. This does not protect the meta data of who is talking cloud service. This does not protect the meta data of who is talking
to who but can help protect the content of the conversations. to who but can help protect the content of the conversations.
C.34. Security and Simplicity - Steven Bellovin C.34. Security and Simplicity - Steven Bellovin
34.pdf [63] 34.pdf [65]
C.35. Privacy at the Link Layer - Piers O'Hanlon, Joss Wright, Ian C.35. Privacy at the Link Layer - Piers O'Hanlon, Joss Wright, Ian
Brown Brown
35.pdf [64] - This paper gives an overview of the privacy issues 35.pdf [66] - This paper gives an overview of the privacy issues
around the use of link layer identifiers and associated protocols. around the use of link layer identifiers and associated protocols.
Whilst the IETF generally specifies IP level protocols it does also Whilst the IETF generally specifies IP level protocols it does also
address the link layer in protocols such as address resolution, address the link layer in protocols such as address resolution,
network attachment detection, tunnelling and router redundancy. network attachment detection, tunnelling and router redundancy.
The indiscriminate broadcast of a device's MAC address, a unique and The indiscriminate broadcast of a device's MAC address, a unique and
effectively personal identifier, allows for unregulated and broad- effectively personal identifier, allows for unregulated and broad-
scale tracking of individuals via their personal devices, whether or scale tracking of individuals via their personal devices, whether or
not those devices have made use of a particular service or not. not those devices have made use of a particular service or not.
These addresses typically remain unchanged for the lifetime of a These addresses typically remain unchanged for the lifetime of a
skipping to change at page 40, line 41 skipping to change at page 39, line 45
approved by the user. Moreover various other 'performance enhancing' approved by the user. Moreover various other 'performance enhancing'
approaches further degrade the privacy of individuals such as approaches further degrade the privacy of individuals such as
proactive discovery of WLAN SSIDs, Detection of Network Attachment proactive discovery of WLAN SSIDs, Detection of Network Attachment
(DNA), Wireless ISP roaming (WISPr), name lookups and so on. (DNA), Wireless ISP roaming (WISPr), name lookups and so on.
All these mechanisms need to be re-examined in the light of pervasive All these mechanisms need to be re-examined in the light of pervasive
monitoring. monitoring.
C.36. Erosion of the moral authority of middleboxes - Joe Hildebrand C.36. Erosion of the moral authority of middleboxes - Joe Hildebrand
36.pdf [65] - Many middleboxes on the Internet attempt to add value 36.pdf [67] - Many middleboxes on the Internet attempt to add value
to the connections that traverse that point on the network. Problems to the connections that traverse that point on the network. Problems
in their implementations erode the moral authority that otherwise in their implementations erode the moral authority that otherwise
might accrue to the legitimate value that they add. might accrue to the legitimate value that they add.
C.37. Policy Responses, Implications and Opportunities - Joseph Lorenzo C.37. Policy Responses, Implications and Opportunities - Joseph Lorenzo
Hall & Runa Sandvik Hall & Runa Sandvik
37.pdf [66] - We raise issues for discussion that lie in the 37.pdf [68] - We raise issues for discussion that lie in the
interface between policy and technology. Specifically, we discuss 1) interface between policy and technology. Specifically, we discuss 1)
routing, processing and data localization policy mandates (i.e., new routing, processing and data localization policy mandates (i.e., new
laws that may affect how data flows through the 'net; 2) the laws that may affect how data flows through the 'net; 2) the
uncertain possibility of dilution of credibility of IETF and w3c uncertain possibility of dilution of credibility of IETF and w3c
given what we've seen with NIST after NSA-coziness allegations; 3) given what we've seen with NIST after NSA-coziness allegations; 3)
the claim that strenghtening the internet and web will "help the bad the claim that strenghtening the internet and web will "help the bad
guys" and the dubious need for "lawful intercept" funcationality; and guys" and the dubious need for "lawful intercept" funcationality; and
3) abusive content, cryptography as a controlled export technology, 3) abusive content, cryptography as a controlled export technology,
and the need to standardize more anonymity primitives (onion routing, and the need to standardize more anonymity primitives (onion routing,
pluggable transport protocols). We also highlight our own work in pluggable transport protocols). We also highlight our own work in
ensuring that technologists have a voice in policy environments and ensuring that technologists have a voice in policy environments and
discuss a few interventions we coordinated over the past year, discuss a few interventions we coordinated over the past year,
focusing on software backdoors and NSA surviellance. focusing on software backdoors and NSA surviellance.
C.38. Is it time to bring back the hosts file? - Peter Eckersley C.38. Is it time to bring back the hosts file? - Peter Eckersley
38.pdf [67] 38.pdf [69]
C.39. Metaphors matter; application-layer; distribute more - Larry C.39. Metaphors matter; application-layer; distribute more - Larry
Masinter Masinter
39.pdf [68] - 39.pdf [70] -
1. Dont say Attack: IETF should stay away from political theatre: 1. Dont say Attack: IETF should stay away from political theatre:
changing protocols or workflows not because the change works but changing protocols or workflows not because the change works but
just to say you did something. Metaphors matter. just to say you did something. Metaphors matter.
2. For most relevant threats, traffic analysis is enough, and 2. For most relevant threats, traffic analysis is enough, and
encyption doesnt mitigate. encyption doesnt mitigate.
3. The only deployable protection - if that is what is wanted - 3. The only deployable protection - if that is what is wanted -
means shifting architecture from client-server to mesh. means shifting architecture from client-server to mesh.
C.40. Levels of Opportunistic Privacy Protection for Messaging-Oriented C.40. Levels of Opportunistic Privacy Protection for Messaging-Oriented
Architectures - Dave Crocker, Pete Resnick Architectures - Dave Crocker, Pete Resnick
40.pdf [69] - Messaging protection against pervasive monitoring (PM) 40.pdf [71] - Messaging protection against pervasive monitoring (PM)
needs to cover primary payload, descriptive meta-data, and traffic- needs to cover primary payload, descriptive meta-data, and traffic-
related analysis. Complete protection against PM, for traffic related analysis. Complete protection against PM, for traffic
through complex handling sequences, has not yet been achieved through complex handling sequences, has not yet been achieved
reliably in real-world operation. Consequently, this document reliably in real-world operation. Consequently, this document
considers a range of end-to-end, object-based mechanisms, distinct considers a range of end-to-end, object-based mechanisms, distinct
from channel-based mechanisms. Each approach offers incremental from channel-based mechanisms. Each approach offers incremental
protection levels that can be provided with existing, or low-risk, protection levels that can be provided with existing, or low-risk,
component technologies, such as through the DNS and MIME conventions. component technologies, such as through the DNS and MIME conventions.
C.41. Fingerprinting Guidance for Web Specification Authors - Nick Doty C.41. Fingerprinting Guidance for Web Specification Authors - Nick Doty
41.pdf [70] - http://w3c.github.io/fingerprinting-guidance/ - 41.pdf [72] - http://w3c.github.io/fingerprinting-guidance/ -
Exposure of settings and characteristics of browsers can impact user Exposure of settings and characteristics of browsers can impact user
privacy by allowing for browser fingerprinting. This document privacy by allowing for browser fingerprinting. This document
defines different types of fingerprinting, considers distinct levels defines different types of fingerprinting, considers distinct levels
of mitigation for the related privacy risks and provides guidance for of mitigation for the related privacy risks and provides guidance for
Web specification authors on how to balance these concerns when Web specification authors on how to balance these concerns when
designing new Web features. designing new Web features.
C.42. Eradicating Bearer Tokens for Session Management - Philippe De C.42. Eradicating Bearer Tokens for Session Management - Philippe De
Ryck, Lieven Desmet, Frank Piessens, Wouter Joosen Ryck, Lieven Desmet, Frank Piessens, Wouter Joosen
42.pdf [71] - Session management is a crucial component in every 42.pdf [74] - Session management is a crucial component in every
modern web application. It links multiple requests and temporary modern web application. It links multiple requests and temporary
stateful information together, enabling a rich and interactive user stateful information together, enabling a rich and interactive user
experience. The de facto cookie-based session management mechanism experience. The de facto cookie-based session management mechanism
is however flawed by design, enabling the theft of the session cookie is however flawed by design, enabling the theft of the session cookie
through simple eavesdropping or script injection attacks. Possession through simple eavesdropping or script injection attacks. Possession
of the session cookie gives an adversary full control the user's of the session cookie gives an adversary full control the user's
sover ession, allowing him to impersonate the user to the target sover ession, allowing him to impersonate the user to the target
application and perform transactions in the user's name. While application and perform transactions in the user's name. While
several alternatives for secure session management exist, they fail several alternatives for secure session management exist, they fail
to be adopted due to the introduction of additional roundtrips and to be adopted due to the introduction of additional roundtrips and
skipping to change at page 42, line 44 skipping to change at page 42, line 8
session is established, the overhead becomes negligible (<0.1ms), and session is established, the overhead becomes negligible (<0.1ms), and
the average size of the request headers is even smaller than with the average size of the request headers is even smaller than with
common session cookies. Additionally, SecSess works well with common session cookies. Additionally, SecSess works well with
currently deployed systems, such as web caches and third-party currently deployed systems, such as web caches and third-party
services. SecSess also supports a gradual migration path, while services. SecSess also supports a gradual migration path, while
remaining compatible with currently existing applications. remaining compatible with currently existing applications.
C.43. STREWS Web-platform security guide: security assessment of the C.43. STREWS Web-platform security guide: security assessment of the
Web ecosystem - Martin Johns, Lieven Desmet Web ecosystem - Martin Johns, Lieven Desmet
43.pdf [72] - In this document, we report on the Web-platform 43.pdf [75] - In this document, we report on the Web-platform
security guide, which has been developed within the EC-FP7 project security guide, which has been developed within the EC-FP7 project
STREWS. Based on their research, the STREWS consortium argues that STREWS. Based on their research, the STREWS consortium argues that
in order to strengthening the Internet (e.g. against pervasive in order to strengthening the Internet (e.g. against pervasive
monitoring), it is crucial to also strengthen the web application monitoring), it is crucial to also strengthen the web application
ecosystem, the de-facto Internet application platform. ecosystem, the de-facto Internet application platform.
C.44. Pervasive Attack: A Threat Model and Problem Statement - Richard C.44. Pervasive Attack: A Threat Model and Problem Statement - Richard
Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie
44.pdf [8] - Documents published in 2013 have revealed several 44.pdf [76] - Documents published in 2013 have revealed several
classes of "pervasive" attack on Internet communications. In this classes of "pervasive" attack on Internet communications. In this
document, we review the main attacks that have been published, and document, we review the main attacks that have been published, and
develop a threat model that describes these pervasive attacks. Based develop a threat model that describes these pervasive attacks. Based
on this threat model, we discuss the techniques that can be employed on this threat model, we discuss the techniques that can be employed
in Internet protocol design to increase the protocols robustness to in Internet protocol design to increase the protocols robustness to
pervasive attacks. pervasive attacks.
C.45. Cryptech - Building a More Assured HSM with a More Assured Tool- C.45. Cryptech - Building a More Assured HSM with a More Assured Tool-
Chain - Randy Bush Chain - Randy Bush
45.pdf [73] 45.pdf [77]
C.46. Replacing passwords on the Internet AKA post-Snowden C.46. Replacing passwords on the Internet AKA post-Snowden
Opportunistic Encryption - Ben Laurie, Ian Goldberg Opportunistic Encryption - Ben Laurie, Ian Goldberg
46.pdf [74] 46.pdf [78]
C.47. End-User Concerns about Pervasive Internet Monitoring: Principles C.47. End-User Concerns about Pervasive Internet Monitoring: Principles
and Practice - Tara Whalen, Stuart Cheshire, David Singer and Practice - Tara Whalen, Stuart Cheshire, David Singer
47.pdf [75] - This position paper will discuss pervasive monitoring 47.pdf [79] - This position paper will discuss pervasive monitoring
on the Internet from the perspective of end users: what are on the Internet from the perspective of end users: what are
overarching concerns around pervasive monitoring, and what are some overarching concerns around pervasive monitoring, and what are some
steps that could be taken to address those concerns? We begin by steps that could be taken to address those concerns? We begin by
exploring a preliminary set of characteristics of systemic exploring a preliminary set of characteristics of systemic
surveillance, which can be used to pinpoint dominant concerns of end surveillance, which can be used to pinpoint dominant concerns of end
users that should be addressed through technical means. We then users that should be addressed through technical means. We then
illustrate one specific significant problem facing end users, namely illustrate one specific significant problem facing end users, namely
that of certificate errors, which can be exploited to facilitate that of certificate errors, which can be exploited to facilitate
pervasive surveillance. We suggest that users should not be required pervasive surveillance. We suggest that users should not be required
to determine whether a certificate error is valid, but instead to to determine whether a certificate error is valid, but instead to
block access to websites that generate such errors. We believe this block access to websites that generate such errors. We believe this
approach would be more effective in protecting end users in an approach would be more effective in protecting end users in an
environment of persistent network threats. environment of persistent network threats.
C.48. Developer-Resistant Cryptography - Kelsey Cairns, Graham Steel C.48. Developer-Resistant Cryptography - Kelsey Cairns, Graham Steel
48.pdf [76] - "Properly implemented strong crypto systems are one of 48.pdf [80] - "Properly implemented strong crypto systems are one of
the few things that you can rely on" - Edward Snowden. So why is the few things that you can rely on" - Edward Snowden. So why is
mass surveillance so successful? One (big) problem is endpoint mass surveillance so successful? One (big) problem is endpoint
security. Another is that strong crypto systems are sufficiently security. Another is that strong crypto systems are sufficiently
difficult to implement that often either mistakes are made resulting difficult to implement that often either mistakes are made resulting
in catastrophic loss of security, or cryptography is not used at all. in catastrophic loss of security, or cryptography is not used at all.
What can we do to make cryptography easier to use and more resistant What can we do to make cryptography easier to use and more resistant
to developer errors? to developer errors?
C.49. Improving the reliability of key ownership assertions - Kai C.49. Improving the reliability of key ownership assertions - Kai
Engert Engert
49.pdf [77] - A majority of today's secure Internet connections rely 49.pdf [81] - A majority of today's secure Internet connections rely
on Certificate Authorities not being abused for issueing false on Certificate Authorities not being abused for issueing false
certificates (key ownership assertions), which might get abused for certificates (key ownership assertions), which might get abused for
interception purposes, despite the risk of detection. I suggest to interception purposes, despite the risk of detection. I suggest to
enhance Internet protocols with protective mechanisms to detect false enhance Internet protocols with protective mechanisms to detect false
key ownership assertions. Ideas: (1) Using a network of proxy key ownership assertions. Ideas: (1) Using a network of proxy
services, for example as implemented by the The Onion Router (Tor), services, for example as implemented by the The Onion Router (Tor),
consistency checking chould be performed by individual clients, in consistency checking chould be performed by individual clients, in
order to detect assertions that are likely false, prior to allowing a order to detect assertions that are likely false, prior to allowing a
connection (see Detector.io). (2) Extend the idea that notary connection (see Detector.io). (2) Extend the idea that notary
services provide a second opinion about the correctness of key services provide a second opinion about the correctness of key
ownership assertions, by requiring CAs to run such services (kuix.de/ ownership assertions, by requiring CAs to run such services (kuix.de/
mecai). (3) Implement protocol extensions, where client software mecai). (3) Implement protocol extensions, where client software
reports previously seen key ownership assertions to the operators of reports previously seen key ownership assertions to the operators of
services, allowing the discovery of false ownership assertions. services, allowing the discovery of false ownership assertions.
C.50. Mike O'Neill's Position Paper - Mike O'Neill C.50. Mike O'Neill's Position Paper - Mike O'Neill
50.pdf [78] 50.pdf [82]
C.51. Detecting MITM Attacks on Ephemeral Diffie-Hellman without C.51. Detecting MITM Attacks on Ephemeral Diffie-Hellman without
Relying on a PKI in Real-Time Communications - Alan Johnston Relying on a PKI in Real-Time Communications - Alan Johnston
51.pdf [79] - With the recent revelations about pervasive 51.pdf [83] - With the recent revelations about pervasive
surveillance on the Internet, there is renewed interest in techniques surveillance on the Internet, there is renewed interest in techniques
that protect against passive eavesdropping without relying on a that protect against passive eavesdropping without relying on a
Public Key Infrastructure (PKI). An ephemeral Diffie-Hellman (DH) Public Key Infrastructure (PKI). An ephemeral Diffie-Hellman (DH)
key agreement can provide such protection, but (without key agreement can provide such protection, but (without
authentication) the exchange is vulnerable to a Man in the Middle authentication) the exchange is vulnerable to a Man in the Middle
(MitM) attack. An example of a protocol that has MitM protection for (MitM) attack. An example of a protocol that has MitM protection for
a DH key agreement is ZRTP, RFC 6189, "ZRTP: Media Path Key Agreement a DH key agreement is ZRTP, RFC 6189, "ZRTP: Media Path Key Agreement
for Unicast Secure RTP." ZRTP provides pervasive surveillance for Unicast Secure RTP." ZRTP provides pervasive surveillance
resistant security for Voice over IP (VoIP), video communication, and resistant security for Voice over IP (VoIP), video communication, and
other real-time communication services. This paper describes the other real-time communication services. This paper describes the
techniques used by ZRTP to detect MitM attacks, and explores whether techniques used by ZRTP to detect MitM attacks, and explores whether
these techniques could be used to develop a general MitM detection these techniques could be used to develop a general MitM detection
protocol to be used by other non-real-time communication protocols. protocol to be used by other non-real-time communication protocols.
An example of how ZRTP can provide MitM detection for another An example of how ZRTP can provide MitM detection for another
protocol, DTLS-SRTP, Datagram Transport Layer Security - Secure Real- protocol, DTLS-SRTP, Datagram Transport Layer Security - Secure Real-
time Transport Protocol, is given. time Transport Protocol, is given.
C.52. Trust & Usability on the Web, a Social/Legal perspective - Rigo C.52. Trust & Usability on the Web, a Social/Legal perspective - Rigo
Wenning, Bert Bos Wenning, Bert Bos
52.pdf [80] - (1) The browsers' UIs for security are very technical 52.pdf [84] - (1) The browsers' UIs for security are very technical
and seem to avoid saying anything useful, maybe so that the browsers and seem to avoid saying anything useful, maybe so that the browsers
and CAs cannot be held responsible. (2) A user wanting to configure and CAs cannot be held responsible. (2) A user wanting to configure
security has difficulty finding the UI and then often discovers that security has difficulty finding the UI and then often discovers that
settings are hard-coded or unclear. (3) The security model is based settings are hard-coded or unclear. (3) The security model is based
on trusting a few commercial entities and mistrusting the user, who on trusting a few commercial entities and mistrusting the user, who
ends up without control over his software if one of those entities is ends up without control over his software if one of those entities is
compromised or doesn't share his goals. Conclusion: We need better compromised or doesn't share his goals. Conclusion: We need better
UIs, which in turn requires a PKI that has the metadata and social UIs, which in turn requires a PKI that has the metadata and social
aspects that help users understand and explore the keys and the aspects that help users understand and explore the keys and the
organizations behind them. organizations behind them.
C.53. Hardening Operations and Management Against Passive Eavesdropping C.53. Hardening Operations and Management Against Passive Eavesdropping
- Bernard Aboba - Bernard Aboba
53.pdf [81] - Today within service providers protocols used for 53.pdf [85] - Today within service providers protocols used for
operations and management frequently send data in the clear, enabling operations and management frequently send data in the clear, enabling
the data to be collected by passive eavesdroppers. Examples of the data to be collected by passive eavesdroppers. Examples of
operations and management protocols include Authentication, operations and management protocols include Authentication,
Authorization and Accounting (AAA), syslog and Simple Networking Authorization and Accounting (AAA), syslog and Simple Networking
Monitoring Protocol (SNMP). Since the publication of "Operational Monitoring Protocol (SNMP). Since the publication of "Operational
Security Current Practices in Internet Service Provider Environments" Security Current Practices in Internet Service Provider Environments"
[RFC4778], the IETF has developed specifications that enable per- [RFC4778], the IETF has developed specifications that enable per-
packet confidentiality to be applied to operations and management packet confidentiality to be applied to operations and management
protocols. By developing updated operational guidance recommending protocols. By developing updated operational guidance recommending
deployment of per-packet confidentiality based on recent IETF Request deployment of per-packet confidentiality based on recent IETF Request
for Comments (RFCs) and work-in-progress, the IETF can assist in for Comments (RFCs) and work-in-progress, the IETF can assist in
bringing customer and regulatory pressure to bear in improving bringing customer and regulatory pressure to bear in improving
operational practices. operational practices.
C.54. A few theses regarding privacy and security - Andreas Kuckartz C.54. A few theses regarding privacy and security - Andreas Kuckartz
54.pdf [82] 54.pdf [86]
C.55. Meet the new threat model, same as the old threat model - Eric C.55. Meet the new threat model, same as the old threat model - Eric
Rescorla Rescorla
55.pdf [83] - The Internet environment has a fairly well understood 55.pdf [87] - The Internet environment has a fairly well understood
threat model. In general, we assume that the end-systems engaging in threat model. In general, we assume that the end-systems engaging in
a protocol exchange have not themselves been compromised. Protecting a protocol exchange have not themselves been compromised. Protecting
against an attack when one of the end-systems has been compromised is against an attack when one of the end-systems has been compromised is
extraordinarily difficult. It is, however, possible to design extraordinarily difficult. It is, however, possible to design
protocols which minimize the extent of the damage done under these protocols which minimize the extent of the damage done under these
circumstances. circumstances.
By contrast, we assume that the attacker has nearly complete control By contrast, we assume that the attacker has nearly complete control
of the communications channel over which the end-systems communicate. of the communications channel over which the end-systems communicate.
This means that the attacker can read any PDU (Protocol Data Unit) on This means that the attacker can read any PDU (Protocol Data Unit) on
the network and undetectably remove, change, or inject forged packets the network and undetectably remove, change, or inject forged packets
onto the wire. This includes being able to generate packets that onto the wire. This includes being able to generate packets that
appear to be from a trusted machine. Thus, even if the end-system appear to be from a trusted machine. Thus, even if the end-system
with which you wish to communicate is itself secure, the Internet with which you wish to communicate is itself secure, the Internet
environment provides no assurance that packets which claim to be from environment provides no assurance that packets which claim to be from
that system in fact are. - [RFC3552] that system in fact are. - [RFC3552]
C.56. It's Time for Application-Centric Security - Yuan Gu, Harold C.56. It's Time for Application-Centric Security - Yuan Gu, Harold
Johnson Johnson
56.pdf [84] - An 'application' is an organized data/executable-code 56.pdf [88] - An 'application' is an organized data/executable-code
compound performing a specific function or service. We hold that compound performing a specific function or service. We hold that
applications should be protected intrinsically (by obfuscated, applications should be protected intrinsically (by obfuscated,
tamper-resistant code and data), as well as extrinsically (by tamper-resistant code and data), as well as extrinsically (by
encrypted communication, hardened hardware platforms, authenticated encrypted communication, hardened hardware platforms, authenticated
access). (1) Cloud-based applications are vulnerable to their hosting access). (1) Cloud-based applications are vulnerable to their hosting
services or neighbors. (2) Peripheral-based applications (on phones, services or neighbors. (2) Peripheral-based applications (on phones,
pads, PDAs, or more generally in the Internet of Things) are pads, PDAs, or more generally in the Internet of Things) are
vulnerable because hardware security is inconsistent and very vulnerable because hardware security is inconsistent and very
expensive to repair. (3) Browser-based applications are vulnerable expensive to repair. (3) Browser-based applications are vulnerable
because they run on potentially hostile or malware-infected browsers because they run on potentially hostile or malware-infected browsers
or platforms which we don't control. Application obfuscations such or platforms which we don't control. Application obfuscations such
as homomorphic transforms on data and computation (motto: avoid data as homomorphic transforms on data and computation (motto: avoid data
or computation in plain form) and increased interdependency (motto: or computation in plain form) and increased interdependency (motto:
aggressive fragility under tampering) can effectively address these aggressive fragility under tampering) can effectively address these
vulnerabilities. vulnerabilities.
C.57. Sabatini Monatesti position paper - Sabatine Monatesti C.57. Sabatini Monatesti position paper - Sabatine Monatesti
57.pdf [85] 57.pdf [89]
C.58. Trust problems in pervasive monitoring - Melinda Shore, Karen C.58. Trust problems in pervasive monitoring - Melinda Shore, Karen
O'Donoghue O'Donoghue
58.pdf [86] 58.pdf [90]
C.59. Beyond "Just TLS Everywhere": From Client-encrypted Messaging to C.59. Beyond "Just TLS Everywhere": From Client-encrypted Messaging to
Defending the Social Graph - Harry Halpin, George Danezis Defending the Social Graph - Harry Halpin, George Danezis
59.pdf [87] 59.pdf [91]
C.60. Network Security as a Public Good - Wendy Seltzer C.60. Network Security as a Public Good - Wendy Seltzer
60.pdf [88] - Network security depends on cooperation of multiple 60.pdf [92] - Network security depends on cooperation of multiple
actors in the Internet ecosystem. Standards consortia should support actors in the Internet ecosystem. Standards consortia should support
and help coordinate activity to protect the commons. and help coordinate activity to protect the commons.
C.61. Statement of Interest on behalf of the W3C TAG - Dan Appelquist C.61. Statement of Interest on behalf of the W3C TAG - Dan Appelquist
61.pdf [89] 61.pdf [93]
C.62. Improving Security on the Internet - Hannes Tschofenig C.62. Improving Security on the Internet - Hannes Tschofenig
62.pdf [90] - Securing the Internet has been an on-going activity 62.pdf [94] - Securing the Internet has been an on-going activity
since the early days of the IETF and a variety of technical since the early days of the IETF and a variety of technical
specifications have been standardized. Someone reading through IETF specifications have been standardized. Someone reading through IETF
RFCs might easily get the impression that the Internet should be very RFCs might easily get the impression that the Internet should be very
secure. This is, however, not the entire story as the never-ending secure. This is, however, not the entire story as the never-ending
series of breaches and recently the Snowden revelations have series of breaches and recently the Snowden revelations have
illustrated. While on paper everything looks pretty good many illustrated. While on paper everything looks pretty good many
problems can be found in implementations and with deployments. problems can be found in implementations and with deployments.
In this position paper the author makes the argument that improving In this position paper the author makes the argument that improving
the collaboration between different communities in the Internet the collaboration between different communities in the Internet
software development life-cycle will be crucial for improving software development life-cycle will be crucial for improving
security on the Internet. security on the Internet.
C.63. Protecting customer data from government snooping - Orit Levin C.63. Protecting customer data from government snooping - Orit Levin
63.pdf [91] 63.pdf [95]
C.64. Privacy Aware Internet Development Initiative 2014 - Achim C.64. Privacy Aware Internet Development Initiative 2014 - Achim
Klabunde Klabunde
64.pdf [92] - Protecting privacy on the Internet requires more than 64.pdf [96] - Protecting privacy on the Internet requires more than
using encryption. Protocols, implementations and applications must using encryption. Protocols, implementations and applications must
minimise the amount of personal data that is distributed and minimise the amount of personal data that is distributed and
collected. Work is required to develop and disseminate privacy aware collected. Work is required to develop and disseminate privacy aware
design and impmementation techniques to the actual developers. The design and impmementation techniques to the actual developers. The
paper is a call for interest for an initiative aiming to address this paper is a call for interest for an initiative aiming to address this
need, supported by privacy and technology experts. need, supported by privacy and technology experts.
C.65. The Internet is Broken: Idealistic Ideas for Building a NEWGNU C.65. The Internet is Broken: Idealistic Ideas for Building a NEWGNU
Network - Christian Grothoff, Bartlomiej Polot, Carlo von Loesch Network - Christian Grothoff, Bartlomiej Polot, Carlo von Loesch
65.pdf [93] - This paper describes issues for security and privacy at 65.pdf [97] - This paper describes issues for security and privacy at
all layers of the Internet stack and proposes radical changes to the all layers of the Internet stack and proposes radical changes to the
architecture to build a network that offers strong security and architecture to build a network that offers strong security and
privacy by default. privacy by default.
C.66. Opportunistic Keying as a Countermeasure to Pervasive Monitoring C.66. Opportunistic Keying as a Countermeasure to Pervasive Monitoring
- Stephen Kent - Stephen Kent
66.pdf [94] - This document was prepared as part of the IETF response 66.pdf [98] - This document was prepared as part of the IETF response
to concerns about "pervasive monitoring" as articulated in to concerns about "pervasive monitoring" as articulated in [draft-
[draft-farrell-perpass-attack]. It begins by exploring terminology farrell-perpass-attack]. It begins by exploring terminology that has
that has been used in IETF standards (and in academic publications) been used in IETF standards (and in academic publications) to
to describe encryption and key management techniques, with a focus on describe encryption and key management techniques, with a focus on
authentication vs. anonymity. Based on this analysis, it propose a authentication vs. anonymity. Based on this analysis, it propose a
new term, "opportunistic keying" (OK) to describe a goal for IETF new term, "opportunistic keying" (OK) to describe a goal for IETF
security protocols, one possible countermeasure to pervasive security protocols, one possible countermeasure to pervasive
monitoring. It reviews key management mechanisms used in IETF monitoring. It reviews key management mechanisms used in IETF
security protocol standards, with respect to these properties, to security protocol standards, with respect to these properties, to
identify what changes might be needed to offer OK with minimal identify what changes might be needed to offer OK with minimal
changes. The document ends by examining possible impediments to and changes. The document ends by examining possible impediments to and
potential adverse effects associated with deployment and use of potential adverse effects associated with deployment and use of
techniques that would increase the use of encryption, even when keys techniques that would increase the use of encryption, even when keys
are distributed in an unauthenticated manner. are distributed in an unauthenticated manner.
Appendix D. Workshop chairs & program committee Appendix D. Workshop chairs & program committee
The workshop chairs were three: Stephen Farrell [95] (TCD) and Rigo The workshop chairs were three: Stephen Farrell [99] (TCD) and Rigo
Wenning [96] (W3C) from the STREWS project, and Hannes Wenning [100] (W3C) from the STREWS project, and Hannes Tschofenig
Tschofenig [97] (ARM) from the STREWS Interest Group. [101] (ARM) from the STREWS Interest Group.
A program committee (PC) was charged with evaluating the submitted A program committee (PC) was charged with evaluating the submitted
papers. It was made up of the members of the STREWS project, the papers. It was made up of the members of the STREWS project, the
members of the STREWS Interest Group, plus invited experts: Bernard members of the STREWS Interest Group, plus invited experts: Bernard
Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard
Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen
O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP), O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP),
Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal
Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler
(Microsoft) and Sean Turner (IECA). (Microsoft) and Sean Turner (IECA).
Appendix E. Participants Appendix E. Participants
The participants to the workshop were: The participants to the workshop were:
o *Bernard Aboba* (Microsoft Corporation) o Bernard Aboba (Microsoft Corporation)
o *Thijs Alkemade* (Adium) o Thijs Alkemade (Adium)
o *Daniel Appelquist* (Telefonica Digital) o Daniel Appelquist (Telefonica Digital)
o *Jari Arkko* (Ericsson)
o *Alia Atlas* (Juniper Networks) o Jari Arkko (Ericsson)
o *Emmanuel Baccelli* (INRIA) o Alia Atlas (Juniper Networks)
o *Mary Barnes* o Emmanuel Baccelli (INRIA)
o *Richard Barnes* (Mozilla) o Mary Barnes
o *Steve Bellovin* (Columbia University) o Richard Barnes (Mozilla)
o *Andrea Bittau* (Stanford University) o Steve Bellovin (Columbia University)
o *Marc Blanchet* (Viagenie) o Andrea Bittau (Stanford University)
o *Carsten Bormann* (Uni Bremen TZI) o Marc Blanchet (Viagenie)
o *Bert Bos* (W3C) o Carsten Bormann (Uni Bremen TZI)
o *Ian Brown* (Oxford University) o Bert Bos (W3C)
o *Stewart Bryant* (Cisco Systems) o Ian Brown (Oxford University)
o *Randy Bush* (IIJ / Dragon Research Labs) o Stewart Bryant (Cisco Systems)
o *Kelsey Cairns* (Washington State University) o Randy Bush (IIJ / Dragon Research Labs)
o *Stuart Cheshire* (Apple) o Kelsey Cairns (Washington State University)
o *Vincent Cheval* (University of Birmingham) o Stuart Cheshire (Apple)
o *Benoit Claise* (Cisco) o Vincent Cheval (University of Birmingham)
o *Alissa Cooper* (Cisco) o Benoit Claise (Cisco)
o *Dave Crocker* (Brandenburg InternetWorking) o Alissa Cooper (Cisco)
o *Leslie Daigle* (Internet Society) o Dave Crocker (Brandenburg InternetWorking)
o Leslie Daigle (Internet Society)
o *George Danezis* (University College London) o George Danezis (University College London)
o *Spencer Dawkins* (Huawei) o Spencer Dawkins (Huawei)
o *Mark Donnelly* (Painless Security) o Mark Donnelly (Painless Security)
o *Nick Doty* (W3C) o Nick Doty (W3C)
o *Dan Druta* (AT&T)
o *Peter Eckersley* (Electronic Frontier Foundation) o Dan Druta (AT&T)
o *Lars Eggert* (NetApp) o Peter Eckersley (Electronic Frontier Foundation)
o *Kai Engert* (Red Hat) o Lars Eggert (NetApp)
o *Monika Ermert* o Kai Engert (Red Hat)
o *Stephen Farrell* (Trinity College Dublin) o Monika Ermert
o *Barbara Fraser* (Cisco) o Stephen Farrell (Trinity College Dublin)
o *Virginie Galindo* (gemalto) o Barbara Fraser (Cisco)
o *Stefanie Gerdes* (Uni Bremen TZI) o Virginie Galindo (gemalto)
o *Daniel Kahn Gillmor* (ACLU) o Stefanie Gerdes (Uni Bremen TZI)
o *Wendy M. Grossman* o Daniel Kahn Gillmor (ACLU)
o *Christian Grothoff* (The GNUnet Project) o Wendy M. Grossman
o *Oliver Hahm* (INRIA) o Christian Grothoff (The GNUnet Project)
o *Joseph Lorenzo Hall* (Center for Democracy & Technology) o Oliver Hahm (INRIA)
o *Phillip Hallam-Baker* o Joseph Lorenzo Hall (Center for Democracy & Technology)
o *Harry Halpin* (W3C/MIT and IRI) o Phillip Hallam-Baker
o *Ted Hardie* (Google) o Harry Halpin (W3C/MIT and IRI)
o *Joe Hildebrand* (Cisco Systems) o Ted Hardie (Google)
o *Russ Housley* (Vigil Security, LLC) o Joe Hildebrand (Cisco Systems)
o *Cullen Jennings* (CISCO) o Russ Housley (Vigil Security, LLC)
o Cullen Jennings (CISCO)
o *Leif Johansson* (SUNET) o Leif Johansson (SUNET)
o *Harold Johnson* (Irdeto) o Harold Johnson (Irdeto)
o *Alan Johnston* (Avaya) o Alan Johnston (Avaya)
o *L. Aaron Kaplan* (CERT.at) o L. Aaron Kaplan (CERT.at)
o *Steve Kent* (BBN Technologies)
o *Achim Klabunde* (European Data Protection Supervisor) o Steve Kent (BBN Technologies)
o *Hans Kuhn* (NOC) o Achim Klabunde (European Data Protection Supervisor)
o *Christian de Larrinaga* o Hans Kuhn (NOC)
o *Ben Laurie* (Google) o Christian de Larrinaga
o *Eliot Lear* (Cisco Ssytems) o Ben Laurie (Google)
o *Barry Leiba* (Huawei Technologies) o Eliot Lear (Cisco Ssytems)
o *Sebastian Lekies* (SAP AG) o Barry Leiba (Huawei Technologies)
o *Orit Levin* (Microsoft Corporation) o Sebastian Lekies (SAP AG)
o *carlo von lynX* (#youbroketheinternet) o Orit Levin (Microsoft Corporation)
o *Xavier Marjou* (Orange) o Carlo Von LynX (#youbroketheinternet)
o *Larry Masinter* (Adobe) o Xavier Marjou (Orange)
o *John Mattsson* (Ericsson) o Larry Masinter (Adobe)
o *Patrick McManus* (Mozilla) o John Mattsson (Ericsson)
o *Doug Montgomery* (NIST) o Patrick McManus (Mozilla)
o *Kathleen Moriarty* (EMC) o Doug Montgomery (NIST)
o *Alec Muffett* (Facebook) o Kathleen Moriarty (EMC)
o *Suhas Nandakumar* (Cisco Systems) o Alec Muffett (Facebook)
o *Linh Nguyen* (ERCIM/W3C) o Suhas Nandakumar (Cisco Systems)
o *Linus Nordberg* (NORDUnet) o Linh Nguyen (ERCIM/W3C)
o Linus Nordberg (NORDUnet)
o *Mark Nottingham* o Mark Nottingham
o *Karen O'Donoghue* (Internet Society) o Karen O'Donoghue (Internet Society)
o *Piers O'Hanlon* (Oxford Internet Institute) o Piers O'Hanlon (Oxford Internet Institute)
o *Kenny Paterson* (Royal Holloway, University of London) o Kenny Paterson (Royal Holloway, University of London)
o *Jon Peterson* (Neustar)
o *Joshua Phillips* (University of Birmingham) o Jon Peterson (Neustar)
o *Alfredo Pironti* (INRIA) o Joshua Phillips (University of Birmingham)
o *Dana Polatin-Reuben* (University of Oxford) o Alfredo Pironti (INRIA)
o *Prof. Johan Pouwelse* (Delft University of Technology) o Dana Polatin-Reuben (University of Oxford)
o *Max Pritikin* (Cisco) o Prof. Johan Pouwelse (Delft University of Technology)
o *Eric Rescorla* (Mozilla) o Max Pritikin (Cisco)
o *Pete Resnick* (Qualcomm Technologies, Inc.) o Eric Rescorla (Mozilla)
o *Tom Ristenpart* (University of Wisconsin) o Pete Resnick (Qualcomm Technologies, Inc.)
o *Andrei Robachevsky* (Internet Society) o Tom Ristenpart (University of Wisconsin)
o *David Rogers* (Copper Horse) o Andrei Robachevsky (Internet Society)
o *Scott Rose* (NIST) o David Rogers (Copper Horse)
o *Christine Runnegar* (Internet Society) o Scott Rose (NIST)
o *Philippe De Ryck* (DistriNet - KU Leuven) o Christine Runnegar (Internet Society)
o *Peter Saint-Andre* (&yet) o Philippe De Ryck (DistriNet - KU Leuven)
o *Runa A. Sandvik* (Center for Democracy and Technology) o Peter Saint-Andre (&yet)
o *Jakob Schlyter* (&#12461;&#12524;&#12452;) o Runa A. Sandvik (Center for Democracy and Technology)
o *Dr. Jan Seedorf* (NEC Laboratories Europe) o Jakob Schlyter
o *Wendy Seltzer* (W3C) o Dr. Jan Seedorf (NEC Laboratories Europe)
o *Melinda Shore* (No Mountain Software) o Wendy Seltzer (W3C)
o Melinda Shore (No Mountain Software)
o *Dave Thaler* (Microsoft) o Dave Thaler (Microsoft)
o *Brian Trammell* (ETH Zurich) o Brian Trammell (ETH Zurich)
o *Hannes Tschofenig* (ARM Limited) o Hannes Tschofenig (ARM Limited)
o *Sean Turner* (IECA, Inc.) o Sean Turner (IECA, Inc.)
o *Matthias Waehlisch* (Freie Universitaet Berlin)
o *Greg Walton* (Oxford University) o Matthias Waehlisch (Freie Universitaet Berlin)
o *Rigo Wenning* (W3C) o Greg Walton (Oxford University)
o *Tara Whalen* (Apple Inc.) o Rigo Wenning (W3C)
o *Greg Wood* (Internet Society) o Tara Whalen (Apple Inc.)
o *Jiangshan Yu* (University of Birmingham) o Greg Wood (Internet Society)
o *Aaron Zauner* o Jiangshan Yu (University of Birmingham)
o *Dacheng Zhang* (Huawei) o Aaron Zauner
o *Phil Zimmermann* (Silent Circle LLC) o Dacheng Zhang (Huawei)
o *Juan-Carlos Zuniga* (InterDigital) o Phil Zimmermann (Silent Circle LLC)
o Juan-Carlos Zuniga (InterDigital)
Authors' Addresses Authors' Addresses
Stephen Farrell Stephen Farrell
Trinity College, Dublin Trinity College, Dublin
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
Rigo Wenning Rigo Wenning
World Wide Web Consortium World Wide Web Consortium
 End of changes. 389 change blocks. 
581 lines changed or deleted 569 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/