Notes from Tor meeting at FC04
arma at mit.edu
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.
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
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
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.
Nice idea, but it's not Tor.
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.
- 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.
tls key rotation
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