RFC 7258 – Pervasive Monitoring Is an Attack

http://tools.ietf.org/html/rfc7258

by cnst • 12 years ago

315 34 12 years ago

tools.ietf.org

d4mi3n• 12 years ago

What are the odds of something like this becoming core to how the IETF writes it's recommendations? Is this an actual attempt to address the surveillance issues that have become so prevalent, or should I not get my hopes up?

mattdeboard2• 12 years ago

If I'm reading it right, this RFC is seeking public input on a proposed policy of considering pervasive monitoring (PM) another attack vector among a host of attack vectors that should be considered when designing protocols.

I am blissfully ignorant on the politics of how the IETF works so who knows what the actual odds are. But I think it's good that it's at least being considered. That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. Seems a bit like tilting at windmills if the corporations that host are data are either voluntarily complying with "PM" or being compelled to by subpoena.

AnthonyMouse4• 12 years ago

That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs.

One of the primary concerns with pervasive monitoring is metadata. We could see an increase in protocols that make efforts to not only protect what you're communicating but who you're communicating with.

Seems a bit like tilting at windmills if the corporations that host are data are either voluntarily complying with "PM" or being compelled to by subpoena.

The general idea is to change the status quo. Use distributed systems rather than centralized ones.

cnst3• 12 years ago

That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs.

The difference is that with passive monitoring, you don't have to worry about authentication, and opportunistic encryption without any sort of authentication is good enough. Think STARTTLS in SMTP.

I actually found this RFC7258 through http://tools.ietf.org/html/draft-nottingham-http2-encryption... "Opportunistic Encryption for HTTP URIs", so, there's that. Personally very interested in this, as I have a dozen of different domains and subdomains for my non-profit reference web-sites like http://mdoc.su/, and I also care about supporting legacy clients and having minimal administrative costs, hence I cannot deploy HTTPS://.

fulafel• 12 years ago

If I'm reading it right, this RFC is seeking public input on a proposed policy

No, all the IETF published documents are called "request for comments" for historical/cultural reasons. This is an actual finalized policy document.

The phase where the IETF seeks input to these is the "Internet-Draft stage".

cnst3• 12 years ago

Yes, HTTP/2 is finally taking the opportunistic encryption seriously (think STARTTLS in SMTP), whereas the pre-Snowden http://tools.ietf.org/html/rfc2817 "Upgrading to TLS Within HTTP/1.1" never took off one bit.

In fact, there are now not one, but like at least four different post-Snowden drafts to the effect of seamless behind-the-scenes encryption on top of the HTTP:// address scheme, which is the exact solution I'm personally advocating for, since it's pretty much backwards compatible with 100% of the existing infrastructure, and effectively has negligible cost, and no tie-ins, unlike the full blown HTTPS://.

https://github.com/http2/http2-spec/issues/315

https://www.mnot.net/blog/2014/03/17/trying_out_tls_for_http...

http://tools.ietf.org/html/draft-nottingham-http2-encryption...

http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-una...

http://tools.ietf.org/html/draft-miller-http-unauth-tls-00

http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-t...

__alexs2• 12 years ago

Opportunistic encryption without authenticated certificates is basically useless. Actively decrypting and re-encrypting the entire current internet at line speed can be achieved for only a few million dollars.

It's neither a technical nor economic deterrent to surveillance.

An SSH style TOFU auth model might provide some safety here but at a significant cost in user experience when certificates do change.

tveita• 12 years ago

There are also proposals for lower-layer opportunistic encryption, like Tcpcrypt. Being an OS feature it would take considerably longer time to reach wide-spread deployment, but it would add opportunistic encryption to all TCP connections, including regular HTTP.

http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt

zurn• 12 years ago

What are the odds of something like this becoming core to how the IETF writes it's recommendations?

This is a document mandating just that.

Status-wise, this is a BCP (Best Current Practice) document, so it's as senior and authoritative as IETF documents get. BCPs are on the same top tier as IETF's Standards Track documents, they go through a heavy (as far as IETF goes) process involving IESG approval etc.

This means that specs have to take this BCP into account in their (mandatory) security considerations sections, and spec reviewers are required to take issue if a spec isn't doing that.

Like rules in general, this is subject to gaming on various levels, so if a working group is manned by snooping enthusiasts they can conspire to do this weakly. But it's still something!

higherpurpose• 12 years ago

I don't know how seriously to take this when IETF keeps letting this happen:

http://arstechnica.com/security/2014/01/nsa-employee-will-co...

_mhp_• 12 years ago

Kevin Igoe is retiring next year, and is currently handing over to the two new CFRG chairs. They introduce themselves here:

http://www.ietf.org/mail-archive/web/cfrg/current/msg04552.h...

http://www.ietf.org/mail-archive/web/cfrg/current/msg04553.h...

AlyssaRowan2• 12 years ago

You'll recognise me from the CFRG threads about that topic.

The subject is moot now: Kevin M. Igoe is retiring, so he's stepping down at the end of the year (and probably not doing anything major until then, other than participating as anyone else could, with of course full knowledge of where he works). The other current co-chair is also stepping down, in favour of two new unrelated co-chairs who have been extremely open and forthright with their status - and, to the best of my knowledge, don't work for a Nation State Adversary. Things seem to have turned out okay.

In the meantime, CFRG has been documenting - in the public eye - a ChaCha20-Poly1305 AEAD (the djb alternative to the NIST-preferred AES-GCM; a fast, 256-bit secure constant-time authenticated stream cipher AEAD) and has, after a lively discussion, selected djb's Curve25519 (the most mature of the so-called "SafeCurves") as the preferred curve for new IETF protocols; amongst some other lively and open discussion about the promises and perils of PAKEs, signature schemes and other such things. They'll be coming to protocols near you soon: various WG drafts are in progress now.

bertil2• 12 years ago

The term "attack" is used here in a technical sense that differs somewhat from common English usage.

This document is intended to be read by a larger public than most IETF documents.

bertil2• 12 years ago

Making networks unmanageable to mitigate PM is not an acceptable outcome

Not sure that I'm reading this correctly, but "managed network" was a euphemism for Deep packet inspection used as a censoring tool (by government-controlled ISPs) some years ago. This reads a bit like the IETF had to unanimously yield, not to "But who will think of the children" arguments of the time, but the spying threat; it makes Snowden revelation an interesting linchpin in making surveillance acceptable, as a weapon against surveillance.

brianmwaters_hn• 12 years ago

I think they're speaking more about the much less exciting form of network everyday network monitoring that goes on inside the enterprise - troubleshooting, performance tuning, etc. But you've got an interesting, if not a bit cynical, interpretation there.

Tepix• 12 years ago

I welcome the current stance of the IETF regarding privacy, opportunistic encryption and mass surveillance. I hope we can stop mass surveillance by technical means.

Our political leaders have made it clear that they are unwilling and/or uncapable of stopping this continued human rights violation.

mellisarob• 12 years ago

this is not a favorable in terms of the outcomes it might have.

Create2• 12 years ago

“You can't solve social problems with software.” – Marcus Ranum

We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites States government has led not only us but the world.

This should not actually be a complicated inquiry.

http://www.theguardian.com/technology/2014/may/27/-sp-privac...

27182818284• 12 years ago

“You can't solve social problems with software.” – Marcus Ranum

This is the first time I've seen that quote or that name. I have no idea why I should believe that quote, though. For one, the NSA, CIA, Russian intelligence (what's the preferred name these days anyway?), etc all invest significant time and money into software.

Additionally, I feel like the Internet has solved lots of problems for me personally, even if those aren't "social" problems per se.

Create2• 12 years ago

Right now, on one hand, we're spending billions of dollars for this Myth of Homeland Security in the hopes of protecting against terrorists, rogue states, and ideological nutcases. But, on the other hand, corporate America is lining the pockets of executives...

http://www.ranum.com/security/homeland_security/editorials/F...

http://www.ranum.com/security/computer_security/editorials/l...

Additionally A Web 2.0 site may allow users to interact and collaborate with each other in a social media dialogue as creators of user-generated content in a virtual community, in contrast to Web sites where people are limited to the passive viewing of content. Examples of Web 2.0 include social networking sites, blogs, wikis, folksonomies, video sharing sites, hosted services, Web applications, and mashups.

webmaven• 12 years ago

I thought I had been paying attention to this as a proposed draft, but actually didn't notice that it had achieved BCP status in May!: https://datatracker.ietf.org/doc/rfc7258/

This was pleasantly speedy (six months, from November '13 to May '14), by IETF standards.

RFC 7258 – Pervasive Monitoring Is an Attack

Related Stories