Privacy in the IETF (May 2014 Update)

Mid 2013 I posted a summary about ongoing efforts on privacy in the IETF and I got a lots of good feedback. ISOC even published an extended version of the write-up at http://www.internetsociety.org/articles/ietf-privacy-update. Since summer 2013 a lot happened with regards to security and privacy.

Here is another short update based on activities I have seen. Let me know if I miss something.

Pervasive Surveillance 

With the revelations provided by Snowden a mailing list was created to have a venue for IETF security and privacy experts to discuss the implications of various news articles. This mailing list, called “Perpass List“, was established and triggered a rich discussion about what IETF protocols we need to look into. It is difficult to summarize all the discussions but the archives are available. As a side-effect of the discussion the “Using TLS in Applications” (UTA) working group was created to provide guidance for use of TLS in HTTP, XMPP, email, etc.  An important document discussed in this group provides recommendations for secure use of TLS/DTLS. Meetings at the London IETF meeting also discussed various ideas in more details, for example the desire to encrypt DNS exhanges (see http://www.ietf.org/proceedings/89/dnse.html).

The discussions in the IETF about the Snowden revelations were intense. I doubt that any other standardization organization saw a similar volume of discussions.  Quite naturally the Internet Architecture Board (IAB) used this as an opportunity to scheduled the pervasive monitoring topic as a plenary topic and invited several experts, including Bruce Schneier. Details about the plenary (including a video recording) can be found at http://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html. Due to a job change I was unfortunately not able to attend the meeting myself but the plenary lead to a great discussion and resulted to good community feedback. Following the plenary, an IETF draft was produced to capture the feedback from the IETF community. The main message of <draft-farrell-perpass-attack> is rather simple:

“Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.”

As a follow-up action a workshop was organized. The workshop was called Strengthening the Internet Against Pervasive Monitoring (STRINT) and slides, position papers, and a short transcript can be found at https://www.w3.org/2014/strint/. The event was well attended and the position paper are of great quality. In the meanwhile a first version of the workshop report has been published that describes the conclusions:

“1. Well-implemented cryptography can be effective against pervasive monitoring (PM) and will benefit the Internet if used more,  despite its cost, which is steadily decreasing anyway.

2. Traffic analysis also needs to be considered, but is less well understood in the Internet community: relevant research and protocol mitigations such as data minimisation need to be better understood.

3. Work should continue on progressing the PM threat model draft [I-D.barnes-pervasive-problem] discussed in the workshop.

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 that BCP and dealing with recommendations on how to mitigate PM and how to reflect that in IETF work.

5. The term “Opportunistic” has been widely used to refer to a possible mitigation strategy for PM. We need to document definition(s) for this term, as it is being used differently by
different people and in different contexts. We may also be able to develop a cookbook-like set of related protocol techniques for developers. Since the workshop, the IETF’s security area has taken up this work, most recently favouring the generic term “Opportunistic Security” (OS) [I-D.kent-opportunistic-security].

6. The technical community could do better in explaining the real technical downsides related to PM in terms that policy makers can understand.

7. Many User Interfaces (UI) could be better in terms of how they present security state, though this is a significantly hard problem. There may be benefits if certain dangerous choices were simply not offered anymore. But that could require significant co-ordination among competing software makers, otherwise some will be considered “broken” by users.

8. Ways to better integrate UI issues into the processes of IETF and W3C needs further discussion.

9. Examples of good software configurations that can be cut-and-paste’d for popular software, etc., can help. This is not necessarily standards work, but maybe the standards organisations can help and can work with those developing such package-specific documentation.

10. The IETF and W3C can do more so that default (“out-of-the-box”) settings for protocols better protect security and privacy.

11. Captive portals, [6] (and some firewalls, too) can and should be distinguished from real man-in-the-middle attacks. This might mean establishing common conventions with makers of such middleboxes, but might also need new protocols. However, the incentives for deploying such new middlebox features might not align.”

As the reference indicate there have been some high-quality contributions, such as threat description, better terminology, that have been submitted to the IETF and are work in progress.

 

Engineering Privacy into Internet Protocols

The IAB privacy program has been working on the privacy consideration document and it has been published in RFC 6973. As a follow-up action a privacy tutorial was scheduled and held for the first time. Here is the announcement text distributed before the London IETF meeting (March 2014):

Privacy, as with security, has received increasing attention over the last few years as the number of security incidents and privacy violations increased. While security guidance has been offered in RFC 3552 and has been part of the IETF education tutorial for many years privacy related guidance has only been available recently with the publication of RFC 6973. This tutorial aims to provide the audience a brief overview of the privacy threats that engineers may encounter during their protocol work.

A core part of RFC 6973 is on offering guidance, i.e., a set of questions an engineer should ask himself or herself when designing new protocols or protocol extensions to take common privacy concerns into account.

The slides are available here and here. The audio/video recording was, unfortunately, corrupted. I will try to re-create one to make the content available to a wider audience.

Heartbleed

The discovery of a severe security vulnerability in the implementation of the TLS protocol (in OpenSSL) illustrated a number of problems in the way how implementations of standards are produced. A lot can be said about what went wrong and there are various ideas about what can be done in the future to avoid similar problems (or at least to communicate them better). To keep it short I would like to point to a great article written by Monika Ermert for the Internet Policy Review, a journal on Internet regulation.

 

HTTP 2.0 & the “Trusted Proxy”

As mentioned in my summary last year one exciting development in the IETF is happening in the applications area with HTTP 2.0. With the discussions about pervasive surveillance the desire to provide an always-on security for HTTP 2.0 was raised and this would obviously make “deep packet inspection” by Internet service providers and enterprise networks more difficult. Hence, various companies (which are deploying these types of devices) have started to suggest proposals (e.g., draft-loreto-httpbis-trusted-proxy20 and draft-mcgrew-tls-proxy-server) for building a backdoor into Transport Layer Security (TLS) to terminate security somewhere in the middle of the network to inspect the traffic. Needless to say that this triggered some discussions (also at the STRINT workshop, at the privacy tutorial, and at various IETF mailing list). As an example take a look at Section 5.7 of draft-iab-strint-report and at the perpass mailing list.

TLS 1.3

The work on the new version of Transport Layer Security is ongoing and in the meanwhile progress has been made with the availability of a more detailed working draft. Requirements and use cases are being brought forward and support for privacy protection (and protection against pervasive monitoring) are brought forward. Particularly interesting are the discussions related to the use of cryptographic algorithms, which has lead the IRTF Cryptographic Research Group (CFRG) becoming more active. A recent interim meeting from the CFRG meeting was dedicated to the discussion of Elliptic Curve Cryptography (ECC) has shown in this renewed interest. Here is a link to an email from the co-chair David McGrew about the criteria for choosing a new ECC mechanism.

 

Leave a Reply

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