Security

STRINT Workshop Focuses on Pervasive Monitoring

By: Karen O’Donoghue

Date: July 1, 2014

line break image

The past year has brought a series of revelations that have focused the entire Internet community on the topics of privacy and pervasive monitoring. Although some of the vulnerabilities have been known and some of the capabilities suspected, the depth and scale has come as a shock to many.

Two days prior to IETF 89, approximately 100 experts from the broader Internet community gathered for a workshop to discuss Strengthening the Internet (STRINT) against pervasive monitoring. The workshop focused on the ongoing issue of pervasive monitoring, its impact on the global Internet, and possible responses in various communities.

The primary goal of the STRINT workshop was to explore future work with the IETF and the World Wide Web Consortium (W3C) to address pervasive monitoring. Within that framework, the workshop also hoped to arrive at some agreement on threats, mitigations, trade-offs, architectural weak points, and potential work items and actions both within the Internet technical community (IETF, Internet Architecture Board, Internet Research Task Force, and W3C) and beyond.

The IAB plenary held at IETF 88 in Vancouver1 concluded with a broad consensus that pervasive monitoring is an attack. This consensus has been subsequently documented as “Pervasive Monitoring Is an Attack,” BCP 188, RFC 72582. The STRINT workshop started with that consensus and proceeded to discuss the scope and implications of pervasive monitoring on the global Internet, possible near term actions for both the IETF and W3C communities, and harder topics for further discussion and analysis.

Workshop Goals and Structure

The STRINT workshop was jointly sponsored by the IAB3 and the W3C4 with hosting support from the European Union STREWS project5. All interested parties were invited to submit position papers and participants were selected from that set, resulting in a capacity crowd. The agenda and submissions are available on the workshop website6.

The workshop comprised a series of sessions with short kick-off presentations followed by moderated discussions. Topics for the sessions included workshop goals, threat models, usage of existing security tools, policy implications, improved tools, metadata, and deployment. The final sessions were a series of breakouts on research, clients, defaults, and terminology. A draft report detailing the results of the workshop is available7.

General Observations

While it is not possible to summarize all the discussion and results from the workshop, key themes from the workshop are discussed below.

First, there is general agreement that there are technologies and tools that have been developed that would improve the state of privacy and security in the Internet. For example, well-implemented cryptography can be effective, and more use of it would improve security and privacy.

This raises the question of why existing technologies and tools that have already been developed don’t get deployed and used. Cost is an argument often used against cryptography; however, costs are significantly declining. Another concern is the difficulty with deployment and use. The technical community could do more to make the tools easier to use and ensure that the default settings provide the highest levels of protection using well respected algorithms.

Additionally, the community as a whole could benefit from more examples of how to do things correctly, including examples of good software configurations to facilitate the deployment and use of existing technology. And to help the developers who are often not security experts, the community should consider the development of examples of quality code for product development.

Near-Term Actions

In addition to the general observations above, the workshop identified specific activities for the IETF.

  1. Not surprisingly, terminology is a problem. The term opportunistic encryption has been used in a number of IETF discussions related to pervasive monitoring. However, that terminology is used differently in related communities, causing confusion. To reduce this confusion, consensus needs to be reached on generic terminology. Subsequent to the STRINT workshop, the Security Area in the IETF has pursued this topic with the latest state being discussed on the SAAG mailing list ([email protected]) and in draft-kent-opportunistic-security “Opportunistic Security as a Countermeasure to Pervasive Monitoring”8.
  2. A documented threat model would be helpful. There is already an excellent start for that document in draft-barnes-pervasive-problem “Pervasive Attack: A Threat Model and Problem Statement”9. This will be used as the starting point and developed in the IETF.

Longer-Term Challenges

This brings us to some of the tougher challenges identified during the STRINT workshop. Most of these challenges represent significant tensions between legitimate competing concerns.

  1. The tension between the desire to deploy more encryption and the difficulty that this deployment creates for network operations. Some visibility into traffic is necessary to optimize network performance and troubleshoot problems. However, that same visibility provides a wealth of information about the source and nature of communications even when the actual data itself is encrypted. Exacerbating this issue is the fact that traffic analysis is not well understood in the Internet community. Additional research and the development of techniques like data minimization are needed. In another example of this first tension, devices like captive portals and firewalls have legitimate roles to play in deployed networks but may not be distinguishable from a man-in-the-middle attack. Policies associated with using these devices may limit or prohibit the use of encryption.
  2. The tension between privacy and business models. Many products and services in today’s Internet are provided on a low- or no-cost basis. The information gathered in the process of providing the service is a valuable commodity, and the cost associated with providing the service is offset by the value of the information gathered. In this case, the business model is in direct conflict with the proposed mechanism for enhancing privacy.
  3. The last significant challenge discussed herein is the problem of user interfaces. Existing user interfaces are a significant barrier to the adoption of many security technologies. If the security mechanism stands between an operator or a user and his desired objective, it needs to be easily understood and used. That is often not the case. Internet users have long since been conditioned to hit the OK button without fully understanding the implications of their decisions. A user cannot be expected to fully understand the intricacies of certificate models and encryption in order to be protected by the security mechanism. The IETF and W3C have long considered user interfaces to be primarily outside their scope; however, the time may have come to better integrate these topics into the discussion.

 

 

Finally, while the STRINT workshop was primarily a technical meeting, there was some discussion of the interdependency of technology and policy in addressing pervasive monitoring. Better communication and understanding between the two communities could lead to technical and policy approaches that are viable and support each other instead of working against each other.

Ongoing Related Activities

Beyond the STRINT workshop, the IETF and the W3C are both responding to pervasive monitoring with renewed focus on privacy and security.

The IETF has revived an effort to provide adequate privacy reviews to protocols under development. This will be part of the existing security review process and be informed by “Privacy Considerations for Internet Protocols”10. At some point, the IETF may update the existing security considerations document “Guidelines for Writing RFC Text on Security Considerations”11 to better address pervasive monitoring. In addition to review of emerging protocols, there is a new effort to review existing RFCs for any privacy or pervasive monitoring concerns. A mailing list has been established ([email protected]) and a wiki page has been set up to track any issues identified during the course of these reviews (https://trac.tools.ietf.org/group/ppm-legacy-review/).

On the working group front, a new working group in the IETF has been chartered to look at the use of Transport Layer Security (TLS) in application protocols, Using TLS in Applications (UTA). Several other working groups and Birds-of-a-Feather sessions are looking at this issue with renewed energy.

In the W3C, the Privacy Interest Group continues to provide overarching privacy review for W3C recommendations12. In addition, a Web Security Interest Group13 has been established to advance security in W3C recommendations.

Conclusions

While it has been a tough year for privacy and security in the Internet, the STRINT workshop showed that there is an energized and passionate community. This community, while not in total agreement, does have rough consensus on some general principles, near term actions, and longer-term efforts that would help to mitigate pervasive monitoring. All of this is encouraging for the improvement of overall security and privacy for the global Internet.

References

  1. http://www.internetsociety.org/publications/ietf-journal-march-2014/iab-plenary-debates-attacks
  2. Farrell, S. and H. Tschofenig, “Pervasive Monitoring Is an Attack,” BCP 188, RFC 7258, May 2014. (https://www.rfc-editor.org/rfc/rfc7258.txt)
  3. www.iab.org
  4. www.w3.org
  5. http://www.strews.eu
  6. https://www.w3.org/2014/strint
  7. https://datatracker.ietf.org/doc/draft-iab-strint-report
  8. https://datatracker.ietf.org/doc/draft-kent-opportunistic-security
  9. https://datatracker.ietf.org/doc/draft-barnes-pervasive-problem
  10. Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, “Privacy Considerations for Internet Protocols,” RFC 6973, July 2013.
  11. Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” BCP 72, RFC 3552, July 2003.
  12. http://www.w3.org/Privacy
  13. http://www.w3.org/Security/wiki/IG