Re: Thoughts on MixMinion archives

[Nick Mathewson <nickm@alum.mit.edu>]

On Tue, 2002-04-23 at 04:36, Len Sassaman wrote:

Hello again!  The points I skip below are the ones I either agree with,
or don't feel qualified to dispute yet. :)

  [...]
> * one shot at a backwards incompatible change
> 
> Lance said in our BOF that he thinks we only get one shot at a backwards
> incompatible change to the remailer network, and I agree with him. I'm
> stating this, because a lot of the things being discussed are orthogonal
> to the core protocol changes, it will be necessary to introduce them at
> once to minimize the number of remailer servers out there with
> compatibility problems.

Well, if we get the cap/type system straightened out enough, we may be
able to keep backwards compatibility indefinitely.  We should ponder
what backwards-compatible changes are considered for the future, and
which of them can be pulled into the Mixminion spec.

Also consider that, if we can make v3 succeed on a big social scale,
acceptance of a v4 would be higher down the road.

 [...]
> * random mix (black holes)
> 
> Since Mixmaster pulls messages out of the pool at random, there is the
> possibility that a message may get stuck in a pool forever. Is there any
> way of making sure this doesn't happen, without weakening the system?

If I understand correctly, all we want here is that the probability of a
message staying around for a long time should be vanishingly small as
the amount of time increases, without reducing the effective
probabilistic anonymity sets of any user.

There's been some good work recently (such as the 2 papers, one by
George, in PET2002) on quantifying anonymity for this kind of thing.

(BTW, although the spec _should_ specify a preferred mixing method,
there is no reason that different servers can't mix in different ways,
and specify their policies in their capabilities block.)

> * Delivery methods
> * http://archives.seul.org/mixminion/dev/Apr-2002/msg00035.html issues
> 
> Roger and George told me about the discussion of what to do with messages
> when they hit the last hop of the chain. I like the idea of having each
> node set its own exit hop policy. It could be "no unauthenticated
> delivery" (i.e., the current Mixmaster "middleman" mode), deliver via
> mail, deliver via IRP, hold in a pop-box, or user configurable (with a
> specified default.)

Actually, I'd like to see each of these be a different delivery method
(payload type), and allow nodes to support any combination of them.
 
> Since there is an IRP, we could have a retry system similar to SMTP where
> if the user/recipient is offline, remailer messages spool for him until he
> comes online and starts listening on the IRP port, and it times out
> eventually.
> 
> The talk in the above mentioned archived message about "SMTP extension
> modules" confuses me. Why wouldn't MixMinion just hand off messages to be
> delivered by SMTP to the local MTA?

Sorry about the confusion--what you describe is the intended behavior of
a SMTP delivery module.  The idea is to make all delivery methods into
isolated modulres, to make the security of the core easier to examine.

> * cap strings
> 
> We need to at some later point think of how we want to allow remailer to
> specify the features they offer.

This needs to be part of the spec.  Also in the spec should be:
    * how to request the cap block from a given node
    * how to get a list of nodes (and stats?) from a reputation server

These are necessary features, and if they're not in the spec, they'll
happen ad hoc.  If they happen ad hoc, fewer clients will support them,
and we'll have usability issues.

> * remixing type I to type II (to type III?)
> 
> Currently, Mixmaster has the ability to receive a Type I message and
> "remix" it using Type II. Basically, node A takes the Type I message and
> wraps it up as though it were a type II message, and sends it on to node
> B (assuming it has node B's mix key). Node B unwraps the Type II layer,
> then the Type I layer, than remixes it again if it can. Etc. This is an
> attempt at keeping the anonymity set as large as possible.
> 
> Would we want to do something like that with Type III?

To go from III to II or I, we could have a "deliver to (local?)
type-I/II remailer" delivery method for Type III messages, to support
the unwrapping operation.  I'm not familiar enough with Types I or II to
to know how hard they would be to nest inside a type III payload.

> * pings -- should they be distinguishable from real messages? Pros, cons?
 [...]
> Mainly, the current pinging system works just fine as it is. A
> pinger sends mail to itself through a remailer or remailer chain, and
> reports the outcome. If a pinger was instead asking for a pong response
> from the server, the server would be able to skew the stats by
> prioritizing pings to a greater degree. (Yes, cheating can still occur by
> identifying which recipient addresses are pingers, etc. But why make it
> easy?)

Yes, I think this is right.  The client suite should have an integrated
ping tool, but we don't need a separate message type for it.

-- 
Nick