Re: OR partial todo file

[Andrei Serjantov <aas23@hermes.cam.ac.uk>]

Ok, well if you have started a serious design thread, I will continue.

(My status: trying to sort out how I am going to run OR here in the lab
and getting 2 machines to an appropriate state)

> Obvious things I'd like to do that won't break anything:
>
> * Abstract out crypto calls, with the eventual goal of moving
>   from openssl to something with a more flexible license.

Yes. Sigh. We want to be able to GPL this code.

<uncontroversial things deleted>

> * Since my OR can handle multiple circuits through a given OP,
>   I think it's clear that the OP should pass new create cells through the
>   same channel. Thus we can take advantage of the padding we're already
>   getting. Does that mean the choose_onion functions should be changed
>   to always pick a favorite OR first, so the OP can minimize the number
>   of outgoing connections it must sustain?

The idea I had about this is that all connections from a particular OP go
to the first router (via the constant-padded OP -> OR_1 link) and can then
go via an arbitrary route to the destination. I think this is ok
anonymity-wise.

> * 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'd like more than 4 bits for Version. :) More generally, we may want
>   to increase sizes of various things in the onion. I haven't looked
>   much at the onion code yet.

Should not be a priority...

> * 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?

> * We currently block on gethostbyname in OR. This is poor. The complex
>   solution is to have a separate process that we talk to. There are some
>   free software programs we can use, but they'll still be tricky. The
>   better answer is to realize that the OP can do the resolution and
>   simply hand the OR an IP directly.
>   A) This prevents us from having the name resolve differently at the
>      OR than at the OP. I'm ok with that.
>   B) It actually just shunts the "dns lookups block" problem back onto the
>      OP. But that's ok too, because the OP doesn't have to be as robust.
>      (Heck, can we have the application proxy resolve it, even?)

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)

>   We should look into a 'topology communication protocol'; there's one
>   mentioned in the spec that Paul has, but I haven't looked at it to
>   know how complete it is or how well it would work. This would also
>   allow us to add new ORs on the fly. Directory servers, a la the ones
>   we're developing for Mixminion (see http://mixminion.net/), are also
>   a very nice approach to consider.

Well we need to decide how to solve the n^2 problem anyway... See later
chat about padding.

> * Should ORs rotate their link keys periodically?

Yes...

> * We probably want OAEP padding for RSA.

Don't understand.

> * Padding between ORs, and correct padding between OPs. Currently

I think this is a new thread, I'll post my reply to this in a separate
message.

> * Make the connection buf's grow dynamically as needed. This won't
>   really solve the fundamental problem above, though, that a buffer
>   can be given an adversary-controlled number of cells.

Yep.

> * Reply onions. Hrm.

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

A.

------------------
Andrei Serjantov
Queens' College
Cambridge CB3 9ET
http://www.cl.cam.ac.uk/~aas23/