Internet Engineering Task Force Considers Making Surveillance Mitigation A Standard Part Of Its Specifications

from the o-brave-new-world dept

Snowden's revelations that key elements of the Internet have been subverted by the NSA and its allies has led people to realize that in the future we need a more thoroughgoing framework for security that assumes surveillance, and takes steps in advance to counter it. One interesting manifestation of this approach is a new "Request For Comments" document from the Internet Engineering Task Force (IETF), RFC 7528, entitled "Pervasive Monitoring Is an Attack." Here's the basic idea:

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM.
What's key is the idea that pervasive monitoring is an attack that needs to be mitigated as a matter of course; here's what that means:
Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?"

In particular, architectural decisions, including which existing technology is reused, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making architectural decisions.
As that shows, this is a high-level technical specification; it's not about how to mitigate pervasive monitoring, but about the fact that Internet engineers should always think about how to mitigate such surveillance when they are drawing up IETF specifications. It's great that the IETF is starting to work along these lines, even if it is a rather melancholy acknowledgement that we now live in a world where the default assumption has to be that someone, somewhere, is trying to monitor on a massive scale what people are doing.

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+


Reader Comments (rss)

  1.  
    identicon
    Anonymous Coward, May 17th, 2014 @ 3:45am

    Comments

    To the writer of this blog: With all respect, maybe you haven't connected the dots. We are way past melancholy when national states assume full take is their right, as in take EVERYTHING on this internet, and all personal information can be used to suborn anyone. At this point in time, it only takes good intentions of the nation state to not actively suborn our key decision makers - if you are melancholy, then you still deep down trust "good intentions."

    Wake up!

    And why are we not running HTTPS for this site???

    Double wake up!

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here
Get Techdirt’s Daily Email
Save me a cookie
  • Note: A CRLF will be replaced by a break tag (<br>), all other allowable HTML will remain intact
  • Allowed HTML Tags: <b> <i> <a> <em> <br> <strong> <blockquote> <hr> <tt>
Follow Techdirt
Advertisement
Essential Reading
Techdirt Deals
Techdirt Insider Chat
Techdirt Reading List
Advertisement
Recent Stories
Advertisement
Support Techdirt - Get Great Stuff!

Close

Email This

This feature is only available to registered users. Register or sign in to use it.