tor-spec comments

[Roger Dingledine]

[Responding to the list, so we can make the threads public.]

These are all good entries for the FAQ. Unfortunately, a lot of them will
be addressed by the (not yet written) tor-design.tex document. For now,
read http://freehaven.net/anonbib/#syverson_5f2000 as an intro to the
basic ideas and security arguments (but recognize that we're talking
about a slightly different design).

The goal of the spec isn't to discuss security implications; it's just
to say how to do things. Hopefully in not too long (depending on other
priorities) tor-design.tex will help explain motivations.

On Fri, Aug 29, 2003 at 04:07:36PM -0400, Joel N. Weber II wrote:
> 1) I really don't understand what would be wrong with using TLS as the
> basis for a secure channel, with some sort of multiplexing layer on
> top of that.
> 
> I'm thinking of a system in which you have a secure channel between
> each pair of connected onion routers, and then the client builds a
> stack of nested TLS sessions for each hop it wants to route through.

Yep. This isn't a crazy idea. I think peekabooty had a similar plan.
Brandon Wiley (blanu) also suggested just using ssh port-forwarding to
build up a bunch of ssh tunnels within tunnels.

Doing it with nested ssh's is quite inflexible though, because we want
to be able to experiment with link padding, use fixed-size cells so an
observer can't distinguish control cells from relay cells, etc.

Doing it with TLS might well be feasible. Certainly our circuit-building
protocol is kind of like TLS (albeit simpler).

Paul, Nick, want to try answering this more thoroughly? It needs to
go in the FAQ, because people keep asking it (or if we can't answer it
sufficiently, we should start looking at switching).

> 2) The protocol appears to, in some cases, simply encrypt session keys
> in long term public keys.  (I think when communicating between one
> onion router and another.)  You don't want to do that.  You want to
> always use diffie-hellman to negotiate keys, and authenticate that
> diffie-hellman exchange using public keys (or perhaps use ephemeral
> public keys), so that you can throw away the private keys periodically
> such that an attacker who eventually recovers the long term keys won't
> be able to read the old traffic.  (But maybe I didn't read carefully
> enough.)

You are totally right. The negotiation when building a circuit is DH,
which is what we want, but currently the OR-OR handshake is inherited
from the old design from several years ago. Updating the OR-OR handshake
is on the todo list.

I'd actually like to solve link key rotation at the same time as I update
the handshake protocol. It would be nice if establishing the first key
is pretty much the same operation as rotating the key, so we can keep
the design simple. More design work remains. Feel free. :)

> 3) I don't see any real discussion of whether having fixed sized
> packets is important, and why.  Furthurmore, the comment about link
> padding being left out makes me think that perhaps you're designing a
> protocol around assumptions that are not well-understood.

The cells are fixed size to reduce vulnerability to traffic analysis.
Fixed-size cells plus encryption is a great combination against the
simplest traffic analysis attacks. We could do mixing, batching, or
delaying down the road to get better protection; whether this will be
worth it requires more research though.

It is absolutely the case that we're designing a protocol around
traffic analysis resistance assumptions that are not well-understood. The
anonymity field is very young. Part of the goal of tor is to actually
try building an infrastructure based on some of the current assumptions,
and see which parts are easy and which are hard.

We also aren't totally clear on what adversary we defend
against. Rather than picking a very weak adversary and proving
security, which is one approach of academic systems, we want to
build as strong a system as we reasonably can, while still paying
attention to other factors like usability (and usability directly
influences security -- see eg http://freehaven.net/anonbib/#back01,
http://freehaven.net/anonbib/#econymics).

> 4) It doesn't seem to be explicitly stated in what I've seen thus far,
> but it seems like you very much want the onion routers to be very well
> known, but the clients are anonymous.  (I guess it is implied.  But
> this seems like an important point.)

Yes, the onion routers are going to be a relatively stable group. This is
so we can resist Sybil attacks (http://freehaven.net/anonbib/#sybil) by
requiring manual intervention to add routers, and generally because our
directory system and long-term circuit concept aren't really conducive
to a high churn rate for routers. We could instead use a more p2p
design, like Morphmix (http://freehaven.net/anonbib/#RP02-1) or Tarzan
(http://freehaven.net/anonbib/#tarzan:ccs02). But part of the goal here
is to get something reasonably understandable and analyzable out and
having actual users, and see what happens. P2P systems have even more
surprising side-effects than distributed client-server architectures.

Right now we're really quite limited because we're expecting the
routers to form a clique (ie, every router connects to every other
router). Down the road we plan to investigate restricted topologies,
which improve scalability and also can allow more efficient padding
(http://freehaven.net/anonbib/#pet2003-danezis).

> 5) Negotiation that allows the end user to pick their favorite set of
> options is obviously bad for their anonyminity.  However, I'm not at
> all convinced that having a couple of distinct sets of options out
> there would be a bad thing.

I'm not convinced either way either. On the other hand, having ways
of doing things which the developers don't use is a sure way to have
lurking bugs. So far in each situation we've been able to decide on
one way to do it and drop the other ways. But for instance (for a
recent example), allowing onion routers to support router twins or not
(http://archives.seul.org/or/dev/Aug-2003/msg00003.html) seems innocent
enough. So I think we take it case by case.

> 6) If an attacker can modify data in transit, that might or might not
> be a problem; it seems that in many cases, you aren't
> encrypting/intergity protecting once you get onto the general internet
> via the exit proxy anyway, and in other cases you're going to be using
> TLS anyway.

Correct. The adversary can still just give us the wrong file, eg if he is
the webserver, if he controls link from the exit node to the webserver,
or if he controls the exit node in our circuit.

But on the other hand, I think the chances of you getting in between
me and my sourceforge download are realistically quite small. But here,
even a weak adversary can volunteer to be a router in between me and my
sourceforge download. So it's something we need to look at carefully.

If the user cares, he should be doing his own end-to-end authentication
and integrity checking.

> 7) You seem very opposed to designing a system that's anywhere near as
> conservative as what Schneier and Ferguson are recommending.  I think
> that plus a lack of negotiation is going to prove to be a really bad
> thing in the long run.  krb5 took forever to get anything more than
> 1des support; I think it took a couple years after the EFF said ``hey
> look, we can crack this easily in a couple days, and we have *actually
> built the hardware for it*.''  And that's in spite of the protocol
> having an enctype field.

That could well be true. We're young and naive designers at this point,
after all. :)

But on the other hand, I think for at least the alpha design and
deployment stages, I want to minimize the extra stuff I need to support.
Once there are more than a few developers and more than a few users,
we can start to consider how things will fall apart a few years down
the road.

One of the tricky things about tor is that I'm desperately trying to keep
it simple and easy to understand, but at the same time I'd like to plan
for actual users and user demands. Perhaps it will slowly evolve into
something as complex as Freedom, and then some other person will jump
up and say "we should build a simple one!" and the cycle will start again.

But on yet another hand, if we get some good clean usable free code out
there, we'll be doing a lot better than most projects.

I don't think the crypto is going to be the way to attack tor
anyway, assuming we do a halfway decent job. Traffic analysis and
social-engineering / human attacks will probably work much better.

> 8) If you're going to complain about crypto operations being
> expensive, as you seem to like doing, you're going to have to explain
> why you think it likely that you'll be able to get substantially more
> than a megabit per second of bandwidth for a machine in any
> significant number of common cases, or why a reasonably modern machine
> (much newer than xanthine.gratuitous.org ;-) can't keep up with that
> traffic.  I think we have a disagreement on whether N is in fact
> large.

I think it's definitely the case that we will have dozens of onion
routers with fully 10mbit or more pipes to the Internet. I've already
had that many people tell me they want to run routers and describe their
hosting facilities, and several of them are talking 100mbit or more. And
if we're going to have a fairly limited number of nodes, then we want
people with big pipes.

Whether our code can saturate big pipes in real-world situations remains
to be seen (we're still working on getting approval for an Internet-wide
beta network). But even if we can only barely fill up a 10mbit machine
(I think my 1GHz Athlon can fill between 5 and 10mbit now), I don't
want to be asking these volunteers to give me all of their CPU too:
it would be really nice if this was a typical unnoticed network daemon.

Thanks for the questions. Keep 'em coming!
--Roger