
RFC 7258 – Pervasive Monitoring Is an Attack - cnst
http://tools.ietf.org/html/rfc7258
======
Tepix
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.

------
higherpurpose
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...](http://arstechnica.com/security/2014/01/nsa-employee-will-continue-to-
co-chair-influential-crypto-standards-group/)

~~~
AlyssaRowan
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.

------
bertil
> 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
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.

------
Create
“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...](http://www.theguardian.com/technology/2014/may/27/-sp-privacy-
under-attack-nsa-files-revealed-new-threats-democracy)

~~~
27182818284
>“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.

~~~
Create
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/homeland_security/editorials/Farewell_Dossier/)

[http://www.ranum.com/security/computer_security/editorials/l...](http://www.ranum.com/security/computer_security/editorials/lawyers/index.html)

 _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.

------
d4mi3n
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?

~~~
mattdeboard
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.

~~~
AnthonyMouse
> 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.

~~~
XorNot
Yay, a whole new class of protocols which will make it harder to communicate
with each other.

I'm all for secure protocols but metadata protection is so nebulously defined,
and introduces such ridiculous problems, that I really don't want it built
into core protocols.

There is no solution to it - moving traffic from here to there via a third
party requires telling someone how to do it. So long as that third party
exists, the problem is unsolvable outside of distributed-risk models like Tor.

~~~
AnthonyMouse
> There is no solution to it - moving traffic from here to there via a third
> party requires telling someone how to do it.

Why do I have to do everything myself? OK, here's IPv8: The only unencrypted
part of the packet is the destination address, the rest of the packet is
encrypted with CurveCP. Moreover, every router has a public key, and you can
set the "destination address" to any router on the path to the actual
destination and encrypt the entire actual packet with its public key. That
router will receive the packet and decrypt it only to discover that it
contains another encrypted packet, which it sends on its way to the next
destination. If you like you can do this more than once. It's onion routing at
the IP level. Tor without the inefficiency, because the "relays" are already
devices on the path to the destination, and with in some ways better security
because each "relay" doesn't inherently know whether the previous hop was also
the previous relay or whether the next relay is the actual destination.

~~~
pjc50
_" destination address" to any router on the path to the actual destination_

1) In normal IP, the source does not know the route to the destination. You
can try to guess with traceroute, but that's not authoritative. And the route
out may not be the same as the route back. There may not even be a single well
defined route.

2) This has the same pattern as the various reflection/amplification attacks
and facilitates DDOS. I think that what "network management" means; if you
provide means for people to flood the network with bad traffic then it becomes
unusable for everyone, or at least it becomes possible to silence a site or
endpoint on an ongoing basis.

3) You've assumed that there's no legal responsibility attached to re-emitting
these packets.

~~~
AnthonyMouse
> 1) In normal IP, the source does not know the route to the destination. You
> can try to guess with traceroute, but that's not authoritative. And the
> route out may not be the same as the route back. There may not even be a
> single well defined route.

This isn't normal IP, it's new IP. Moreover, using a relay would be optional
(just encrypting the source address would give 90% of the benefit) and the
worst case for having chosen one that isn't a router on the preferred route is
that the packet would take a mildly suboptimal path to the destination.

> 2) This has the same pattern as the various reflection/amplification attacks
> and facilitates DDOS. I think that what "network management" means; if you
> provide means for people to flood the network with bad traffic then it
> becomes unusable for everyone, or at least it becomes possible to silence a
> site or endpoint on an ongoing basis.

I don't see amplification. You send one packet, each router forwards it once.
I suppose the attacker could have a packet go back and forth between the same
routers multiple times but that is already possible in existing IP using
source routing and is trivially mitigated by adding a hop count / TTL field.

Amplification means you can send a small amount of data and cause someone else
to send a large amount of data to the target. For example, if you send an EDNS
query to a DNS server with many records for a particular name, the query is
very small and the response could be very large. I don't see that here.

Reflection is much more benign. It doesn't allow an attacker with 100Mbps of
bandwidth to convert it into 10000Mbps of bandwidth, it only allows an
attacker who doesn't care about receiving a response to remain anonymous. So
your complaint about a technical measure designed to allow people to remain
anonymous is that it would allow people to remain anonymous. Feature not bug.

> 3) You've assumed that there's no legal responsibility attached to re-
> emitting these packets.

The existing routers on the existing internet are already re-emitting all the
packets. That's what routers are for.

Obviously Congress could pass whatever law making it legal or illegal after
the fact, but that's orthogonal to the technical issue of how it can be done
whatsoever.

~~~
XorNot
> This isn't normal IP, it's new IP. Moreover, using a relay would be optional
> (just encrypting the source address would give 90% of the benefit) and the
> worst case for having chosen one that isn't a router on the preferred route
> is that the packet would take a mildly suboptimal path to the destination.

"Mildly suboptimal" is the difference between playable latency in online
gaming and unplayable. It's the difference between VOIP and video calling
working and not working.

Your sweeping those issues away under the guise of "probably not so bad" yet
we've had decades of experience finding out that, yeah, they are that bad
which is why the modern internet has ended up the way it is.

~~~
AnthonyMouse
Your argument is that we can't have an optional feature that provides stronger
anonymity because when you use it there could be a few ms of latency that
would be intolerable to some applications that aren't required to use it?

------
webmaven
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/](https://datatracker.ietf.org/doc/rfc7258/)

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

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

------
bertil
> 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.

