Re: OR partial todo file

[Roger Dingledine <arma@mit.edu>]

On Thu, Jun 27, 2002 at 03:35:00PM +0100, Andrei Serjantov wrote:
> Ok, well if you have started a serious design thread, I will continue.

We've got OR code that works and seems robust to basic use. Now's
the time to figure out what features we actually want, and how hard
they'll be to get.  Like you and Matej, I'm not happy ignore traffic
confirmation attacks. I want to make this thing as secure as we can,
with modern approaches.

At the same time, though, I recognize that currently low-latency
designs are more vulnerable to traffic analysis/confirmation attacks than
high-latency message-based designs. That's the whole reason we started the
Mixminion project. You guys (at least Andrei, Paul, Matej) should go read
the minion-design document at http://mixminion.net/, because it brings
up a lot of issues that the current onion routing designs don't even
realize are problems. Specifically, consider sections 3.1, 4.4, and 5.

> > * Add autoconf support.
> >   Figure out what .h files we're actually using, and how portable
> >   those are.
> 
> You are replying on glibc 2.2, as I discovered while trying to install it
> on an old machine...

I shouldn't be. Not much, if I am. What needed glibc 2.2?

> > * Exit policies. Since we don't really know what protocol is being spoken
> >   to the application, it really comes down to an IP range and port range
> >   that we allow/disallow (in various combinations). The 'application'
> >   connection can evaluate it and make a decision to accept or reject.
> 
> Do you really care that much about who the connection goes to?

Not much for web traffic; but perhaps quite a bit for mail traffic.
Running an open exit relay for mail traffic is a good way to get a whole
lot of abuse complaints. Without firm support from your ISP, your node
will disappear quickly.

> Errr... If an OP does a gethostbyname call, it's about to make an
> anonymous connection to that IP. This breaks anonymity (unless I am being
> totally dense and not understanding something)

Damn. You're right.

> > * We probably want OAEP padding for RSA.
> 
> Don't understand.

Without oaep, things encrypted with RSA can be modified but still
accepted. I need to look at the protocols we use more to decide if this
opens up any vulnerabilities. I noticed that we don't have integrity
hashes in very many places; this can open us up to tagging attacks,
among others.

> Hrm. Leave for now. Complicated problems... You are the best-placed person
> to solve them having done mixminion. Let's do the above first.

I would like to encourage you guys to peruse the mixminion archives,
at http://archives.seul.org/mixminion/dev/, and then join the
mixminion-dev list (send mail to majordomo@seul.org with a body of
'subscribe mixminion-dev'. These projects are very similar, and many of
the pieces (such as directory servers) can be entirely shared between
them. I'm going to be splitting time between them, but at this point
I'm more hopeful that Mixminion will be a secure thorough system that
people should actually use. It's an easier problem than onion routing,
so we figured we'd tackle it first and gain some experience -- and I
still plan to take that approach.

--Roger