draft-iab-strint-report-03.txt   rfc7687.txt 
Network Working Group S. Farrell Internet Architecture Board (IAB) S. Farrell
Internet-Draft Trinity College, Dublin Request for Comments: 7687 Trinity College, Dublin
Intended status: Informational R. Wenning Category: Informational R. Wenning
Expires: March 7, 2016 B. Bos ISSN: 2070-1721 B. Bos
W3C W3C
M. Blanchet M. Blanchet
Viagenie Viagenie
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
September 4, 2015 December 2015
Report from the Strengthening the Internet (STRINT) workshop Report from the Strengthening the Internet (STRINT) Workshop
draft-iab-strint-report-03
Abstract Abstract
The Strengthening the Internet (STRINT) workshop assembled one The Strengthening the Internet (STRINT) workshop assembled one
hundred participants in London for two days in early 2014 to discuss hundred participants in London for two days in early 2014 to discuss
how the technical community, and in particular the IETF and the W3C, how the technical community, and in particular the IETF and the W3C,
should react to Pervasive Monitoring and more generally how to should react to Pervasive Monitoring and more generally how to
strengthen the Internet in the face of such attacks. The discussions strengthen the Internet in the face of such attacks. The discussions
covered issues of terminology, the role of user interfaces, classes covered issues of terminology, the role of user interfaces, classes
of mitigation, some specific use cases, transition strategies of mitigation, some specific use cases, transition strategies
(including opportunistic encryption), and more. The workshop ended (including opportunistic encryption), and more. The workshop ended
with a few high-level recommendations, which it is believed could be with a few high-level recommendations, that it is believed could be
implemented and which could help strengthen the Internet. This is implemented and could help strengthen the Internet. This is the
the report of that workshop. report of that workshop.
Note that this document is a report on the proceedings of the Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB those of the workshop participants and do not necessarily reflect IAB
views and positions. views and positions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Architecture Board (IAB)
Task Force (IETF). Note that other groups may also distribute and represents information that the IAB has deemed valuable to
working documents as Internet-Drafts. The list of current Internet- provide for permanent record. Documents approved for publication by
Drafts is at http://datatracker.ietf.org/drafts/current/. the IAB are not a candidate for any level of Internet Standard; see
Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7687.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Workshop goals . . . . . . . . . . . . . . . . . . . . . . . 4 3. Workshop Goals . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop structure . . . . . . . . . . . . . . . . . . . . . 5 4. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. After the workshop . . . . . . . . . . . . . . . . . . . . . 20 6. After the Workshop . . . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Security considerations . . . . . . . . . . . . . . . . . . . 21 8. Informative References . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Workshop chairs & program committee . . . . . . . . 28 Appendix C. Workshop Chairs and Program Committee . . . . . . . 29
Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 28 Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Context 1. Context
The Vancouver IETF plenary[vancouverplenary] concluded that Pervasive The technical plenary session at IETF 88 [vancouverplenary] concluded
Monitoring (PM) represents an attack on the Internet, and the IETF that Pervasive Monitoring (PM) represents an attack on the Internet,
has begun to carry out the more obvious actions required to try to and the IETF has begun to carry out the more obvious actions required
handle this attack. However, there are additional much more complex to try to handle this attack. However, there are much more complex
questions arising that need further consideration before any 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 (<https://www.w3.org>) and IAB (<https://www.iab.org>)
the topic of "Strengthening the Internet Against Pervasive therefore decided to host a workshop on the topic of "Strengthening
Monitoring" before IETF 89 [4] in London in March 2014. The the Internet Against Pervasive Monitoring" [STRINT] before IETF 89 in
FP7-funded STREWS [5] project organised the STRINT workshop on behalf London in March 2014. The FP7-funded STREWS project
of the IAB and W3C. (<https://www.strews.eu/>) organised the STRINT workshop on behalf of
the IAB and W3C.
The main workshop goal was to discuss what can be done, especially by The 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[RFC7258] (the text of which had achieved IEFF that PM is an attack [RFC7258] (the text of which had achieved IETF
consensus at the time of the workshop, even though the RFC had yet to consensus at the time of the workshop, even though the RFC had yet to
be published). 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, except for a few generally of good quality and all were published, except for a few
skipping to change at page 3, line 34 skipping to change at page 3, line 32
1. Well-implemented cryptography can be effective against PM and 1. Well-implemented cryptography can be effective against PM and
will benefit the Internet if used more, despite its cost, which will benefit the Internet if used more, despite its cost, which
is steadily decreasing anyway. is steadily decreasing anyway.
2. Traffic analysis also needs to be considered, but is less well 2. Traffic analysis also needs to be considered, but is less well
understood in the Internet community: relevant research and understood in the Internet community: relevant research and
protocol mitigations such as data minimisation need to be better protocol mitigations such as data minimisation need to be better
understood. understood.
3. Work should continue on progressing the PM threat model 3. Work should continue on progressing the PM threat model document
draft[I-D.barnes-pervasive-problem] discussed in the workshop. [Barnes] discussed in the workshop. Subsequent work on this
topic resulted in the publication of [RFC7624].
4. Later, the IETF may be in a position to start to develop an 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. The community need to possible mitigation strategy for PM. The community needs to
document definition(s) for this term, as it is being used document definition(s) for this term, as it is being used
differently by different people and in different contexts. We differently by different people and in different contexts. We
may also be able to develop a cookbook-like set of related may also be able to develop a cookbook-like set of related
protocol techniques for developers. Since the workshop, the protocol techniques for developers. Since the workshop, the
IETF's security area has taken up this work, most recently IETF's Security area has taken up this work, most recently
favouring the generic term "Opportunistic Security" (OS) favouring the generic term "Opportunistic Security" (OS) [Kent].
[I-D.kent-opportunistic-security]. Subsequent work on this Subsequent work on this topic resulted in the publication of a
topic resulted in the publication of a definition of OS in definition of OS in [RFC7435].
[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 (UIs) could be better in terms of how they 7. Many user interfaces (UIs) 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 coordination among competing software makers;
otherwise some will be considered "broken" by users. otherwise, some will be considered "broken" by users.
8. Further discussion is needed on ways to better integrate UI 8. Further discussion is needed on ways to better integrate UI
issues into the processes of IETF and W3C. 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 pasted 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 [Captive] and some firewalls, too, can and
distinguished from real man-in-the-middle attacks. This might should be distinguished from real man-in-the-middle attacks.
mean establishing common conventions with makers of such This might mean establishing common conventions with makers of
middleboxes, but might also need new protocols. However, the such middleboxes, but might also mean developing new protocols.
incentives for deploying such new middlebox features might not However, the incentives for deploying such new middlebox
align. features might not align.
3. Workshop goals 3. Workshop Goals
As stated, the STRINT workshop started from the position [RFC7258] As stated, the STRINT workshop started from the position [RFC7258]
that PM is an attack. While some dissenting voices are expected and that PM is an attack. While some dissenting voices are expected and
need to be heard, that was the baseline assumption for the workshop, need to be heard, that was the baseline assumption for the workshop,
and the high-level goal was to provide more consideration of that and and the high-level goal was to provide more consideration of that and
how it ought to affect future work within the IETF and W3C. how it ought to affect future work within the IETF and W3C.
At the next level down the goals of the STRINT workshop were to: 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 BCP72. documented for the IETF at least, e.g., via an update to BCP 72.
[7] [RFC3552]
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
would help mitigate PM. that 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 that
help those done within the IETF/W3C. might 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.
These summary presentations took at most 50% of the session and These summary presentations took at most 50% of the session and
usually less. usually less.
Because the papers would not be presented during the workshop, Because the papers would not be presented during the workshop,
participants were asked to read and discuss the papers beforehand, at participants were asked to read and discuss the papers beforehand, at
skipping to change at page 5, line 44 skipping to change at page 5, line 40
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 to The penultimate session consisted of break-outs (which turned out to
be the most productive sessions of all, most likely simply due to the be the most productive sessions of all, most likely simply due to the
smaller numbers of people involved). The subjects for the break-outs smaller numbers of people involved). The subjects for the break-outs
were agreed during the earlier sessions and just before the break-out were agreed during the earlier sessions, and just before the break-
session the participants collectively determined who would attend out session the participants collectively determined who would 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
skipping to change at page 6, line 24 skipping to change at page 6, line 29
Some participants 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, and easy see if their systems conform to a certain level of security, and easy
to remember names are needed for those standards, so that a buyer can 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 calculation of the cost of losing resources vs. the cost of
protecting them is thus different. And unlike someone motivated to protecting them is thus different. And unlike someone motivated to
make money, a PM attacker may not be concerned at the cost of the make money, a PM attacker may not be concerned at the cost of the
attack (or may even prefer a higher cost, for "empire building" attack (or may even prefer a higher cost, for "empire building"
reasons"). 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 mount an attack but 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.
Paradoxically, while larger sites such as Facebook, Yahoo, and Google Paradoxically, while larger sites such as Facebook, Yahoo, and Google
supervise the security of their respective services more than other supervise the security of their respective services more than other
smaller sites, such large sites offer a much more attractive target smaller sites, such large sites offer a much more attractive target
to attack. Avoiding overuse of such repositories for private or to attack. Avoiding overuse of such repositories for private or
sensitive information may be a useful measure that increases the cost sensitive information may be a useful measure that increases the cost
of collecting for a pervasive attacker. This is sometimes called the of collecting for a pervasive attacker. This is sometimes called the
target-dispersal approach. target-dispersal approach.
Lack of interoperability between systems can lead to poorly thought Lack of interoperability between systems can lead to poorly thought
out work-arounds and compromises that may themselves introduce out work-arounds and compromises that may themselves introduce
vulnerabilities. And thus improving interoperability needs to be vulnerabilities. Thus, improving interoperability needs to be high
high on the list of priorities of standards makers and even more for on the list of priorities of standards makers and even more for
implementers. Of course, testing, such as interop testing, is at implementers. Of course, testing (such as interop testing) is, at
some level, part of the process of IETF and W3C; and W3C is currently some level, part of the process of the IETF and W3C; and the W3C is
increasing its testing efforts. currently increasing its testing efforts.
5.3. Increase usage of security tools 5.3. Increase Usage of Security Tools
The first session on Communication Security (COMSEC) tools looked at The first session on Communication Security (COMSEC) tools looked at
the question why existing security tools aren't used more. the question why existing security tools aren't used more.
The example of the public key infrastructure used to secure HTTP is The example of the public key infrastructure used to secure HTTP is
informative. One problem is that certificate authorities (CAs) may informative. One problem is that certification authorities (CAs) may
issue a certificate for any domain. Thus a single compromised CA can issue a certificate for any domain. Thus, a single compromised CA
be used in combination with a MITM to impersonate any server. can be used in combination with a MITM to impersonate any server.
Moreover, ongoing administration, including requesting, paying for Moreover, ongoing administration, including requesting, paying for,
and installing new certificates, has proven over time to be an and installing new certificates, has proven over time to be an
insurmountable barrier for many web site administrators, leading them insurmountable barrier for many web site administrators, leading them
not to bother to secure their systems. not to bother to secure their systems.
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"
transparency": a public, permanent log of who issued which -- 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. PGP demonstrates a alternative or in combination) may also help. Pretty Good Privacy
model known as a "web of trust" where people verify the public key of (PGP) demonstrates a model known as a "web of trust" where people
the people they meet. Because there is no innate transitive trust in verify the public key of the people they meet. Because there is no
PGP, it is appropriate only for small scale uses; an example being a innate transitive trust in PGP, it is appropriate only for small-
team of people working on a project. scale uses; an example is a team of people working on a project.
Yet another model is "trust on first use" (TOFU). This is used quite Yet another model is "trust on first use" (TOFU). This is used quite
effectively by SSH [RFC4252]. On the first connection, one has no effectively by SSH [RFC4252]. On the first connection, one has no
way to verify that the received public key belongs to the server one way to verify that the received public key belongs to the server one
is contacting, therefore, the key is accepted without further is contacting, therefore, the key is accepted without further
verification. But on the subsequent connections, one can verify that verification. But on the subsequent connections, one can verify that
the received key is the same key as the first time. So a MITM has to the received key is the same key as the first time. So, a MITM has
be there on all connections, including the first, otherwise it will to be there on all connections, including the first; otherwise, it
be detected by a key mismatch. will be detected by a key mismatch.
This works well for SSH, because people typically use SSH to This works well for SSH, because people typically use SSH to
communicate with a small number of servers over and over again. And, communicate with a small number of servers over and over again. And,
if they want, they may find a separate channel to get the public key if they want, they may find a separate channel to get the public key
(or its fingerprint). It may also work for Web servers used by small (or its fingerprint). It may also work for web servers used by small
groups (the server of a sports club, a department of a company, groups (the server of a sports club, a department of a company,
etc.), but probably works less well for public servers that are etc.), but probably works less well for public servers that are
visited once or a few times or for large services where many servers visited once or a few times or for large services where many servers
may be used. may be used.
A similar proposal [draft-ietf-websec-key-pinning] for an HTTP header A similar proposal [RFC7469] for an HTTP header introduces an aspect
introduces an aspect of TOFU into HTTP: Key pinning tells HTTP of TOFU into HTTP: Key pinning tells HTTP clients that for a certain
clients that for a certain time after receiving this certificate, time after receiving this certificate, they should not expect the
they should not expect the certificate to change. If it does, even certificate to change. If it does, even if the new certificate looks
if the new certificate looks valid, the client should assume a valid, the client should assume a security breach.
security breach.
Session Initiation Protocol (SIP) [RFC3261] can require several The Session Initiation Protocol (SIP) [RFC3261] can require several
different intermediaries in different stages of the communication to different intermediaries in different stages of the communication to
deal with NAT traversal and to handle policy. While both hop-by-hop deal with NAT traversal and to handle policy. While both hop-by-hop
and end-to-end encryption are specified, in practice many SIP and end-to-end encryption are specified, in practice, many SIP
providers disable these functions. The reasons for disabling end-to- providers disable these functions. The reasons for disabling end-to-
end security here are understandable: to overcome lack of end security here are understandable: to overcome lack of
interoperability they often need to change protocol headers and interoperability they often need to change protocol headers and
modify protocol data. Some workshop participants argued that SIP modify protocol data. Some workshop participants argued that SIP
would never have taken off if it hadn't been possible for providers would never have taken off if it hadn't been possible for providers
to monitor and interfere in communications in this way. Of course, to monitor and interfere in communications in this way. Of course,
that means an attacker can listen in just as easily. that means an attacker can listen in just as easily.
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 reuses 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[RFC6120] suffers from yet another problem. It has encryption XMPP [RFC6120] suffers from yet a different kind of problem. It has
and authentication, and the OTR ("off the record") extension even encryption and authentication, and the OTR ("off the record")
provides what is called Perfect Forward Secrecy (PFS, compromising extension even provides what is called Perfect Forward Secrecy (PFS),
the current communication never gives an attacker enough information i.e., compromising the current communication never gives an attacker
to decrypt past communications that he may have recorded). But, in enough information to decrypt past communications that he may have
practice, many people don't use XMPP at all, but rather Skype, recorded. But, in practice, many people don't use XMPP at all, but
WhatsApp or other instant-messaging tools with unknown or no rather Skype, WhatsApp, or other instant-messaging tools with unknown
security. The problem here seems to be one of user awareness. And or no security. The problem here seems to be one of user awareness.
though OTR does provide security, it is not well integrated with XMPP And though OTR does provide security, it is not well integrated with
and nor is it available as a core feature of XMPP clients. XMPP, 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
clear: not clear:
o Improvements to the certificate system, such as certificate o Improvements to the certificate system, such as certificate
transparency (CT). 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
Security may be one model for that. Security may be one model for that.
5.4. Policy issues and non-technical actions 5.4. Policy Issues and Non-technical Actions
Previous sessions already concluded that the problem isn't just Previous sessions already concluded that the problem isn't just
technical, such as getting the right algorithms in the standards, technical, such as getting the right algorithms in the standards,
fixing interoperability, or educating implementers and systems fixing interoperability, or educating implementers and systems
administrators. There are user interface issues and education issues administrators. There are user interface issues and education issues
too. And there are also legal issues and policy issues for too. And there are also legal issues and policy issues for
governments. governments.
It appears that the public in general demand more privacy and It appears that the public, in general, demands 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
be as privacy-friendly as possible. to 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 the IETF and W3C have
ethics committee? Standards such as the Geolocation API an ethics committee? 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 [Barnes]
paper 44 [8]) explains, PM doesn't just monitor the networks, but (which was included as paper 44) explains, PM doesn't just monitor
also attacks at the endpoints, turning organisations or people into the networks, but also attacks at the endpoints, turning
(willing, unwilling, or unwitting) collaborators. One technical organisations or people into (willing, unwilling, or unwitting)
means of protection is thus to design protocols such that there are collaborators. Note: that document later evolved into [RFC7624].
fewer potential collaborators, e.g., a provider of cloud storage One technical means of protection is thus to design protocols such
cannot hand over plaintext for content that is encrypted with a key that there are fewer potential collaborators, e.g., a provider of
he doesn't have, and cannot hand over names if his client is cloud storage cannot hand over plaintext for content that is
anonymous. encrypted with a key he doesn't have, and cannot hand over names if
his client is anonymous.
It is important to distinguish between PM and fighting crime. PM is It is important to distinguish between PM and fighting crime. PM is
an attack, but a judge ordering the surveillance of a suspected an attack, but a judge ordering the surveillance of a suspected
criminal is not. The latter, often abbreviated in this context as LI criminal is not. The latter, often abbreviated in this context as LI
(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) [Kent]. The idea is that software is enhanced with a
software is enhanced with a module that tries to encrypt module that tries to encrypt communications when it detects that the
communications when it detects that the other end also has the same other end also has the same capability, but otherwise it lets the
capability but otherwise lets the communication continue in the old communication continue in the old way. The detailed definition of OS
way. The detailed definition of OS is being discussed by the IETF was being discussed by the IETF Security Area Advisory Group at the
security area at the time of this workshop [saag]. time of this workshop [SAAG_list].
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
was agreement at the workshop that such user interface features ought was agreement at the workshop that such user interface features ought
not be changed because OS is being used. not be changed because OS is being used.
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
skipping to change at page 11, line 28 skipping to change at page 11, line 34
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
of the UI, user understanding, and user experience. For an of the UI, user understanding, and user experience. For an
e-commerce site, e.g., it is not just important that the user's data e-commerce site, e.g., it is not just important that the user's data
is technically safe, but also that he feels secure. Otherwise he is technically safe, but also that he feels secure. Otherwise, he
still won't buy anything. still won't buy anything.
When talking about users, we also need to distinguish the end user When talking about users, we also need to distinguish the end user
(who we typically think about when we talk about UI) from the server (who we typically think about when we talk about UI) from the server
administrators and other technical people involved in enabling a administrators and other technical people involved in enabling a
connection. When something goes wrong (e.g., the user's software connection. When something goes wrong (e.g., the user's software
detects an invalid certificate), the message usually goes to the end detects an invalid certificate), the message usually goes to the end
user. But he isn't necessarily the person who can do something about user. But, he isn't necessarily the person who can do something
it. E.g., if the problem is a certificate that expired yesterday, about it. For example, if the problem is a certificate that expired
the options for the user are to break the connection (the safe yesterday, the options for the user are to break the connection (the
choice, but it means he can't get his work done) or continue anyway safe choice, but it means he can't get his work done) or continue
(there could be a MITM...). The server administrator, on the other anyway (there could be a MITM). The server administrator, on the
hand, could actually solve the problem. other 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 setup 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 user agents important to know that it is the real data. Most mail user agents
(UA) already provide independent options for encryption and signing, (UA) already provide independent options for encryption and signing,
but Web 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 email 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 It also has to be kept in mind that encrypting only the "sensitive"
"sensitive" data and not the rest decreases the cost for an attacker, data and not the rest decreases the cost for an attacker, too: It
too: It becomes easy to know which connections are worth attacking. 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
content, an attacker would rather attempt to steal the keys, corrupt content, an attacker would rather attempt to steal the keys, corrupt
the encoding software, or get the content via a collaborator.) But the encoding software, or get the content via a collaborator. See
encrypting the content doesn't hide the fact that you are [RFC7624] for more information on "collaborator".) But encrypting
communicating. This metadata (who talks to whom, when and for how the content doesn't hide the fact that you are communicating. This
long) is often as interesting as the content itself, and in some metadata (who talks to whom, when, and for how long) is often as
cases the size and timing of messages is even an accurate predictor interesting as the content itself, and in some cases the size and
of the content. So how to stop an attacker from collecting metadata, timing of messages is even an accurate predictor of the content. So
given that much of that data is actually needed by routers and other how to stop an attacker from collecting metadata, given that much of
services to deliver the message to the right place? that data is actually needed by routers and other services to deliver
the message to the right place?
It is useful to distinguish different kinds of metadata: explicit (or 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 such as 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 it 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 4 harder to get: aggregation, contraflow, and multipath (see "Flows and
[9]). New protocols should be designed such that these measures are Pervasive Monitoring" [Paper4]). New protocols should be designed
not inadvertently disallowed, e.g., because the design assumes that such that these measures are not inadvertently disallowed, e.g.,
the whole of a conversation passes through the same route. because the design assumes that 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. For example, if HTTP connections pass through a
the conversations appear to come from the proxy instead of from their proxy, all the conversations appear to come from the proxy instead of
original sources. (This assumes that telltale information in the from their original sources. (This assumes that telltale information
headers is stripped by the proxy, or that the connection is in the 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., sending conversations) and routes the parts in different ways, e.g., sending
a request via a satellite link and receiving the response via a land a request via a satellite link and receiving the response via a land
line; or starting a conversation on a cellular link and continuing it line, or starting a conversation on a cellular link and continuing it
via Wi-Fi. This again increases the cost for an attacker, who has to via Wi-Fi. This again increases the cost for an attacker, who has to
monitor and correlate multiple networks. monitor and correlate data traversing 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 to One thing that can be done relatively easily in the short term is to
go through existing protocols to check what data they send that isn't go through existing protocols to check what data they send that isn't
really necessary. One candidate mentioned for such a study was XMPP. really necessary. One candidate mentioned for such a study was 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 [RFC6973]: Clients can be recognised
grouped) because their messages always have a combination of features (or at least grouped) because their messages always have a
that other clients do not have. Reducing redundant metadata and combination of features that other clients' messages do not have.
reducing the number of optional features in a protocol reduces the Reducing redundant metadata and reducing the number of optional
variation between clients and thus makes fingerprinting harder. features in a protocol reduces the 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 that are little known among protocol developers.
developers. Some collections of results are Some collections of results are
o A selected bibliography on anonymity [10] by the Free Haven o a selected bibliography on anonymity by the Free Haven Project
Project, <http://freehaven.net/anonbib/>,
o The yearly Symposium on Privacy Enhancing Technologies (PETS) o the yearly Symposium on Privacy Enhancing Technologies (PETS)
[11], and <http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>,
and
o The yearly Workshop on Privacy in the Electronic Society (WPES) o the yearly Workshop on Privacy in the Electronic Society (WPES)
[12]. <http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html>.
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 traffic analysis. 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, for example, has a built-
mechanism. However, it is not so easy to use these techniques well, in padding mechanism. However, it is not easy to use these
and not actually make messages easier to recognise rather than techniques well and make messages harder to recognise (as intended)
harder. rather than easier.
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.
In practice, however, people have more or less valid reasons to In practice, however, people have more or less valid reasons to
insist on intermediaries: companies filtering incoming and outgoing insist on intermediaries: companies filtering incoming and outgoing
traffic for viruses or other reasons, giving priority to certain traffic for viruses, inspecting content to give priority to certain
communications or caching to reduce bandwidth. applications, or caching content 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: use fake certificates to impersonate intermediaries have two choices: use fake certificates to impersonate
the endpoints or have access to the private keys of the endpoints. the endpoints or have access to the private keys of the endpoints.
The former is a MITM attack that is difficult to distinguish from a The former is a MITM attack that is difficult to distinguish from a
more malicious one, and the latter obviously decreases the security more malicious one, and the latter obviously decreases the security
of the endpoints by copying supposedly protected data and of the endpoints by copying supposedly confidential information and
concentrating such data in a single place. concentrating credentials 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, it 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 user needs to be identified, that
is mainly done at the application layer via passwords or cookies.) is mainly done at the application layer via username and password.)
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 do If the client doesn't immediately close the connection (which they do
not in many cases), the server may thus disclose information that the not in many cases), the server may thus disclose information that 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 Wi-Fi 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 applications, it may be a while page. With the increasing use of applications, it may be a while
before the user actually opens a browser. The flood of error before the user actually opens a browser. The flood of error
messages may also have as a result that the user no longer reads the messages may also have as a result that the user no longer reads the
errors, allowing 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. Something like an shouldn't have to do MITM attacks to be noticed. A mechanism at the
extension to DHCP that tells a connecting device about the login page link layer or an extension to DHCP that tells a connecting device
may help, although that still doesn't solve the problem for devices about the login page may help, although that still doesn't solve the
that do not have a Web browser, such as game consoles or SIP phones. problem for devices that do not have a web browser, such as voice
HTTP response code 511 (defined in [RFC6585]) is another attempt at a over IP phones. HTTP response code 511 (defined in [RFC6585]) is
partial solution (Partial, because it can only work at the moment the another attempt at a partial solution. (It's partial because it can
user uses a browser to connect to a Web site and doesn't use HTTPS). only work at the moment the user uses a browser to connect to a web
site and doesn't use HTTPS.)
A practical problem with deployment of such a protocol may be that 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 relationship between security research and standardisation that the relationship between security research and standardisation
needs improvement. Research on linkability is not yet well known in needs improvement. Research on linkability is not yet well known in
the IETF. But the other side of the coin needs improvement too: the IETF. But, the other side of the coin needs improvement too:
While doing protocol design, standardisation should indicate what While doing protocol design, standardisation organisations should
specific problems are in need of more research. indicate what 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 nonexhaustive 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 ("Compression Ratio Info-leak Made Easy") SSL/TLS
vulnerability [Ristic]
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" o How to better obfuscate so-called "metadata"
o How to make the 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
many others. are many others.
Other common case of "false" alarms for MITM (after captive portals) Other common cases of "false" alarms for MITM (after captive portals)
include expired and mis-configured certificates. This is quite include expired and misconfigured certificates. This is quite common
common in intranets, when the sysadmin hasn't bothered updating a 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.
One way to get rid of such certificates is if client software no One way to get rid of such certificates is if client software no
longer offers the option to continue after a certificate error. That longer offers the option to continue after a certificate error. That
requires that all major clients (such as browsers) change their requires that all major clients (such as browsers) change their
behaviour at the same time, otherwise the first one to do so will be behaviour at the same time; otherwise, the first one to do so will be
considered broken by users, because the others still work. Also it considered broken by users, because the others still work. Also, it
requires a period in which that software gives increasingly strong requires a period in which that software gives increasingly strong
warnings about the cut-off date after which the connection will fail warnings about the cut-off date after which the connection will fail
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 web
it shouldn't cause such scary warnings. There may be ways to improve site, it shouldn't cause such scary warnings. There may be ways to
the explanations in the error message and provide an easy way to improve the explanations in the error message and provide an easy way
verify the certificate (by e-mail, over the phone or some other to verify the certificate (by email, phone, or some other channel)
channel) and trust it. 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
rather than MAY. This is sometimes referred to as Mandatory To standard rather than "MAY". This is sometimes referred to as
Implement (MTI) and is the current practice for IETF Mandatory To Implement (MTI) and is the current practice for IETF
protocols[RFC3365]. 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
that some security features are implemented but interoperability for be that some security features are implemented, but interoperability
those doesn't really work. Or, even worse, it may be that protocol for those doesn't really work. Or, even worse, it may be that
designers have only followed the letter of the MTI best practice and protocol designers have only followed the letter of the MTI best
not its spirit, with the result that security features are hard to practice and not its spirit, with the result that security features
use or make deployment harder. One can thus argue that such features are hard to use or make deployment harder. One can thus argue that
should be defined to be on by default. such features 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 Mandatory To Use (MTU). sometimes called Mandatory To Use (MTU).
The question raised at this session was for what protocols on-by- The questions raised at this session were for what protocols is on-
default is appropriate, and how can one explain to the developers of by-default appropriate, and how can one explain to the developers of
such protocols that it is needed? such protocols that it is needed?
There would of course be resistance to MTU security from implemeters Of course, there would be resistance to MTU security from
and deployments that practice deep packet inspection (DPI) and also implementers and deployments that practice deep packet inspection
perhaps from some governments. On the other hand, there may also be (DPI) and also perhaps from some governments. On the other hand,
governments that outlaw protocols without proper encryption. there may also be 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 it 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. encourage or gamify the increased use of security mechanisms.
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 cryptographic security and attempted to progress the work applies to cryptographic security and attempted to progress the work
towards arriving at an agreed-upon definition for use of that term, towards arriving at an agreed-upon definition for use of that term,
at it 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
a move to the term "Opportunistic Security" (OS). in a move to the term "Opportunistic Security" (OS).
Aside from terminology, disussion focused on the use of Diffie- Aside from terminology, discussion focused on the use of Diffie-
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 mutual) 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 mitigation 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 LEDBAT
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 flow. In IPv6, this can be done via different IPv6 different flow. In IPv6, this can be done via different IPv6
flow labels. For IPv4, this can be done by encapsulating the IP flow labels. For IPv4, this can be done by encapsulating the IP
packet into UDP and varying the UDP source 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 the Reverse Path Forwarding(RPF)[RFC3704] check problem can be e. If the Reverse Path Forwarding (RPF) [RFC3704] check problem can
fixed, perhaps the source could be hidden, however it assumes the be fixed, perhaps the source could be hidden; however, such fixes
trafic is within trusted perimeters. assume the traffic 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 it
also has different costs (longer latency, new transport protocol has different costs (longer latency, new transport protocol
usage) to its users. usage) to its users.
The idea of encrypting traffic from customer edge (CE) to CE as part The idea of encrypting traffic from Customer Edge (CE) to CE as part
of an L3VPN or such was also discussed. This could allow hiding of of an L3VPN or such was also discussed. This could allow hiding of
addresses, including source, and headers. From conversation with Ron addresses, including source, and headers. From conversation with Ron
Bonica, some customers already do encryption (though not hiding the Bonica, it's clear that some customers already do encryption (though
source address) like this. So, it is unclear that this is very without hiding the source address). So, rather than an enhancement,
practically useful as an enhancement except for encouraging this is an existing mechanism for which deployment and use can be
deployment and use. encouraged.
Finally, it was discussed whether it would be useful to have a means Finally, it was discussed whether it would be useful to have a means
of 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.
IETF Working groups meeting in London took the recommendations from IETF working groups meeting in London took the recommendations from
the workshop into account. It was even the first item in the report the workshop into account. It was even the first item in the 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" [Pouwelse].
7. IANA considerations
There are none. We hope the RFC editor deletes this section.
8. Security considerations
This document does not define a technology but is all about security 7. Security Considerations
and privacy.
9. References This document is all about security and privacy.
9.1. Informative references 8. 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.) [Barnes] Barnes, R., Schneier, B., Jennings, C., and T. Hardie,
"Pervasive Attack: A Threat Model and Problem Statement",
[draft-ietf-websec-key-pinning] Work in Progress, draft-barnes-pervasive-problem-00,
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning January 2014.
Extension for HTTP", February 2014.
(Work in progress.)
[draft-pouwelse-perpass-shadow-internet] [Captive] Wikipedia, "Captive portal", October 2015,
Pouwelse, J., Ed., "The Shadow Internet: liberation from <https://en.wikipedia.org/w/
Surveillance, Censorship and Servers", February 2014, index.php?title=Captive_portal&oldid=685621201>.
<https://datatracker.ietf.org/doc/draft-pouwelse-perpass-
shadow-internet/>.
(Work in progress.) [Kent] Kent, S., "Opportunistic Security as a Countermeasure to
Pervasive Monitoring", Work in Progress, draft-kent-
opportunistic-security-01, April 2014.
[I-D.barnes-pervasive-problem] [Paper4] Hardie, T., "Flows and Pervasive Monitoring",
Barnes, R., Schneier, B., Jennings, C., and T. Hardie, STRINT Workshop, 2014,
"Pervasive Attack: A Threat Model and Problem Statement", <https://www.w3.org/2014/strint/papers/4.pdf>.
draft-barnes-pervasive-problem-01 (work in progress), July
2014.
[I-D.kent-opportunistic-security] [Pouwelse] Pouwelse, J., "The Shadow Internet: liberation from
Kent, S., "Opportunistic Security as a Countermeasure to Surveillance, Censorship and Servers", Work in Progress,
Pervasive Monitoring", draft-kent-opportunistic- draft-pouwelse-perpass-shadow-internet-00, February 2014.
security-01 (work in progress), 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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[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 3365, DOI 10.17487/RFC3365, August 2002, RFC 3365, DOI 10.17487/RFC3365, August 2002,
skipping to change at page 22, line 44 skipping to change at page 22, line 47
[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 4322, DOI 10.17487/RFC4322, December 2005, RFC 4322, DOI 10.17487/RFC4322, December 2005,
<http://www.rfc-editor.org/info/rfc4322>. <http://www.rfc-editor.org/info/rfc4322>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>. March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[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, DOI 10.17487/RFC6585, April 2012,
<http://www.rfc-editor.org/info/rfc6585>.
[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,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. <http://www.rfc-editor.org/info/rfc6817>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <http://www.rfc-editor.org/info/rfc6962>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[saag] Area, S., "IETF Security Area mailing list", March 2014, [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
<https://www.ietf.org/mail-archive/web/saag/current/ Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
maillist.html>. 2015, <http://www.rfc-editor.org/info/rfc7469>.
[vancouverplenary]
IETF, , "IETF 88 Technical Plenary Minutes",
<http://www.ietf.org/proceedings/88/minutes/
minutes-88-iab-techplenary>.
[w3c-geo-api]
Popescu, A., "Geolocation API Specification", October
2013, <http://www.w3.org/TR/geolocation-API/>.
9.2. URIs
[1] http://www.w3.org/
[2] https://www.iab.org/
[3] https://www.w3.org/2014/strint/Overview.html
[4] https://www.ietf.org/meeting/89/index.html
[5] http://www.strews.eu/
[6] https://en.wikipedia.org/wiki/Captive_portal
[7] http://tools.ietf.org/html/bcp72
[8] https://www.w3.org/2014/strint/papers/44.pdf
[9] https://www.w3.org/2014/strint/papers/04.pdf
[10] http://freehaven.net/anonbib/
[11] http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html
[12] http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html
[13] https://community.qualys.com/blogs/securitylabs/2012/09/14/crime
-information-leakage-attack-against-ssltls
[14] http://www.strews.eu/
[15] http://cordis.europa.eu/fp7/ict/
[16] http://blog.digital.telefonica.com/
[17] https://www.ietf.org/meeting/89/index.html
[18] http://lists.i1b.org/pipermail/strint-attendees-i1b.org/
[19] https://www.w3.org/2014/strint/
[20] https://twitter.com/search?q=%23strint
[21] http://www.w3.org/2014/02/28-strint-minutes.html
[22] http://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf
[23] http://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf
[24] http://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf
[25] http://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf
[26] http://www.w3.org/2014/03/01-strint-minutes.html
[27] http://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf
[28] http://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf
[29] http://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf
[30] http://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<http://www.rfc-editor.org/info/rfc7624>.
[31] http://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf [Ristic] Ristic, I., "CRIME: Information Leakage Attack against
SSL/TLS", Qualys Blog,
<https://community.qualys.com/blogs/securitylabs/2012/
09/14/crime-information-leakage-attack-against-ssltls>.
[32] https://www.w3.org/2014/strint/slides/summary.pdf [SAAG_list]
IETF, "saag Discussion Archive", <https://www.ietf.org/
mail-archive/web/saag/current/maillist.html>.
[33] https://www.cs.tcd.ie/Stephen.Farrell/ [STRINT] W3C/IAB, "STRINT Workshop",
<https://www.w3.org/2014/strint/Overview.html>.
[34] http://www.w3.org/People/Rigo/ [vancouverplenary]
IETF, "IETF 88 Technical Plenary Minutes",
<https://www.ietf.org/proceedings/88/minutes/
minutes-88-iab-techplenary>.
[35] http://www.tschofenig.priv.at/wp/?page_id=5 [w3c-geo-api]
Popescu, A., "Geolocation API Specification",
W3C Recommendation, October 2013,
<http://www.w3.org/TR/geolocation-API/>.
Appendix A. Logistics Appendix A. Logistics
The workshop was organised by the STREWS [14] project (a research The workshop was organised by the STREWS project
project funded under the European Union's 7th Framework Programme (<https://www.strews.eu/>), which is a research project funded under
[15]), as the first of two workshops in its work plan. The the European Union's 7th Framework Programme
organisers were supported by the IAB and W3C, and, for the local (<http://cordis.europa.eu/fp7/ict/>). It was the first of two
organisation, by Telefonica Digital. [16] workshops in its work plan. The organisers were supported by the IAB
and W3C, and, for the local organisation, by Telefonica Digital
(<http://blog.digital.telefonica.com/>).
One of the suggestions in the project description of the STREWS 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 [17] in London, which would begin on best opportunity was IETF 89 in London, which began on Sunday 2 March
Sunday March 2, 2014. Telefonica Digital offered meeting rooms at 2014; see <https://www.ietf.org/meeting/89/> for more information.
its offices in central London for the preceding Friday and Saturday, Telefonica Digital offered meeting rooms at its offices in central
just minutes away from the IETF's location. London for the preceding Friday and Saturday, just minutes away from
the IETF's location.
The room held 100 people, which was thought to be sufficient. There 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.
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 helping 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 [19]. also used on the workshop's web site:
<https://www.w3.org/2014/strint/>.
o A "Twitter hashtag" (#strint). Four weeks after the workshop, o A Twitter hashtag (#strint). Four weeks after the workshop, there
there were still a few new messages [20] about events related to were still a few new messages about events related to workshop
workshop topics. topics; see <https://twitter.com/search?q=%23strint>.
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 [21] Minutes: <http://www.w3.org/2014/02/28-strint-minutes.html>
Workshop starts, welcome, logistics, opening/overview [slides] Workshop starts, welcome, logistics, opening/overview
[22] Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf>
* Goal is to plan how we respond to PM threats o Goal is to plan how we respond to PM threats
* Specific questions to be discussed in sessions o Specific questions to be discussed in sessions
* Outcomes are actions for IETF, W3C, IRTF, etc. o Outcomes are actions for IETF, W3C, IRTF, etc.
I. Threats - What problem are we trying to solve? (Presenter: I. Threats - What problem are we trying to solve?
Richard Barnes; Moderator: Cullen Jennings) [slides] [23] (Presenter: Richard Barnes; Moderator: Cullen Jennings)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf>
* What attacks have been described? (Attack taxonomy) * What 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)
II. COMSEC 1 - How can we increase usage of current COMSEC tools? II. COMSEC 1 - How can we increase usage of current COMSEC tools?
(Presenter: Hannes Tschofenig; Moderator: Leif Johansson) [slides] (Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
[24] Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf>
* 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 /
they used? aren't 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?
III. Policy - What policy / legal/ other issues need to be taken III. Policy - What policy/legal/other issues need to be taken into
into account? (Presenter: Christine Runnegar; Moderator: Rigo account? (Presenter: Christine Runnegar; Moderator: Rigo
Wenning) [slides] [25] Wenning)
* What non-technical activities do we need to be aware of? Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf>
* How might such non-technical activities impact on IETF/W3C? * What non-technical activities do we need to be aware of?
* How might IETF/W3C activities impact on those non-technical * How might such non-technical activities impact on IETF/W3C?
activities?
Session IV - Saturday plan, open-mic, wrap up day * How might IETF/W3C activities impact those non-technical
activities?
Saturday plan, open mic, wrap-up of the day
B.2. Saturday 1 March B.2. Saturday 1 March
Minutes [26] Minutes: <http://www.w3.org/2014/03/01-strint-minutes.html>
IV. COMSEC 2 - What improvements to COMSEC tools are IV. COMSEC 2 - What improvements to COMSEC tools are needed?
needed?(Presenter: Mark Nottingham; Moderator: Steve Bellovin) (Presenter: Mark Nottingham; Moderator: Steve Bellovin)
[slides] [27] Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf>
* 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?
V. Metadata - How can we reduce the metadata that protocols V. Metadata - How can we reduce the metadata that protocols expose?
expose? (Presenter: Alfredo Pironti [slides] [28] / Ted Hardie (Presenters: Alfredo Pironti, Ted Hardie; Moderator: Alissa
[slides] [29]; Moderator: Alissa Cooper [slides] [30]) Cooper)
* Meta-data, fingerprinting, minimisation Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf>
* What's out there? * Metadata, fingerprinting, minimisation
* How can we do better? * What's out there?
VI. Deployment - How can we address PM in deployment / * How can we do better?
operations? (Presenter: Eliot Lear; Moderator: Barry Leiba)
[slides] [31]
* "Mega"-commercial services (clouds, large scale email & SN, VI. Deployment - How can we address PM in deployment / operations?
SIP, WebRTC...) (Presenter: Eliot Lear; Moderator: Barry Leiba)
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf>
* Target dispersal - good goal or wishful thinking? * "Mega"-commercial services (clouds, large-scale email and
Online Social Networks, SIP, WebRTC)
* Middleboxes: when a help and when a hindrance? * Target dispersal - good goal or wishful thinking?
VII. 3 x Break-out Sessions / Bar-Camp style (Hannes Tschofenig) * Middleboxes: when a help and when a hindrance?
* Content to be defined during meeting, as topics come up VII. Break-out Sessions (x 3) / Bar-Camp style (Hannes Tschofenig)
* Sum up at the end to gather conclusions for report * Content to be defined during meeting, as topics come up
Break-outs:
1. Research Questions (Moderator: Kenny Paterson) * Sum up at the end to gather conclusions for report
+ Do we need more/different crypto tools? Break-outs:
+ How can applications make better use of COMSEC tools? 1. Research Questions (Moderator: Kenny Paterson)
+ What research topics could be handled in IRTF? + Do we need more/different crypto tools?
+ What other research would help? + How can applications make better use of COMSEC tools?
2. clients + What research topics could be handled in IRTF?
3. on by default + What other research would help?
4. measuring 2. Clients
5. opportunistic 3. On by default
VIII. Break-out reports, Open mic & Conclusions - What are we 4. Measurement
going to do to address PM? [slides] [32]
* Gather conclusions / recommendations / goals from earlier 5. Opportunistic
sessions
Appendix C. Workshop chairs & program committee VIII. Break-out Reports, Open Mic & Conclusions - What are we going
to do to address PM?
Slides: <https://www.w3.org/2014/strint/slides/summary.pdf>
The workshop chairs were three: Stephen Farrell [33] (TCD) and Rigo * Gather conclusions / recommendations / goals from earlier
Wenning [34] (W3C) from the STREWS project, and Hannes Tschofenig sessions
[35] (ARM) from the STREWS Interest Group.
A program committee (PC) was charged with evaluating the submitted Appendix C. Workshop Chairs and Program Committee
papers. It was made up of the members of the STREWS project, the
members of the STREWS Interest Group, plus invited experts: Bernard The workshop chairs were three: Stephen Farrell (TCD) and Rigo
Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard Wenning (W3C) from the STREWS project, and Hannes Tschofenig (ARM)
Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen from the STREWS Interest Group.
O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP),
Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal The Technical Programme Committee (TPC) was charged with evaluating
Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler the submitted papers. It was made up of the members of the STREWS
(Microsoft) and Sean Turner (IECA). project, the members of the STREWS Interest Group, plus invited
experts: Bernard Aboba (Microsoft), Dan Appelquist (Telefonica & W3C
TAG), Richard Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU
Leuven), Karen O'Donoghue (ISOC), Russ Housley (Vigil Security),
Martin Johns (SAP), Ben Laurie (Google), Eliot Lear (Cisco), Kenny
Paterson (Royal Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C),
Dave Thaler (Microsoft), and Sean Turner (IECA).
Appendix D. Participants Appendix D. 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 Jari Arkko (Ericsson)
o Alia Atlas (Juniper Networks) o Alia Atlas (Juniper Networks)
o Emmanuel Baccelli (INRIA) o Emmanuel Baccelli (INRIA)
o Mary Barnes o Mary Barnes
o Richard Barnes (Mozilla) o Richard Barnes (Mozilla)
o Steve Bellovin (Columbia University) o Steve Bellovin (Columbia University)
o Andrea Bittau (Stanford University) o Andrea Bittau (Stanford University)
o Marc Blanchet (Viagenie) o Marc Blanchet (Viagenie)
o Carsten Bormann (Uni Bremen TZI) o Carsten Bormann (Uni Bremen TZI)
o Bert Bos (W3C) o Bert Bos (W3C)
o Ian Brown (Oxford University) o Ian Brown (Oxford University)
o Stewart Bryant (Cisco Systems) o Stewart Bryant (Cisco Systems)
o Randy Bush (IIJ / Dragon Research Labs) o Randy Bush (IIJ / Dragon Research Labs)
o Kelsey Cairns (Washington State University) o Kelsey Cairns (Washington State University)
o Stuart Cheshire (Apple) o Stuart Cheshire (Apple)
o Vincent Cheval (University of Birmingham) o Vincent Cheval (University of Birmingham)
o Benoit Claise (Cisco) o Benoit Claise (Cisco)
o Alissa Cooper (Cisco) o Alissa Cooper (Cisco)
o Dave Crocker (Brandenburg InternetWorking) o Dave Crocker (Brandenburg InternetWorking)
o Leslie Daigle (Internet Society) 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 Dan Druta (AT&T)
o Peter Eckersley (Electronic Frontier Foundation) o Peter Eckersley (Electronic Frontier Foundation)
o Lars Eggert (NetApp) o Lars Eggert (NetApp)
o Kai Engert (Red Hat) o Kai Engert (Red Hat)
o Monika Ermert o Monika Ermert
o Stephen Farrell (Trinity College Dublin) o Stephen Farrell (Trinity College Dublin)
o Barbara Fraser (Cisco) o Barbara Fraser (Cisco)
o Virginie Galindo (gemalto) o Virginie Galindo (gemalto)
o Stefanie Gerdes (Uni Bremen TZI) o Stefanie Gerdes (Uni Bremen TZI)
o Daniel Kahn Gillmor (ACLU) o Daniel Kahn Gillmor (ACLU)
o Wendy M. Grossman
o Wendy M. Grossman
o Christian Grothoff (The GNUnet Project) o Christian Grothoff (The GNUnet Project)
o Oliver Hahm (INRIA) o Oliver Hahm (INRIA)
o Joseph Lorenzo Hall (Center for Democracy & Technology) o Joseph Lorenzo Hall (Center for Democracy & Technology)
o Phillip Hallam-Baker o Phillip Hallam-Baker
o Harry Halpin (W3C/MIT and IRI) o Harry Halpin (W3C/MIT and IRI)
o Ted Hardie (Google) o Ted Hardie (Google)
o Joe Hildebrand (Cisco Systems) o Joe Hildebrand (Cisco Systems)
o Russ Housley (Vigil Security, LLC) o Russ Housley (Vigil Security, LLC)
o Cullen Jennings (CISCO) 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 Steve Kent (BBN Technologies)
o Achim Klabunde (European Data Protection Supervisor) o Achim Klabunde (European Data Protection Supervisor)
o Hans Kuhn (NOC) o Hans Kuhn (NOC)
o Christian de Larrinaga o Christian de Larrinaga
o Ben Laurie (Google) o Ben Laurie (Google)
o Eliot Lear (Cisco Ssytems) o Eliot Lear (Cisco Ssytems)
o Barry Leiba (Huawei Technologies) o Barry Leiba (Huawei Technologies)
o Sebastian Lekies (SAP AG) o Sebastian Lekies (SAP AG)
o Orit Levin (Microsoft Corporation) o Orit Levin (Microsoft Corporation)
o Carlo Von LynX (#youbroketheinternet) o Carlo Von LynX (#youbroketheinternet)
o Xavier Marjou (Orange) o Xavier Marjou (Orange)
o Larry Masinter (Adobe) o Larry Masinter (Adobe)
o John Mattsson (Ericsson) o John Mattsson (Ericsson)
o Patrick McManus (Mozilla) o Patrick McManus (Mozilla)
o Doug Montgomery (NIST) o Doug Montgomery (NIST)
o Kathleen Moriarty (EMC) o Kathleen Moriarty (EMC)
o Alec Muffett (Facebook) o Alec Muffett (Facebook)
o Suhas Nandakumar (Cisco Systems) o Suhas Nandakumar (Cisco Systems)
o Linh Nguyen (ERCIM/W3C) o Linh Nguyen (ERCIM/W3C)
o Linus Nordberg (NORDUnet) 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 Jon Peterson (Neustar)
o Joshua Phillips (University of Birmingham) o Joshua Phillips (University of Birmingham)
o Alfredo Pironti (INRIA) o Alfredo Pironti (INRIA)
o Dana Polatin-Reuben (University of Oxford) o Dana Polatin-Reuben (University of Oxford)
o Prof. Johan Pouwelse (Delft University of Technology) o Prof. Johan Pouwelse (Delft University of Technology)
o Max Pritikin (Cisco) o Max Pritikin (Cisco)
o Eric Rescorla (Mozilla) o Eric Rescorla (Mozilla)
o Pete Resnick (Qualcomm Technologies, Inc.) o Pete Resnick (Qualcomm Technologies, Inc.)
o Tom Ristenpart (University of Wisconsin) o Tom Ristenpart (University of Wisconsin)
o Andrei Robachevsky (Internet Society) o Andrei Robachevsky (Internet Society)
o David Rogers (Copper Horse) o David Rogers (Copper Horse)
o Scott Rose (NIST) o Scott Rose (NIST)
o Christine Runnegar (Internet Society) o Christine Runnegar (Internet Society)
o Philippe De Ryck (DistriNet - KU Leuven) o Philippe De Ryck (DistriNet - KU Leuven)
o Peter Saint-Andre (&yet) o Peter Saint-Andre (&yet)
o Runa A. Sandvik (Center for Democracy and Technology)
o Runa A. Sandvik (Center for Democracy and Technology)
o Jakob Schlyter o Jakob Schlyter
o Dr. Jan Seedorf (NEC Laboratories Europe) o Dr. Jan Seedorf (NEC Laboratories Europe)
o Wendy Seltzer (W3C) o Wendy Seltzer (W3C)
o Melinda Shore (No Mountain Software) 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 Matthias Waehlisch (Freie Universitaet Berlin)
o Greg Walton (Oxford University) o Greg Walton (Oxford University)
o Rigo Wenning (W3C) o Rigo Wenning (W3C)
o Tara Whalen (Apple Inc.) o Tara Whalen (Apple Inc.)
o Greg Wood (Internet Society) o Greg Wood (Internet Society)
o Jiangshan Yu (University of Birmingham) o Jiangshan Yu (University of Birmingham)
o Aaron Zauner o Aaron Zauner
o Dacheng Zhang (Huawei) o Dacheng Zhang (Huawei)
o Phil Zimmermann (Silent Circle LLC) o Phil Zimmermann (Silent Circle LLC)
o Juan-Carlos Zuniga (InterDigital) 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
URI: https://www.cs.tcd.ie/Stephen.Farrell/
Rigo Wenning Rigo Wenning
World Wide Web Consortium World Wide Web Consortium
2004, route des Lucioles 2004, route des Lucioles
B.P. 93 B.P. 93
Sophia-Antipolis 06902 Sophia-Antipolis 06902
France France
Email: rigo@w3.org Email: rigo@w3.org
URI: http://www.w3.org/People/Rigo/
Bert Bos Bert Bos
World Wide Web Consortium World Wide Web Consortium
2004, route des Lucioles 2004, route des Lucioles
B.P. 93 B.P. 93
Sophia-Antipolis 06902 Sophia-Antipolis 06902
France France
Email: bert@w3.org
Email: bert@w3org
Marc Blanchet Marc Blanchet
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec, QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca URI: http://viagenie.ca
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. ARM Ltd.
110 Fulbourn Rd 110 Fulbourn Rd
Cambridge CB1 9NJ Cambridge CB1 9NJ
Great Britain Great Britain
Email: Hannes.tschofenig@gmx.net Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 303 change blocks. 
616 lines changed or deleted 474 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/