Re: tor-spec comments

[Roger Dingledine <arma@mit.edu>]

On Sat, Aug 30, 2003 at 01:05:53PM -0400, Joel N. Weber II wrote:
> The sshv2 has some message types that explicitly exist to support
> padding, so I'm not sure I buy this.

There are a number of types of padding we're looking at. First of all
is simply padding transmissions to a fixed-size cell. I agree that it
looks like TLS can do that too (assuming your cells aren't more than
256 bytes -- and currently that's our cell size and we're thinking about
growing them). But in any case, we can pad our cells before we deliver
them to TLS.

Second is link padding -- that is, sometimes sending cells from one
router to the next that have no data in them at all, to avoid
giving observers an idea of how much traffic is being carried. This
is also something that can be done with tls at the link level, because
the nodes themselves decide when and what to send, and the link level
doesn't care what happens to it on the other side.

Third is circuit-level padding, or long-range dummies. That is, sending
cells partway down the circuit. This is part of our 'leaky pipe' design
(http://archives.seul.org/or/dev/Apr-2003/msg00010.html), which lets
connections exit from nodes partway down a circuit, and also lets us
extend a circuit that's currently in use. TLS looks less appropriate
for the circuit level, because we want cells to not grow in size as the
circuit length grows, and also because we want some control over the
representation, so nodes can detect if a given relay cell is for them.

> It does seem like if you can get the ability to run onion routing on
> less trusted nodes that have low bandwidth connections, that
> initiating a connection anonymously is going to be a lot more
> effective.

Take a look at the Tarzan and Morphmix designs for this approach. They
still require a lot more research to be as convincing as tor is (and
tor isn't very convincing).

Onion routing assumes that most of its operators are nice guys
intending to keep their network's traffic private. It aims to solve
traffic analysis, eg a curious or threatened operator, but not traffic
confirmation (endpoint attacks as you describe).

> I'm also not sure if resisting the simplest traffic analysis actually
> buys you anything, if there's another attack that takes an extra week
> of programmer time but the same amount of computing resources.

I don't think it's a matter of spending more time thinking, to attack tor
more effectively. I think it's a matter of expanding your surveillance
network. The more you see the more you know; and if you didn't see it,
thinking about it won't help. But let's write some more papers before
continuing this paragraph.

> What I would like is to be able to use OpenPGP to verify the identity
> of various servers, with seprate trust paths to each, and a sense that
> the various server operators I'm depending on aren't really all that
> close to each other.

Check out section 6 of http://mixminion.net/minion-design.pdf for a
discussion of why it's dangerous to have each user have a different
perspective on topology or node selection. But again, more research
remains.

> Also, if the middle of my onion path is some random untrusted node,
> that doesn't actually add any risk, as far as I can tell, and defends
> me against the cabal a bit, assuming the cabal doesn't happen to be
> secretly running it.

Well, even middle nodes can insert timing signals into the channel,
and try to detect them at either end (or elsewhere in the channel).

> And you always have the potential for lurking buffer overflows in code
> paths that you don't test.  I suspect if you were using OpenSSL rather

You should get your terminology right. We *are* using OpenSSL. We're
just not currently using SSL.

(Not that you could know, because we haven't given you any code. Bleah.)

> What do 1GHz Athlons cost these days?  Is it really the case that
> people aren't going to be able to buy a stack of 10 or 20 machines if
> that's what it takes?

Certainly. You have some spare bits on your coloc so you're willing to run
a program for me; that doesn't mean you're willing to buy more hardware,
use more space on your rack, etc for me. Plenty of coloc machines that
mostly run Apache have pretty weak processors; the goal is to push the
bits out, which is easy.

> Are you using optomized versions of all the crypto algorithms?  You
> really should be microoptomizing the assembly code long before you
> start microoptomizing the protocol.

I'm not going to touch the crypto algorithm code. We're assuming the
OpenSSL guys (or in the case of AES, the AES guys) did them well enough,
and if they didn't, hopefully somebody will come along later and do
them better. Mucking with crypto code is a sure way to not be using the
primitives that you think you're using.

> What do you expect these people are going to do with their CPUs if we
> don't give them crypto to run?

True, but we still need to make sure it runs on their CPU. And I want
to play well with the other programs they might be volunteering to run,
like Mixminion.

--Roger