[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [freehaven-dev] Request for comments: onion routing designpaper
Roger Dingledine <arma@MIT.EDU> writes:
> We've finished the first (rough) draft of our design paper for Tor
> (The Second-Generation Onion Router). Please read it and comment.
various comments, some editorial, some meaningless, some less so.
page 3, column 1, paragraph 4: you discuss JAP. It seems like it's
be worth mentioning the recent brouhaha where JAP's client was
backdoored. (the authors introduced some logging at the request of
the german government). though it's not a technical weakness
specific to JAP, so I'm not sure it really belongs.
page 3, column 2, second to last paragraph: "XXX What's a better
page 3, column 2, last paragraph: "Tor relies on a centrally
maintained set of well-known servers" I would think this makes it
trivial to attack, either via law or DoS, either making it
useless. This may be addressed later, or may be out of scope, but
consider mentioning the drawbacks. (section 5.3 doesn't really
mention DoS attacks on them either)
page 4, column 1, paragraph 2: "Free Haven" looks funny to me when
it has a linebreak in it. YMMV
page 4, column 1, paragraph 6: "will not need to reinvent Tor's
design decisions." this is an awkward sentence, "reinvent" and
"decisions" don't match. YMMV
page 5, column 1, paragraph 2: "DoSing"? ew, perhaps it's accepted
in your target audience. I'd use DoS'ing, but is also ugly, or
consider spelling it out. YMMV
page 5, column 1, paragraph 4: "section ??"
page 5, column 2, paragraph 1: "section ??"
page 7, column 1, paragraph 2: you mention that modifying the local
name server is invasive and brittle. then you say you provide a tool
similar to dig that does lookups through Tor. IMO in addition to a
dig-like tool, you should provide (or just encourage) a simple
caching nameserver suitable to replace the caching only servers most
page 7, general: this may reflect more on me that the paper, but I'm
a little confused about teardown. In section 4.2.2 you mention that
relay cells are encrypted and that this is good because Alice can
send teardowns without the hops knowing. However, My impression was
that the hops propagate the tear down message forward, so only the
earlier hops don't know. Also, there are several cases when a hop
initiates a teardown, I'm a little confused about what get's
encrypted to who in that case.
section 4.5: "tor uses the token bucket approach" Is this some
standard thing, consider a cite.
section 5.1, page 9: "backtracking harmful traffic [?]" (fix the cite)
section 5.2, page 9: "[XXX Mention possibility of filtering...]"
section 5.3: discusses partitioning attacks, is there a cite?
section 5.3, second to last paragraph: "When a client Alice
retrieves a consensus..." the phrase "a client alice" feels awkward
here, consider removing the "a client" or rewording.
section 6: Bob wants to provide a robust pseudononymous identity, so
he can't tie it to a single OR. However, he needs to maintain an
open circuit to every OR tied to his identity. This doesn't seem
like it scales very well.
section 6.2: while bob can reject a connection, thus preventing a
DoS from eiting him, it still eits the ORs he's advertised as his
section 6.2: lots of "XXX"
section 6.3: since authentication tokens are options, consider
y.x.onion instead of x.y.onion. It seems cleaner, and better fits
the dns model.
section 6.4: did I miss where you defined "DHT"
section 6: With all this rendezvous-action, I'm concerned about how
latency is effected. You should mention it, even if only as a future
section 7.1: Usability should re-reference the dns lookup problem
section 7.2: it's really long. consider splitting to 7.2.1 and
7.2.2, or whatever.
section 7.2: XXX, and if it's outside your threat model, say so.
section 7.2, active attacks, iterated compromise: If an attack can
march the length of a circuit, then they can installing some sort of
logging on the nodes, defeating the lifetime cutoff. What percentage
of nodes needs to be compromised for this to still be effective when
combined with traffic analysis? (though some of this is covered later)
section 7.2, introduce timing into messages: you said it's discussed
"above" above was more than a page ago. consider "earlier" instead.
section 7.2: directory attacks and rendezvous points are
incomplete. (I know I commented on it earlier in this)
section 7.2: consider the "trojan code" attack (as of JAP)
section 8: more XXX
section 8: "throughout this paper, we have assumed that end-to-end
traffic analysis cannot yet be defeated. But even high-latency anon
systems can be [analyzed]" as the sentences agree, "but" is out of
section 8, last paragraph: "section ??"
you discuss how having exit policies will encourage exit nodes, by
letting admins not access frequently abused things. You should
distribute several example exit policies, as many admins won't know
what the frequently abused things are. Also, consider some sort of
centrally maintained exit policies, to let sites being abused escape,
and to coordinate. (though I haven't thought through a central list
very hard, I'm sure there are some problems with it)
It's great to see Tor coming along.