[liberationtech] How to make the Internet secure

[Rich Kulawiec]

Many of these kinds of proposals are wonderfully thought out BUT
they presume underlying network infrastructure that (a) exists
(b) has sufficient performance (c) is not heavily censored/blocked
(d) is not heavily monitored/surveilled.

The problem with that, as everyone here probably knows all too well,
is that those assumptions are often not true.  In some places, they're
less and less true by the day.

So assume a country where connections from/to the outside world are
thoroughly blocked and heavily monitored, and where the ISPs are compelled
by the government to record and store data/metadata about everything
their users do.  Assume a country where VPNs and Tor are illegal
and/or are red flags to surveillance agencies.  Assume a country which
will shut down its Internet connection and/or its internal ISPs if
it wants to.  (These are plausible assumptions to make because in
some cases, they're already true.)

So even if all connections are encrypted, that won't suffice: the
endpoints won't be able to connect.  Even if they can, that won't suffice,
because it'll leave a very suspicious metadata trail.   Even if that's
avoidable, the end-to-end performance will be terrible.   Even if that's
acceptable, synchronous and direct communications will always be far
more dangerous than asynchronous and indirect communications because
it facilitates traffic analysis.  Even if that's acceptable, none of
it will work when the network's unplugged.

For these kinds of proposals to be viable under adverse circumstances --
which are the circumstances where they NEED to be viable -- they need to
be able to work over highly intermittent/slow connections (e.g., ad hoc
connections that don't traverse any ISP's broadband infrastructure)
and over sneakernet.

*Especially* over sneakernet: I think that's an absolute must-have.

For example:

	1. Mail queue written onto a USB stick or memory card or similar.
	2. It's smuggled into a location.
	3. It's plugged into a system which delivers the queue locally
		and/or via wifi and/or bluetooth.
	4. Same system collects traffic going the other way, then
		2 and 1 are reversed.

This is a model somewhat like Usenet in the days of UUCP connections
over dialup -- with the wrinkle that we didn't have to commit queues to
9-track tape and physically transport them very often.  But an awful
lot of mail will fit on a 2G memory chip -- and that can be concealed
in almost anything.  In slightly less hostile circumstances, a USB stick
or portable drive could hold far more.  And just as once upon a time we
were admonished to "never undestimate the bandwidth of a station wagon
full of tapes" we should not underestimate the bandwidth of a backpack
full of drives.  Heck, a single one would easily suffice to transport
hundreds of newspapers' worth of news plus photos plus audio plus video
(in) and to transport an equivalent amount of text, audio, video,
photos, etc. (out).

(As a site note, let me note that there's also good reason to think
about the Usenet flooding model, because it makes traffic analysis
difficult: everything is delivered to everyone.  I wrote a proposal
a few years back to leverage Usenet news plus encryption to create a
highly asynchronous, indirect communications method that would suffice
to get email and news in/out of countries with NO external connectivity.
Plus: almost all the software already exists, it's well-understood and
mature, it scales indefinitely, works over intermittent and slow links,
works over sneakernet.  Minus: arguably inefficient, somewhat vulnerable
to DoS, requires rethinking duplicate detection problem.)

If you'd like a contemporary use case for this: Cameroon.

I am, by the way -- and this is a nod to your preamble about
incrementalists and absolutists -- firmly in the middle.  There are a
number of things that we're doing (and have been doing) that we need
to stop doing immediately, and some things we don't do that we need to
start doing yesterday.  That's the absolutist part.  The incrementalist
part says that we should not be tinkering with machinery that has proven
itself to be very robust in the face of determined attacks *unless*
the replacement parts we have in mind can demonstrate that they'll be
just as resilient.  For instance, I'm highly dubious about JSON email,
which I think is far more likely to introduce gratuitous complexity,
creeping featurism, and horrible code bloat -- and thus massive security
and privacy issues -- than anything else.

---rsk