[liberationtech] Oakland Cryptoparty This Sunday at 1pm

[Rich Kulawiec]

On Fri, Jun 14, 2013 at 06:34:42PM +0200, Eleanor Saitta wrote:
> The issue with this approach is that maintaining infrastructure like
> this takes an ongoing time commitment by someone who is clueful (and
> thus at least moderately expensive for broke organizations where
> everyone's constantly overworked), and that older hardware fails, and
> keeping enough spares around to get reliability adds cost and
> complexity again.
> 
> I'm (definitely) not saying this is a bad idea here, but it's
> important to understand what the real costs look like for
> organizations that may not natively have this talent, or where the
> folks who are supposed to do the work also have other jobs.  For
> instance, in every small org that I've seen that does development and
> has infrastructure, infrastructure-only hires quickly get absorbed
> into development work.

All entirely valid points.  I'm going to comment on them below but
will observe that at this point, it's actually not hard at all to
keep a *lot* of spare hardware around.  Much of it's free for the
taking: folks are happy to get rid of it and are delighted if someone
backs a truck up to their loading dock.

But that's kind of a minor consideration, and your point about the
time/labor investment is a much larger and more important one.

> Running mail as reliably, securely, and conveniently as Google does
> with GMail is actually hard; this is why it's achieved the popularity
> it has, not just the cost.  I've watched many friends and orgs over
> the past 9 years decide they just didn't have the time any more.

I'm often puzzled by why so many people seem to hold Gmail in such high
regard.  IMHO, Gmail merits only a gentleman's C, no better. [1]

That's not bad by comparison.  Yahoo?  F.  Hotmail?  F.  AOL?  D. (AOL used
to be up to about a B, but after dismissing the entire postmaster/abuse
team that did such excellent work, they've regressed badly.)

Now what Gmail *did* have was a fairly slick user interface, although like
so many sites, they've taken a modestly clean, usable UI and cluttered
it up with crap.  And more crap.  And still more crap.  It's well on
its way to become horribly bloated unusable rubbish, and I'm sure that
in another revision or two it'll complete the journey.  Yay UI designers!
Mission accomplished.

Shifting gears, your point about the effort required to "do it yourself"
is valid.  And important.  But there's another side of this:

You're certainly correct that running your own SMTP/DNS/HTTP/etc. requires
a skillset and effort.  Vendors of these, who make their money by
convincing people that it's oh so very hard and that they simply
must outsource these tasks, have done a great job of promoting a
culture of learning helplessness over the past decade-plus.

But it's not that hard.  I think anyone with baseline system admin
skills should be able to handle it, and for many years, THEY DID.

Sure it's gotten a *little* harder, but the tools have gotten much
better too.  I think at this point a lot of the apparent difficulty
that people repeatedly bump their heads against is self-created:
it looks hard to them *because they made it so*.  Real world example:

	Problem: Oh dear, our Exchange server has been 0wned.  Again.

	Asserted root cause: Our firewall is inadequate.  Our IDS/IPS isn't
	good enough.  Our antivirus software is outdated.  We haven't kept
	it fully patched.

	Asserted solution: Outsource the Exchange server to $PROVIDER.

	Real root cause: Exchange.

	Real solution: Don't run Exchange.  It's expensive crap.

Of course when things like this are pointed out, there follow
of litany of justifications and rationales and excuses.  The denial
runs deep.  Very few will actually take a moment to tip back their
chair, stare at the ceiling, THINK, and realize that they made the
real mistake when they signed the purchase order (or perhaps when
they were scribbling on the whiteboard), and that nothing they
can possibly do now will truly fix the situation *unless* they back
up and fix the original error.

But that would require admitting it, which is why it rarely happens.
I've watched people pour rivers of money down the toilet desperately
trying to fix unfixable problems rather than admitting they screwed up,
throwing it away, and starting over -- which would yield far better
results faster and cheaper.  Nope.  They can't bring themselves to do it.
They're too deeply invested in their own mistakes to undo them.
It would be, as they say, a career-limiting move.

So if one makes poor choices in architecture, systems, applications, etc.,
and stubbornly sticks with them, then yes, this problem set can be
made very difficult and very expensive.  And then, *yes*, it can seem
a very attractive option at that point to sidestep the whole mess
by outsourcing it.

But that doesn't undo the poor choices.  It just sloughs the problem
set off on someone else, it costs money, and it seriously degrades
one's security/privacy position.

I think it's better to make good choices.  Even if it takes three tries
to get to them.


There's also something else that can be taken advantage of here:
cooperation.  Three hypothetical organizations, let's say, one working for
women's rights in Afghanistan, one working for clean water in
Haiti, and one working for copyright reform in France, can cooperate.
They can secondary each other's DNS zones.  They can share the work
of configuring MTAs.  And so on.  This sort of thing buys each of
them a measure of support along with a modicum of DoS resistance.
It's not the best that can be done, of course, but "the best" costs
a fortune.  (And it means relying on services which may be quite
thoroughly backdoored and/or who may be in turn outsourcing to
countries/companies/people with agendas of their own.)
So this approach is probably good enough most of the time.

AND on top of that: there are a heck of a lot talented people out
there who could be persuaded to volunteer some of their time.  Linux
User Groups are one place they can be found, but certainly not the
only one.  Building a cooperative talent base among organizations
and growing the pool of expertise benefits everyone.

I suppose, to bring this all together, what I'm saying is it's better
to build a non-structure of loose cooperation than to outsource to
providers who will inevitably draw attention from nation-states and others.
In other words: avoid being targeted *by not building a target*.
Or perhaps more accurately, avoid being targeted en masse by not
doing adversaries the favor of offering them one-stop shopping.
Now, to your point, this probably requires more effort, maybe more
expense; it's not as easy as tossing the problem set and a check
in the direction of $PROVIDER.  But I think it may be worth it.

---rsk

[1] Gmail is not as reliable as you might think -- see the "mailop" and
"outages" list archives for discussions on that point.  Their anti-spam
false positive and false negative rates are much too high.  They emit
unacceptably high levels of outbound spam and support far too many
spammer dropboxes.  They use email quarantines -- a worst practice in
mail system engineering.  (Ask RSA how that's working out for them.)
They use content scanning, which is already highly unreliable and
getting worse.  They do not respond to traffic to RFC-2142 mandated
role accounts in a prompt and professional manner.  And so on.