Online privacy and security concerns took centre stage in the global news recently, with much publicity surrounding both the proposed data protection regulation in Europe and the growing allegations of state-sponsored pervasive Internet surveillance. Between the lines, members of the IETF community can see their ongoing privacy and security efforts at work. It’s heartening to see the renewed interest in these important topics and the fresh look they’re receiving in light of a greater understanding of pervasive monitoring. Below you’ll find a brief summary of IETF87 activities related to privacy and security.
HTTP 2.0 and Encryption by-default
The HTTPbis working group (WG) is working on a new version of HTTP (Hypertext Transfer Protocol), called HTTP 2.0. The working draft[1] introduces major changes to HTTP 1.1. In March 2012, at the IETF 83 meeting, the group decided against an HTTP 2.0 design using a secure-only version with mandatory-to-use TLS (Transport Layer Security). Recent debates regarding state-sponsored Internet surveillance, including an inspiring presentation[2] from the working group’s chair, Mark Nottingham, motivated the group to revisit the decision.
The importance of these developments has already prompted mainstream media reports[3] and we expect the ongoing debate to be an interesting one. A solution that enables encryption by default is a privacy feature that many experts have been seeking for some time. It does, however, create a dilemma for firewall manufacturers, who struggle to intercept TLS communication in enterprise networks, particularly with the increase of bring-your-own-device (BYOD) deployments. Today, many enterprise-controlled devices, like laptops, come with a fake trust anchor installed to transparently terminate TLS connections at the company firewall. With BYOD this “trick” does not work anymore. Ideas, such as the TLS proxy, that would have allowed intermediaries to look into the traffic were quickly dismissed by meeting participants.
RTCWeb and E2E Media Security
The IETF has a long history of developing real-time communication protocols, including the Session Initiation Protocol (SIP), the Extensible Messaging and Presence Protocol (XMPP), and most recently, the RTCWeb (Real-time Communication in Web Browsers) protocol, which builds on the Web infrastructure and JavaScript.
The core specifications of RTCWeb were developed in the RTCWEB WG and in the W3C. In addition to functional aspects, last meeting’s agenda included an item to discuss the key management protocol for establishing the necessary keying material and parameters for use with the Secure Real-Time Transport Protocol (SRTP), which is used to protect voice and video communication on an end-to-end basis. Two proposals were put forward: SDES (Session Description Protocol Security Descriptions) and DTLS-SRTP (Datagram Transport Layer Security–Secure Real-time Transport Protocol).
SDES carries keying material along a signalling path such that signalling intermediaries can see the keying material. It’s simple to implement and convenient for those seeking lawful intercept functionality (or other forms of inspection) for end-to-end voice communication. DTLS-SRTP, on the other hand, uses DTLS to distribute the necessary keying material and provides increased protection against intermediaries and eavesdroppers.
Hadriel Kaplan and Martin Thomson presented arguments in favour of SDES.[4,5] Eric Rescorla presented arguments for DTLS-SRTP.[6]
For many meeting participants this was a critical decision and a number of security experts were in attendance to weigh in. By meeting’s end, participants were in favour of DTLS-SRTP.[7]
TLS 1.3: The Next Generation of Transport Layer Security
A side benefit of the design of HTTP 2.0, the work on RTCWeb, and the overall attempt to make the Web more secure (particularly for the mobile environment) is a renewed interest in the TLS WG.
We’re seeing today a desire for both more security protection and lower communications latency, but cryptographic computations and the latency of the security handshake come at a cost. In response, major Web companies, most notably Google, are looking at ways to optimize TLS.
New developments include application layer protocol negotiation to allow the demultiplexing of HTTP 1.1 and HTTP 2.0 payloads, OCSP (Online Certificate Status Protocol) stapling and multiple OCSP stapling to avoid requiring separate protocol exchanges to check the status of certificates, TLS channel IDs to develop a “cryptographic cookie” at the TLS layer, and mostly recently, TLS 1.3.
Eric Rescorla, TLS WG co-chair and TLS author, offered an overview of some of the TLS 1.3 design characteristics,[8] and although he describes the changes as minor, compared to earlier TLS versions they include major improvements (e.g., the addition of a Diffie-Hellman exchange to avoid passive eavesdropping on the TLS exchange, a privacy increasing functionality).
Privacy concerns came up in a number of TLS WG discussions. There appears now to be a better understanding of the need to consider privacy issues when designing TLS protocol extensions.
IAB Privacy Considerations
The IAB (Internet Architecture Board) privacy considerations document was published as RFC 6973.[9] To inform the IETF community about the new guidelines, the IAB privacy program devised a tutorial,[10, 11] which they piloted at IETF 87 in order to solicit feedback. A revised tutorial for a much larger audience is planned for IETF 88 in Vancouver (November 2013).
The IETF security area directors plan to publish a document that requires IETF document authors to address privacy in their protocols. The IAB document is currently used for guidance, but the Internet Engineering Steering Group (IESG) is in a much better position to encourage document authors to consider privacy. This approach will be similar to the approach taken with security in BCP (Best Current Practice) 107 and BCP 61.
Tor and the IETF
Members of the Tor project, including Jacob Appelbaum and Linus Nordberg, attended the IETF 87 to discuss the PRISM revelations, share information about their work, and determine what collaboration with the IETF might look like. In addition to side meetings, a presentation at the Security Area Advisory Group[12] was made and a mailing list ([email protected]) created to foster continued conversation.
Cooperation with the Tor community could provide the IETF with additional insight into fingerprinting prevention and the state of middleboxes throughout networks (see Tor’s Open Observatory of Network Interference project[13]). The Tor community could benefit from additional reviews and involvement of the IETF community in their ongoing projects.
Security Incident Information Sharing
High-profile data breaches and security incidents on the Internet are gaining more and more attention from the Internet community, the public, and governments around the globe. A variety of cybersecurity activities have recently been launched, including the European Union’s CyberSecurity strategy, the European Commission-created Network and Information Security Platform, and the NIST (National Institute for Standards and Technology) CyberSecurity Framework. Sharing security incident information is critical to improving awareness of and ensuring a quicker response to security incidents.
Just prior to IETF 87, the IETF held a workshop on its ongoing standardization efforts in the areas of incident and abuse information sharing. The workshop page contains slides from the presenters, including presentations about privacy and other legal aspects.[14] A workshop report is in progress.
Workshop discussions underscored the fact that privacy issues are not well understood. For example, what information about the communication interactions is allowed to be collected? What can be shared with third parties and under what conditions? While some techniques have been deployed for some time already (e.g., spam filtering), it was not obvious from the discussions at the workshop how well these issues have been considered vis à vis data-protection frameworks. Further discussion is needed and recommendations will be developed as more sharing occurs and as IETF efforts progress, specifically in the Security Automation and Continuous Monitoring (sacm) WG [15] and in the Managed Incident Lightweight Exchange (mile) WG.[16]
Improving the Web Public Key Infrastructure (WebPKI)
Problems with the WebPKI received attention by the Internet security community when DigiNotar, a Dutch certificate authority, had a security breach, and then again in the same year when a Comodo affiliate was compromised. Both involved the fraudulent issue of certificates and raised questions regarding the strength of the PKI in use today.
A compromise of the PKI leads to privacy violations as it allows an attacker to intercept encrypted communication. Almost two years have passed since the aforementioned incidents and new technical mechanisms have been developed—including DANE (DNS-based Authentication of Named Entities), key pinning, and certificate transparency. But very little has happened in terms of actual deployment and similar attacks could still occur.
In April 2013, NIST held a workshop on “Improving Trust in the Online Marketplace” and invited stakeholders to discuss technical options for improving the state-of-the-art. It became clear that there exist very few organizations with the technical expertise, appropriate membership model, and independence required to lead the follow-up discussions.
The IAB will work with the Internet Society on how to proceed on this topic. A meeting is planned for IETF 88 and a workshop will be organized in 2014.
Looking ahead to IETF 88 Vancouver
Just prior to publication of this article, Bruce Schneier published an article suggesting that IETF 88 be dedicated to discussing how to make surveillance more expensive.[17] In response, Jari Arkko, IETF chair, and Stephen Farrell, IETF security area director, shared their views about pervasive surveillance in a blog post.[18] Discussions continue on the IETF mailing list [19] and on the perpass mailing list ([email protected]), about specific steps the IETF can take as a standardization body and steps the wider Internet community can take. Lots of ideas are being bounced around and the open nature of the IETF is, as expected, facilitating a fruitful exchange. I encourage you to contribute your views to the discussion.
References
1. http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
2. http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-3.pdf
3. http://gonzaloraffoinfonews.blogspot.co.at/2013/08/internet-launches-fightback-against.html
4. http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-2.pdf
5. http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-3.pdf
6. http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-5.pdf
7. http://www.ietf.org/proceedings/87/minutes/minutes-87-rtcweb
8. http://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
9. http://tools.ietf.org/html/rfc6973
10. http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF87_PRIVACY_TUTORIAL&chapter=part_1 (
recording)
11. http://www.iab.org/?attachment_id=7038 (slides)
12. http://www.ietf.org/proceedings/87/slides/slides-87-saag-5.pdf
13. https://ooni.torproject.org/
14. http://siis.realmv6.org/
15. http://datatracker.ietf.org/wg/sacm/charter/
16. http://datatracker.ietf.org/wg/mile/charter/
17. http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying
18. http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/
19. http://www.ietf.org/mail-archive/web/ietf/current/msg82071.html