Notes from Tor meeting at FC04

Roger Dingledine arma at
Wed Feb 18 08:33:09 UTC 2004

We talked about a variety of things. I'm including some notes about it
here, for completeness. Ask if you want to know what I mean by something.

  Bandwidth classes, like in Morphmix. How do we do this so it works?
    The real answer for Tor is to refuse slow nodes for the production
      network. But we're not going to do that yet, because eager
      volunteers are far more useful.
  Allow having smallcells and largecells (128 bytes and 1024 bytes, say).
    No good reason why not. Some good reasons to.
    Let's do it. And in the future if we decide it's scary, we can just
      stop generating one type of cell.
  Non-clique topologies -- easy to implement, hard to decide topology.
    But need to implement sometime, because the real internet is already
      non-clique (e.g. the connection between moria and Tonga).
    We could adopt a variety of strategies, e.g.
    "Any node connected to >=80% of the nodes is marked as up, else down"
    But: Creeping death for decentralized reputation systems. Hard
      problem, needs more attention.
  path length
    3 hops, plus a random factor?
    Is the geometric distribution useful? maybe not.
    Let's throw away everything meant to counter learning where you are on
      the path. It's probably very hard to stop an adversary from learning
      that, anyway.
  Rendezvous point design and spec.
    I have a design and partial spec scribbled down on a napkin. I'll
      try not to lose the napkin, and when I get some time later I'll
      write it up into a real spec and we'll go from there.
  Interoperability with morphmix
    The Tor code can almost implement morhpmix as-is. The only distinction
      is when Alice is building her circuit. In both cases:
      * she obtains a list of possible nodes for the next hop
      * she picks one (or has already picked one)
      * alice picks a witness (if necessary), and extends to chosen
        next node.
      The difference between Tor and Morphmix is simply in how the set
        of possible next nodes is gotten, and some more complexity in
        the 'extend' operation.
    Tor is going to become the official Morphmix implementation too,
      if we get around to doing it.
    We should add it into the spec too.
  Some parts of the spec are considered dangerous to use
    E.g., truncate, truncated, exit-from-middle.
    Let's stop using them, but leave them documented in the spec.
  Synchronous design?
    Nice idea, but it's not Tor.
  Helper nodes?
    Maybe. Keep thinking.
  Add a bit of long-range dummy traffic? Not worth it, Matt says
  Put IPs in directory, not hostnames. keeps OPs from stalling on resolves.
    Yes. And Nick volunteered to move everything to IPv6, at least
  Directory needs to indicate which dirserver signed it
  'directory authority' is the right name, not 'directory server'
  Our consensus directory scheme is broken. We need to do true secure
    reliable broadcast. Need to learn more first.
    Much work needs to be done. Start by finalizing the spec, and
      aim for forward-compatibility in the code.
  Extensible spec:
    - e.g. 'router' line more flexible in descriptor
    - split spec file into mini spec files? finalize some, leave others
    - e.g. if no torrc, use acceptable defaults.
  key rotation:
    tls key rotation
      symmetric (easy)
      asymmetric (hard: need to start new parallel tcp connection?)
    onion key rotation
      circuit key -- only relevant for long-lived streams--who cares.
  Advanced directory servers
    Figure out how to do threshold directory servers
    "secondary" directory servers?
      what does it mean for a directory to be valid? do they expire?
  Leave preferential per-connection bandwidth limiting
  Pre- or post- tls alternate auth mechanisms: ldap, others?
    Probably easiest to do auth inside a special auth cell.
  What we could get from windows developers: UI and Usability
  Find some way to report whether bandwidth limit is being hit.
  Begin reputation architecture: kill -USR2 prints opinions about nodes.
  Instrument 'connected' cell:
    Our performance is spotty sometimes, and nobody knows why.
    We should try to collect stats to figure out why.

More information about the tor-dev mailing list