[tor-dev] resistance to rubberhose and UDP questions

[Mike Perry]

Thus spake Jacob Appelbaum (jacob at appelbaum.net):

> >>> 18:10 <@cjd> If someone (with government hat?) tells you they can make your
> >>> life hell...  I wouldn't fault them for doing what the man says.
> >>> 18:10 <@cjd> *wouldn't fault you
> >>> 18:10 <+eleitl> I'll try bugging some Tor developers about that scenario,
> >>> and see how they squirm.
> >>> 18:11 <+eleitl> Also, the UDP connection thing.
> >>> 18:11 <@cjd> You can "stack" your circuit setup packets if you're using UDP
> >>> 18:11 <@cjd> stack -> all headers in the same packet
> >>> 18:12 <@cjd> cjdns does the same thing
> 
> Huh. Wow. I just... Excuse me? Who suggests that no Tor developers
> haven't already had their arm twisted and stood their ground? Who
> suggests that those who run a Tor Directory Authority would comply with
> the "man" and what "they" say? On what evidence do they say these
> things? Do they understand the moral and ethical character of the people
> running those systems? No, they most certainly do not. Do they even know
> the history of harassment that Tor people have faced in various
> circumstances? No, they clearly do not know these things.
> 
> I certainly have had attempts, serious attempts by powerful people, to
> crush my spirit, to push me out of the anonymity space and to punish me
> for speaking out about anonymity as a fundamental human right.
> 
> I don't take kindly to anyone suggesting that 1) such harassment hasn't
> happened and 2) if it were to happen, we'd just roll over like a bunch
> of assholes.

I agree: the assumption was a little rude, and it's clear that cjd
doesn't understand what we're made of. It's an easy assumption to make,
though. After all, the world hasn't seen European Enlightenment values
seriously defended in at least 50 years (or more). :/

However, the real problem here is that the rubberhose attack vector
isn't limited to beating down the few renegade buddhists that the Tor
Project manages to somehow authenticate, locate, and vet as capable of
being beyond pain...

*Anyone* with *any* access to the data centers that host the directory
authorities is potentially subject to either a coercive or subversive
attack to gain access to a majority of the dirauth key material, and
thus generate fraudulent, targeted consensuses...


As you know, I've been digging down the rabbit hole of how to ensure the
integrity of a remote machine, and it seems impossible to do this
without both secure boot *and* a way to verify the current runtime
integrity. Without these properties, it would seem our current model is
untenable long-term.

Yet still, as Roger and Robert point out, there are some serious
questions about the viability of decentralized directory/consensus
systems. Or, at least questions that sexified attack papers can make to
seem serious. (For example: I don't believe TorSK was actually broken
beyond Tor's current properties...).


However, as a stopgap, perhaps we might consider a Perspectives-style
component/addon to HTTPS-Everywhere/TBB/Vidalia for multipath consensus
verification. For example, random people could publish signed statements
of the latest SHA512 hash of the current consensus for the hour to a git
repository or other append-only data structure. This repository could be
easily mirrored widely, and it would be trivial for mirrors to ensure
the integrity of their copies...

With such methods (which can surely start as manual-only), we can
provide multiple mechanisms of consensus validation in tandem, and the
security of the network directory would be governed by the security of
the union of all of these systems.

In fact, it should even be possible for Tor clients to store such
consensus hashes for later validation, to see if they had been
compromised at points in the past. One could even physically smuggle a
USB key out of a potentially targeted location to verify consensus
integrity from another location, at a later date...


Unfortunately, the fake consensus attack is arguably *not* the easiest
way to perform route capture on the Tor network today. It might be #2,
though...


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121006/ef7d9883/attachment.pgp>