From: Hal <hfinney@shell.portal.com>
Date: Mon, 6 Feb 95 08:51:56 PST
To: cypherpunks@toad.com
Subject: Re:  Cooperation
Message-ID: <199502061651.IAA02758@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

From: Nathan Zook <nzook@bga.com>
>    I agree that it is to our advantage to minimize the cooperation between
> remailers, for the following reasons:
> [...]
> But there is a major difference between active cooperation and agreeing to
> a standard.  Active cooperation is just that--something which cannot be
> automated, or which involves automated judgement decisions.  I claim that
> my ideas are merely standards.  A standard which might even be extendable
> into the dominions of a hostile government.

I see your point.  I tend to have something of a knee-jerk reaction
against proposals which put more responsibility into the hands of the
remailer operators, but as you say the mere promulgation of a standard
does not in itself require cooperation.  We have de-facto standards
right now, which is what makes chaining possible.

And from the technical point of view, the idea of remailers encrypting
between themselves seems to do no harm and could possibly make the
attacker's job potentially more difficult by reducing the amount of
information he has available.

One problem is that one remailer may not know about all of the others.
So to the extent that your proposal requires a registry of remailers, a
centralized service which keeps track of all remailers, I still have a
problem.  This is where my vision departs from those who see the
"remailer net" as an entity, and for whom the notion that remailers would
treat messages to each other specially is a natural assumption.  If you
would suggest that at each stage the message included not only the
address of the next remailer, along with the "payload" which was already
encrypted (by the sender) for that remailer, but in addition a key for
that remailer and a request to encrypt under that key, then I would feel
much better about it.  This way there is no need for the remailer to know
anything about whom it is sending to.

Likewise if we wanted to specify in the standard that messages could be
signed, that also would not imply collusion.  However to specify that
signatures must be checked would have some implications about acquiring
the necessary public keys through some means, and I don't think that
should be done.

I do like the idea of standards.  In fact I wonder if the current "mark
1" remailer command set shouldn't be documented as an Internet RFC.  It
has been in use for a couple of years now, evolving somewhat over that
time, and some twenty or thirty remailers have operated for some part of
that time following that spec.  It would also give a certain amount of
(undeserved, perhaps) respectability to remailer operators if there were
an actual numbered RFC which they were following.  And it does seem to me
that this kind of thing is exactly what the RFC's are for.  Certainly
there are a great many "minor" RFC's which are less followed than our
remailer standards.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzZTfBnMLJtOy9MBAQFsRwIA4A5EzFZwJdEmSvcfMmnu+RCAEGYK56dg
y2LBawLdYn5FNcnvH6YkfCMHIcWURm1b6emEsw32FVH2m6ScAAH/iQ==
=F2+s
-----END PGP SIGNATURE-----