Re: [freehaven-dev] Request for comments: onion routing designpaper

[seph <seph@mit.edu>]

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.
>
> http://freehaven.net/tor/tor-design.pdf

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
  cite?" 

  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
  people run.

  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
  introduction points.

  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
  research topic.

  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
  place.

  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.

seph