IETF#87 Update on Privacy

HTTP 2.0

The IETF is working on a new version of HTTP, called HTTP 2.0, in the HTTPbis working group already for some time. The Wiki page provides a bit of additional data about the goals. The working draft of HTTP 2.0 introduces some major changes to HTTP 1.1 and the possibility to mandate the use of TLS (as the only option) was discussed some time ago but the group decided against it.

However, with the recent debate about PRISM the group has at the last meeting decided to revisit this decision. A presentation from the working group chair from the last IETF meeting in Berlin can be found here. The media has picked this item up, see for example FT article “Internet launches fightback against state snoopers“.  The decision at the meeting got a bit misinterpreted since the author of the article already anticipates the outcome of the discussion.


RTCWeb and E2E Security

The IETF has a long history in developing real-time communication protocols, such as the Session Initiation Protocol (SIP, which is also used by the 3GPP IMS), the Extensible Messaging and Presence Protocol (XMPP), and most recently the RTCWeb protocol, which builds on the Web infrastructure and JavaScript.

The work around RTCWeb has an impact to various other IETF areas but the core specifications are developed in the IETF RTCWEB group and in the W3C.  In addition to various functional aspects the chairs put an important item on the agenda for the last meeting: the group had to decide about the automated key management protocol and two proposals were put forward, namely (a) SDES and (b) DTLS-SRTP.

SDES carries keying material for e2e media security along the signaling path so that signaling intermediaries are able to see the keying material. This approach is simple to implement and convenient for those who want to provide lawful intercept functionality (or other form of inspection) of the end-to-end voice communication.

The argument in favor of SDES has been presented during the meeting by Hadriel Kaplan (Oracle) and Martin Thomson (Skype). The arguments for DTLS-SRTP have been provided by Eric Rescorla. It is worthwhile to take a look at the slide decks to see how differently technical solutions can be presented. I sometimes have to think about the movie “Thank You for Smoking“.

At the end of the meeting the participants hummed in favor of DTLS-SRTP, as the meeting minutes capture. For many IETF meeting participants this was a very important decision and various security experts decided to attend the RTCWeb face-to-face meeting, particularly in light of the PRISM discussions, to influence the decision.


TLS 1.3: The Next Generation of Transport Layer Security

A side-effect of the design of HTTP 2.0, the work on RTCWeb, and the overall attempt to make the Web (particularly for the mobile environment) is the renewed interest in the IETF TLS working group. On one hand there is a desire for more security protection and on the other hand TLS needs to become faster. Cryptographic computations and the latency of the security handshake come at a cost and therefore major Web companies, most notable Google, have been looking at ways to reduce optimize TLS.

These new developments include application layer protocol negotiation to allow de-multiplexing of HTTP 1.1 and HTTP 2.0 payloads, OCSP stapling and multiple OCSP stapling to avoid separate protocol exchanges for checking the status of certificates,,TLS channel ids to develop a sort-of cryptographic cookie at the TLS layer, and mostly recently TLS 1.3. A presentation that outlines some of the design characteristics from the TLS co-chair and TLS author, Eric Rescorla, can be found here. While Eric describes the changes as minor they constitute a major improvement compared to earlier TLS versions, such as the addition of a Diffie-Hellman exchange to avoid passive eavesdropping on the TLS exchange (which is a privacy increasing functionality).

In general, privacy concerns had come up in the TLS working group in various discussions and it appears that there is a better understanding of the need for considering privacy in the design of various TLS protocol extensions.


IAB Privacy Considerations

The IAB privacy consideration document has now been published as RFC 6973. To better inform the IETF community about the guidelines found in that document the IAB privacy program has been working on a tutorial. The IETF #87 meeting was used for a trial run with selected persons (typically working group chairs) to solicit feedback on how to better approach the wider IETF community.

A recording of the presentation is available and the slides are available for download here. The trial run resulted in lots of feedback and adjustments to the tutorial will be made. A revised tutorial for a much larger audience is planned for the upcoming IETF meeting in Vancouver (Nov. 2013).

The IETF security area directors are planning to publish a document that requires IETF document authors to address privacy in the protocols since the IAB document is currently a guidance document but the Internet Engineering Group (IESG) is in a much better position to encourage document authors to consider privacy. This approach would be similar to what was done with security and BCP 107 and BCP 61.


Tor meets the IETF

Various members of the Tor project, including Jacob Appelbaum and Linus Nordberg, decided to attend the Berlin IETF meeting to discuss the news about PRISM, to share information about their work, and to determine how cooperation with the IETF community could look like.

In addition to side meetings, a presentation at the Security Area Advisory Group was given and a new mailing list,, was created to continue the discussions.

The interaction with the Tor community will provide the IETF with additional insight on how to prevent fingerprinting and to learn about the state of middleboxes throughout networks (as part of the Tor project work on the Open Observatory of Network Interference). The Tor community on the other hand will benefit from additional reviews and involvement of the IETF community in the ongoing developments.


Security Incident Information Sharing

High-profile data breaches and security incidents on the Internet are gaining increasing attention from the Internet community, but also from the public and from governments. Various CyberSecurity activities have recently been launched, such as the EU CyberSecurity strategy, the EC created Network and Information Security Platform, and the NIST CyberSecurity framework. Sharing of security incident information is one of the items that is supposed to improve awareness and shall ensure a quicker response to security incidents.

Since the IETF has standardization efforts ongoing in the area of incident and abuse information sharing a workshop was held prior to the IETF #87 meeting. The workshop page also contains slides from the presenters, including presentations about privacy and legal aspects. The workshop report is still work in progress.

While there are many challenges it became clear that the privacy related aspects are not well understood. For example, what information about the communication interactions is allowed to be collected? What information can be shared with third parties and under what conditions? While various techniques have been deployed for a long time already (such as in the case of spam filtering) it is was not obvious from the discussions at the workshop how well they have been analyzed against the data protection frameworks. Further discussions will be certainly needed and recommendations will have to be developed as more sharing is expected in the near future, also due to recently created work in the IETF such as Security Automation and Continuous Monitoring (SACM).


Improving the Web Public Key Infrastructure (WebPKI)

The problems with the WebPKI have received the attention by the Internet security community when DigiNotar, a Dutch certificate authority, had a security breach and in the same year a Comodo affiliate was compromised. Both cases lead to fraudulent issue of certificates and raise questions regarding the strength of the PKI used by many applications today.

A compromise of the PKI obviously leads to privacy violations since it allows an attacker to intercept encrypted communication.

Almost two years have passed since these incidents happened. Although new technical mechanisms have been developed within the IETF, such as DANEkey pinning, and certificate transparency, very little has happened in terms of actual deployment. Consequently, the attacks that have happened two years ago may happen any time again.

With the NIST workshop on “Improving Trust in the Online Marketspace” various stakeholders were invited to discuss the technical options for improving the state-of-the-art. It became clear that there are very few organizations who have the desired properties, such as technical expertise, appropriate membership model, and independence, to lead the follow-up discussions.

As a follow-up activity the Internet Architecture Board will work together with the Internet Society to initiate work on a roadmap and shared vision on how to proceed on this topic. A meeting is planned at the upcoming IETF meeting and a workshop will be organized early next year.

Leave a Reply

Your email address will not be published. Required fields are marked *