Re: Thoughts on MixMinion archives

[Len Sassaman <rabbi@quickie.net>]

On 23 Apr 2002, Nick Mathewson wrote:

> 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.

I think that backwards compatibility with Type I remailers is something to
strive to be free of. We're currently managing just fine with the remix
system, but I hate to see users using Type I. If we can just get everyone
to upgrade to Type III clients, I see no real reason to worry about
supporting the previous versions.

(A real working nym system is a huge incentive for people to upgrade to a
Type III compatible client, so I don't foresee any major pushback on
phasing out Type II as well.)

> > 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.

I'd like to get a copy of the proceedings, when they are available.

> (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.)

Yes, which is why I broke that out into a separate proposed RFC. We want
one for the message formats and protocols, so that every app can talk to
each other, and a second one for proper node/app behavior.

> > 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.

I'm not sure I follow.

> 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.

Okay, so this is a Mixminion specific architecture issue, which I don't
have to worry about.

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

Should I write up a BCP describing how the remailer network currently
operates in these regards?

> 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.

Agreed. This also brings up the sticky question of extensibility. Ideally,
we'll permit no extensions that would fragment the anonymity set. However,
if we don't specify a method for specifying additional features/
capabilities, they will happen ad-hoc.

> 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.

It shouldn't matter, should it? Treat it as an opaque clear-text message,
and process it accordingly. On the other end, if it unwraps to be a Type I
or II message for which you hold the secret key, process again. Wash,
rinse, repeat until you have something useful to do with the output.

> 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.

Great.

--Len.