Donate for the Cryptome archive of files from June 1996 to the present

10 July 2014

Countering Pervasive Monitoring

Date: Thu, 10 Jul 2014 06:07:14 +0200
Subject: update
To: cryptome[at]

During the IETF 88 technical plenary that took place in November 2013 [0], some consensus was reached that "pervasive monitoring is an attack" and should as such be addressed in new internet protocol standards. In February 2014, a draft document by Stephen Farrell and Hannes Tschofenig was released that elaborated on this [1]. In May 2014, this document was released again as Best Current Practice (BCP) RFC 7258 [2].

Today, Ted Hardie posted the following message to the IETF's [perpass] mailinglist [3], indicating that other work is already underway:

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

The IAB program for privacy and security

has a document requirement for a threat model document describing the confidentiality issues around surveillance.  In other words, it looked to be about to duplicate some of the work already done around this. To avoid that duplication of effort, and after some discussion with the IESG, the program has adopted this draft and plans to progress it along the IAB track.

We plan to address the comments already raised on the topic by Christian Huitema, Brian Trammel, and Stephane Bortzmeyer, along with incorporating some additional work on metadata analysis.  Further comments on the draft or its successors can be sent to the authors or the IAB program list (privsec-program at

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

The "document requirement" refers to work by Richard Barnes, Bruce Schneier (yes, that one), Cullen Jennings and Ted Hardie, that was released in July 2014 [4]. That document is more elaborate and specific than the first document. Let's see how all this pans out. Only time will tell whether it actually lead to a less surveillance-prone internet. There's both reason for optimism (e.g. the topic of surveillance finally has some momentum in the IETF; and the HTTP/2.0 draft sort-of only allows HTTPS as an apparent result of RFC 7258 [5]) and skepticism (e.g. secure protocols can be insecurely implemented, etc.; and it may generally be difficult to design a protocol such that it defeats all surveillance
attack vectors we'd like it to).

I'm very curious about other people's thoughts on this.