Re: Is "gatereloaded" a Bad Exit?

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

On Sat, Feb 12, 2011 at 5:35 PM, John Case <case@xxxxxxxxxxxxxxxx> wrote:
> That's fair.
>
> Instead of stressing the boundless set of "pros", I will discuss a single,
> specific "pro", and that is the idea that open, arbitrary systems provide a
> foundation upon which to build surprising and unexpected combinations.
>
> I wouldn't think that a group of technical people, much less a group of
> technical people immersed in network architectures would need this explained
> to them.
>
> Then again, I didn't think we woud be referring to /etc/services as hard,
> physical laws, either. ÂYou live and learn, I guess.


This argument has fallen on deaf ears because in isolation it produces
nonsense results. That it is continually pressed while the substantive
arguments required to actually make a decision are ignored by the
people promoting this view makes them look like fanatics, at least in
my eyes. (And I was happily ignoring the thread until someone
commented that they had be swayed by the continued arguments, which
I'd not been bothering to refute)


If we were to take this argument openness/flexibility argument as hard
doctrine why would we not provide a facility for Tor to execute
arbitrary code shipped over from arbitrary users?  That would make tor
a truly "open, arbitrary system".

Of course we don't do this because it's highly insecure and no one
would run a tor daemon which did that. So in practice we must weigh
the benefits of the speculative features mobile code many provide vs
the costs of turning tor into a opensource botnet, and in _this_
analysis the "openness" argument provides little input, because it's
the _specific_ consequences of the decision which determine the best
outcome.

The "pro" you're proposing is not useful as a _specific_ pro, because
it fails completely as a specific _pro_ as the absolute majority of
the infinite number of arguments I could make under it would actually
be really bad ideas: It doesn't really do much to accurately separate
the space of ideas into good and bad onesâ especially in the domain of
security a lot of bad software is bad because it was too flexible for
the wrong users.

Flexibility is also sometimes mutually exclusive and what you exclude
(no buffer overflows!) can be as much of a feature as what you include
(run arbitrary code!).  As Geoff points outâ this class of argument is
fundamentally a pascal's wager.  Which God? Worshiped how? Which
flexibility? Implemented at what cost?

I grant that flexibility is a useful general principle, but one so
general that it would never be useful in making a decision by itself.
Not a specific benefit.  For example, I'd use the flexibility to say
that this policy should not be implemented in every single client,
which take forever to upgrade, but instead should be signaled via
directoriesâ so that the decision could be change quickly and easily.

So back to the case in question: We must look at the cost of excluding
an infinitesimal piece of flexibility (the conceivable uses of four
non-exit flagged exit nodes, is I believe what this policy would
impact today), vs a tiny piece of social policy (if you want to run an
exit node to :80, you're going to allow it to exit to :443 as well or
no one will use it, thus subsidizing port 443 capacity on the back of
port 80 capacity) and decreased incentive for tor users to run
personal exit filters (which would result in network partitioning and
reduced anonymity for everyone if widespread).

Like my botnet toy example, â the more flexible system would be
preferred all things equal, but all things are almost never equal and
so we fall to the simple balance of specific benefits. And it's very
difficult to argue for specific benefits resulting from permitting
nodes to exit to commonly non-encrypted ports while rejecting their
commonly encrypted counterparts, while the specific benefits of
rejecting these nodes are easily explained (if not all that
significant).


One of the side effects of the suggestion of this policy which I was
not expecting is that it caused some participants on this list to
expose their previously held mistaken belief that the Tor network's
technical inability to prevent exit sniffing was actually an explicit
approval of this unethical and probably unlawful activity. To the
extent that policy which is overtly sniffing hostile, if actually
ineffectual at preventing any sniffing, makes it more clear that this
activity is considered regrettable and not permitted then that can
only be a good thing as well.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/