That’s the title of RFC 7258, also known as BCP 188 (where BCP stands for “Best Current Practice”); it represents Internet Engineering Task Force consensus on the fact that many powerful well-funded entities feel it is appropriate to monitor people’s use of the Net, without telling those people. The consensus is: This monitoring is an attack and designers of Internet protocols must work to mitigate it.
Concretely, quoting from the RFC (PM stands for Pervasive Monitoring): “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.”
The back story · Since the pervasive-surveillance story broke in June 2013, it’s reasonable to wonder why the IETF is putting this stake in the ground in May of 2014. The IETF works by “rough consensus”, and the path to this particular consensus was particularly rough. The resistance was vociferous, and fell into some of these baskets:
“This is politics. The IETF doesn’t/shouldn’t do politics.”
“There are legitimate reasons to monitor Internet traffic.” (For example, in businesses and prisons.)
“I work in an area where privacy technologies can’t be used.” (One example is ham radio).
“Privacy technologies will drive up the cost of deploying, managing, and using the Net.”
“The IETF Security Area Directors were mean to me in the past, got in the way of publishing important work, and this will give them another club to beat me with.”
I and lots of others didn’t buy the objections. My own takes are: First, the document carefully steers clear of the motivations for pervasive monitoring, mostly because you can’t figure out what they are. Second, we don’t want an Internet optimized for prisons. Third, if your application doesn’t support privacy, that’s probably a bug in your application. Fourth, the cost of ignoring surveillance exceeds the cost of mitigating it. Finally, the state of Internet privacy suggests that the security people historically haven’t been mean enough.
Of course, if you were paranoid and suspicious, you might feel that some of the resistance is related to the facts that there are people making big money selling surveillance technology, and that other people think Ed Snowden is a traitor and it’s perfectly reasonable for the NSA to know everything about everyone, because if you’re not doing anything wrong why would you want privacy?
Also, the IETF has a contingent that is reflexively against anything new, or that has any flavor of idealism, or that generally rocks any boats.
In any case, I think it was very important, for the continued relevance and usefulness of the IETF, that it, in this case, rise above its own naysayers, bring to bear a mix of idealism, suspicion, and paranoia, and do what is right for the actual people who use the Internet.
Acknowledgments · Thanks are due to Stephen Farrell, who wrote the document, to the members of the “Perpass” mailing list, and then the IETF community as a whole.
Also to Ed Snowden and the journalists who brought his story forward, for starting this very, very necessary conversation.
Comment feed for ongoing:
From: Chris (May 13 2014, at 14:30)
This very good news comes the day after this other very bad news:
http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff
[link]
From: John Goerzen (May 14 2014, at 06:47)
I am quite pleased at the IETF's stance here -- it is a step in the right direction. I hope they find a good balance, and can move quickly, though I fear both will be difficult.
But to address the "bug in the application" comment. Amateur radio is a vital service, particularly in emergencies; our ability to relay messages around the world without relying on any intermediate infrastructure (not even satellites) has often been important. Amateur radio and TCP/IP have worked together for years, and it is possible to effectively telnet into machines dozens or even thousands of miles away using a low-bandwidth system known as packet radio.
Amateur radio is one of the few radio services -- and generally the only open to the public -- where people can build their own transceivers and antennas. Due to the bands open for our use, a misconfigured or malicious transmitter could disrupt communications not just next door, but on the next continent. This is why a license is required. To keep it available for the public's use, certain kinds of communication are banned on amateur radio: communication with a profit motive (such as for a business), profanity, etc. This is important, because otherwise businesses would flood out individuals on the limited bands.
By international treaty, encryption is forbidden on amateur radio bands, to preserve the ability for the community to be self-policing about content.
Although typically a strong advocate for encryption everywhere and as much as possible, in this case, I agree with the ban. I can log into a remote machine via telnet and I authenticate with OPIE, so I can authenticate securely without encryption. Works well.
All this is to say: please do not be so quick to say "that's a bug in your application." You appear to have done so before making an effort to learn the application well enough to differentiate a bug from a feature in its context.
John Goerzen, KR0L
[link]
From: Jeff Smith (May 14 2014, at 09:42)
BCP refers to "Best Current Practice" (http://en.wikipedia.org/wiki/Best_current_practice ), rather than "Best *Common* Practice"
This doesn't necessarily change the overall meaning.
[link]
From: Bill (May 14 2014, at 14:42)
If you are doing nothing that deserves that you are monitored, then you should not be monitored.
[link]
From: Eduardo Montez (May 14 2014, at 16:29)
The internet strikes back.
Alas, I am not sure this could be effective. Suppose, for instance, the IETF develops a new standard that makes IPS's more secure against pervasive monitoring. Perhaps the NSA will pressure the US government to simply outlaw it.
[link]
From: Daniel Appelquist (May 15 2014, at 02:18)
It's worth noting the connection between this RFC and the joint IETF-W3C workshop on this topic which happened in February. The workshop report has recently been posted here: https://www.w3.org/2014/strint/report.html (along with the input papers and minutes) and includes some of the findings - specific areas where Internet & Web standards can be improved to harden them against the pervasive monitoring attack.
[link]
From: Tony Fisk (May 15 2014, at 07:10)
There's an old trick that police use as a pretext to pull 'people of interest' in: follow them in their car until they (inevitably) commit a traffic infringement.
Continual surveillance serves the same purpose.
[link]
From: Josh Myer (May 30 2014, at 21:09)
(Apologies in advance if you're a ham and already know all this stuff.)
For the ham radio example, the lack of privacy is a sort of feature, not a bug. If it were a computer network, ham radio would be basically one singular, giant, world-wide collision domain. On top of that, if someone handed me a spreadsheet and said "I've run the numbers, there's less than 10Mbit of bandwidth in all of the HF bands," I wouldn't bother checking them too closely before agreeing with them. It's a very constrained, very useful public resource, so we tend to be careful with it.
There is also a lot of ham activity at higher frequencies, where there is a lot more bandwidth available. For instance, a bit of the 2.4GHz spectrum used for WiFi is shared with amateur radio, so operators can transmit 1.5kW WiFi signals(!). Beyond the extra bandwidth, these frequencies simply don't propagate that far, so they're simultaneously lower risk and less useful; it may be worth considering a proposal to allow encryption on things in the microwave bands.
This was a big discussion in the US ham radio community recently. The FCC sought comments on a proposal to allow encryption in the amateur service, which was ultimately not adopted. Many amateurs were against it, but a few people thought its benefits outweighed its costs. Bruce Perens was pretty adamantly against it, and I think his arguments carry some weight: https://groups.google.com/forum/#!topic/digitalvoice/20brWmCCm2I
That said, the pragmatic nit-pick of "HF ham radio is actually different than networking" aside, the rest of your points still stand. We shouldn't be engineering the public internet around the constraints of amateur radio. Besides, it makes more room for hams to reinvent our own wheels (often rectangular), which is part of the fun of the hobby.
73 de AJ9BM
[link]