Re: Batching Strategy and Network Structure

[Wouter Slegers <wouter@yourcreativesolutions.nl>]

On Wed, May 22, 2002 at 08:04:02PM -0400, Roger Dingledine wrote:
> I feel confident that a synchronous mix-net is going to provide better
> anonymity than its asynchronous counterpart, *if we do it right*. But
> it also seems that it's harder to do it right.
That is my impression also. And synchronous mix-nets seem much more
vulnerable to DoS or degradation attacks (and availability is an
important factor in getting the mix-nets accepted by the users).
I'd prefer asynchronous mix-nets because they seem much easier to get
deployed.

> But more generally, do we want to try to fold this stuff into what we
> plan to build, or leave it out until later? We've got a couple of options:
> 
> a) Put off spec and coding until we have a design we're happy with. I
> think this is a bad idea, because it'll be another year until we're
> happy with a radical change like this.
As a relative outsider: without a spec (even as a rough draft) it is
difficult to define what the current design _is_. This makes it hard to
evaluate the impact of changes in the design (synchronous vs
asynchronous for example) and makes objective comparison in the results
even harder. At the moment, because the group is tightly knit and small,
divergence of the ideas on what the current design is, has only
occasionally interfered. When the group expands, this will become a
serious problem.
My suggestion is to mark the spec explicitly as "for discussion and not
for implementation" and release it within the mailinglist.

> b) Ignore all of this new-fangled stuff and just build the asynchronous
> network we started with. This may also be a poor choice, because we'll
> be unhappy with the anonymity it provides, so we'll always be looking
> toward the 'second system'.
On the other hand, we can't keep up improving it. At some point, it
needs to be good enough to release/implement. Because we have not
decided on some form of security requirements and/or a description of
what "the enemy" can and cannot do (and mixminion must protect against),
we do not have an objective measurement when the design reaches this
point. I think we should either "ship" the spec if it feels good enough
and set a timelimit for this decision, or define objective requirements.

As I said, I'm willing to do this requirements work iff it is actually
used (Common Criteria docs are not that exciting that I want to do it
just for the fun of it).

> c) Open up the protocol as described above. Have the protocol be quite
> flexible, and have "suggested user behavior" be a subset of the protocol.
> We can then revise suggested behavior as we gain more intuition and
> solve more problems.
I'm in favor of a protocol that can be extended easily, because it will
allow more gradual upgrading when new functionality is needed to solve
problems (compare with the problems we have now with the switchover),
even though this increases the amount of possible behaviours and
therefor increases the chance on insecure modes.

Another way of looking at the decision on what limitations should go
where:
The protocol (without the MUST NOTs) describes the space of actions that
can be performed.
Limitations on the total space of behaviours are sometimes in control of
the user, by way of the actions in the headers requested by the user
(forward this to node X, swap the headers, drop, deliver to
blep@example.com, delay(?) etc) and sometimes in control of the nodes
(delay/reordening strategies, limitations on actions, replay blocking
etc). 
Node limitations should be such that the mix-net provides a minimum (but
sufficient) level of anonymity to an user regardless of (malicious or
stupid) behaviour of other users. Honest nodes following the spec should
also behave such that regardless of other nodes behaviour, traffic
flowing through the node will be be anonymized (protection against
compromised nodes, a single uncompromised node in the path of a message
should be protect anonymity). 

User/client behaviour is for maximizing the anonymity of the user's
messages, against the user's idea of the type of threats against him and
balanced against the costs he is willing to pay for it (latency, higher
probability of loss of messages, more crypto operations etc).
Flexibility in the user's commands should be great, even though this
allows the user to shoot himself in the foot and not gain additional
anonymity. Defining a strongly suggested safe set of choices is needed,
but I do not think we should enforce that (if at all possible) with
built-in limits.

The big problem ofcourse is where individual behaviour compromises the
security of others (tragedy of the commons), but at present I do not see
behaviours of clients that could lead to compromittation of other
messages.

> Others: What's your take on this? How do you want to procede? (Your
> answer gets more weight if you do some of the work :)
:-) Come with the (draft) spec and/or say that a (revised) CC security
target is a brilliant idea and I can get on with some work :-)

With kind regards,
Wouter

-- 
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."