RemailerNet

In message <199408042200.SAA07928@cs.oberlin.edu> Jonathan Rochkind writes:
> >     *   Rochkind's stability-from-being-paid and web-of-trust notions
>  
> I'm not sure I like being credited with the "stability from being paid"
> notion. I think there _is_ stability from being paid, but I think
> if the infrastructure depends on it, it's not a good infrastructure.

If you look at the history of the Internet, there have been some free
Internet services, but the ones that have thrived have been paid.
(If the government or your school subsidizes your Internet access,
it may appear free to you, but the staff all get their paychecks every
month.

> The system should be able to create a stable top-level infrastructure
> on top of an inherently instable environment, with remailers
> going up and down, and popping into existence, and dying. It should
> route around dead remailers, like the internet itself.

If it is built like the Internet, it will do just that.

> > The use of alt.x groups to exchange gateway information does not seem
> > to add anything to this system; in fact it would seem to make it easier
> > to spoof the system.
> 
> It _would_ make it easier to spoof the system, but I think it does add
> several very important things:
> 1) New remailers can easily announce themselves to the remailernet.
> [Whether they are to be trusted or not should depend on pgp-signed keys
> and web of trust, but the newsgroup provides an way to announce yourself
> to the system, and have that announcment by automatically dealt with
> by all participating parties]

There are two things being blurred together here which should be kept
distinct.  The first is gateway-to-gateway announcements.  The second
is advertising of the RemailerNet gateways to the wider world.

Generally I would expect gateways to introduce themselves to one
another privately and negotiate an understanding.  Part of this will
normally take place off the Net.  This is an infrequent event, and
so can be time-consuming and expensive.  The basic web of trust is
that between gateways.	Once gateways had entered into a relationship,
there would be frequent encrypted private traffic between them
which would maintain the trust.

Gateways can also announce their presence to the wider world, and
publish their public keys.  This could be done in alt.RemailerNet or
it could be done in alt.internet.services, or any of several other
places, or all of these.  Any information published in alt.RemailerNet
would be suspect, because it could be a complete fabrication or it
could be a modified version of the correct posting.

Gateways could be started up by anyone and some postings to
alt.RemailerNet would be spurious.  The "gateway" could be a sink,
just tossing traffic sent to it, or it could copy all messages to a
TLA before forwarding them.  The user-gateway web of trust would
therefore be far more problematical. I think that this would function
as a market, and unreliable and untrustworthy gateways would be driven
out over time.

At the same time, there would be a constant bubbling up of new
remailer networks, because the software would be freely available
and the protocols well defined.  The longer lasting gateways that
proved trustworthy would in time join established networks.

> 2) Users (not people operating remailers, people using them) could make
> use of the newsgroup, to compile a database of remailers, and make long
> remailer chains. Users could have automated software doing this.

Compiling a list of remailers, sure.  But if you let the user control
how messages are chained, you are inviting real traffic analysis.  The
user should only be able to specify his destination and the level of
security desired.

> [snip]
> These are really two facets of the one problem, of allowing a user
> or remailer who has just arrived on the seen to quickly get a list
> of remailers, and make use of them, all automatically. That's sort of the
> super-set problem which encompasses the other two, and whose solution solves
> the other two.
>  
> I don't think it's a coincidence that the newsgroup system solves these
> two problems at the expense of security (the newsgroup makes it easier
> to spoof).

If the newsgroup is used as described above, RemailerNet itself is not
threatened; it is only the users that can be spoofed.  This level of risk
is unavoidable.  But gateways would never use the newsgroup for
inter-gateway communications, because (a) it would be redundant (they can
talk directly once they know each other and (b) you would have to assume
that anything posted to a newsgroup had been compromised.

> The fact is, that even remailers exchanging mail _can_ be spoofed, if not
> quite as easily as the newsgroup idea. It seems to be a premise of cryptographic
> protocols and schemes, that you've got to assume a worst case and get a system
> working where even under the worst case, everything works.

Well ... if you follow this line of reasoning too far, you are just
saying 'nothing can be trusted, so don't bother being careful'.  If I
were running a remailer and someone posted his address in a public
newsgroup and said "hey, here I am, and I run a really good remailer"
I wouldn't trust him just because he signed it.  I would get in touch
with him, ask around about him, maybe run some low-security traffic
through his remailer for a while.  Then after some time I would raise
my estimate of his trustworthyness.  If he dropped traffic, if someone
reported that something that they had sent privately had been
compromised, I would drop him.

> I agree that it seems a good idea for the SMTP RFCs to be used to exchnage
> info, ... etc

You already use the SMTP RFCs to exchange information -- this message
comes to you courtesy of those RFCs.  Email can have very complex headers
and they can be in pretty much any order. This makes it difficult to write
email software.  I am simply suggesting that we allow only the minimal
few headers, with possibly a few added to support RemailerNet protocols.

ASSIGNMENT OF ANONYMOUS IDs

These types of traffic are possible, where 'known' means your ordinary
email address:
	    known   --> known
	    known   --> anon
	    anon    --> known
	    anon    --> anon

There should be two anonymous IDs, one for sending, one for
receiving.

I assume that anonymous IDs are never assigned automatically.  If you
want an anonymous ID pair, you ask the gateway for one, possibly
enclosing your public key encrypted with the gateway's public key.
The gateway returns your new IDs, encrypted if you you gave it a key.

The 'send' anonymous ID is used for sending messages from someone
else's account.   The gateway converts it into a 'receive' ID before
forwarding your message.

The 'receive' ID appears on your email after it goes through the gateway
and can also be passed to other parties who want to send you remailed
messages.

Additional security can be added by using a digital signature.	The
gateway could be instructed ignore messages lacking such a signature
or to take some specified action.

ELECTRONIC CASH

Ecash is easily added to such a system.  'Emints' would generate a
message containing a bank identifier and an encrypted value.  This
would be the ecash.  It could be given to anyone or anything.
Messages containing ecash would be encrypted.  The emint would
credit the account of the first person to present it, and would
bounce any copies presented subsequently.  Giving change would be
trivial.

--
Jim Dixon

I think Jim Dixon has some interesting ideas in the RemailerNet.  But I have
a philosophical difference.  I dislike solutions where the users have
to put too much trust in the remailer operators.  IMO, as much control
as possible should be left in the hands of the users.  To make the system
easier to use, mail agents should be enhanced to be more powerful, rather
than moving more power and control into the remailer network.  Trusting
a remailer to choose your path through the network is like trusting the
sysop at your BBS to create your PGP key for you.  Maybe it's OK a lot
of the time, but isn't it better to do it yourself?

Jim Dixon <jdd@aiki.demon.co.uk> writes:

>Generally I would expect gateways to introduce themselves to one
>another privately and negotiate an understanding.  Part of this will
>normally take place off the Net.  This is an infrequent event, and
>so can be time-consuming and expensive.  The basic web of trust is
>that between gateways.	Once gateways had entered into a relationship,
>there would be frequent encrypted private traffic between them
>which would maintain the trust.

This is just the opposite of what I would like to see.  I don't want the
remailer operators getting too friendly.  That makes it all the easier for
them to conspire to track messages through the net.  I'd much rather choose
far-flung remailers whose operators have never heard of each other.  Get
one from Helsinki and the next from Timbuktu.  Choose a path which will
minimize the chances of all the remailers being corrupted.

>Gateways could be started up by anyone and some postings to
>alt.RemailerNet would be spurious.  The "gateway" could be a sink,
>just tossing traffic sent to it, or it could copy all messages to a
>TLA before forwarding them.  The user-gateway web of trust would
>therefore be far more problematical. I think that this would function
>as a market, and unreliable and untrustworthy gateways would be driven
>out over time.

I think this is right, although as I posted elsewhere I don't think usenet
is the best structure for announcing remailer availability.  (As I said,
I'd rather see a few sites volunteer to do pings and publish the results,
or even better would be widely used software packages which let people
do their own pings.)  But the question of remailer reliability is hard.
What is the giveaway if a remailer is secretly archiving messages while
claiming not to do so?  How could you ever tell if the NSA infiltrated
your favorite remailer?

One possibility would be occasional physical audits, in which a remailer
reviewer visited the site, looked at the software, checked the system for
security holes, etc.  This would be quite expensive, obviously, but perhaps
eventually the remailer infrastructure would be extensive enough that this
kind of checking could be done.  Think of it as "Consumer Reports" for
remailers.  (Similar privacy audits might be de rigeur in the future for
other net resources, such as file banks or compute servers.)

>Compiling a list of remailers, sure.  But if you let the user control
>how messages are chained, you are inviting real traffic analysis.  The
>user should only be able to specify his destination and the level of
>security desired.

What?  Again I would reverse this.  The user should have maximum control
of his path.  It's up to him to choose a random one.  Random number gen-
erators are widely available.  (I can get you a bargain on a used Blum-
Blum-Shub.)  If he has to trust the first remailer on his path, then if
just this one remailer is subverted, he's lost all his privacy.  By choosing
his own path no one remailer knows both the source and the destination of
any message.  That is the key.  No one must have those two pieces of
information.  Giving it all away to the first remailer means giving away
all your security.

>> The fact is, that even remailers exchanging mail _can_ be spoofed, if not
>> quite as easily as the newsgroup idea. It seems to be a premise of cryptographic
>> protocols and schemes, that you've got to assume a worst case and get a system
>> working where even under the worst case, everything works.

>Well ... if you follow this line of reasoning too far, you are just
>saying 'nothing can be trusted, so don't bother being careful'.

The point, though, is that with Chaum's scheme you have security if even
one remailer in the network is honest.  The chain becomes as strong as its
strongest link.  Systems which put more responsibility and power into the
remailer network often can't achieve this.  They have single-point failures
where one compromised system can defeat the efforts of all the others.

>If I
>were running a remailer and someone posted his address in a public
>newsgroup and said "hey, here I am, and I run a really good remailer"
>I wouldn't trust him just because he signed it.  I would get in touch
>with him, ask around about him, maybe run some low-security traffic
>through his remailer for a while.  Then after some time I would raise
>my estimate of his trustworthyness.  If he dropped traffic, if someone
>reported that something that they had sent privately had been
>compromised, I would drop him.

Yes, I think this is a reasonable and cautious attitude, but instead of
saying "If I were running a remailer..." I'd say it should apply "if I
were _using_ a remailer".  There may be rating services and other sources
of information to help users, but ultimately the decision should be theirs.
One of the lessons of cryptography, IMO, is that you don't get security
by farming out the hard work to others.  The user should take responsibility
for his own security.

I'm getting too tired to reply to the rest.  I think Jim has a lot of
creative ideas and energy but I'd like to see it directed more towards
empowering end users rather than putting so much reliance on trustworthy
remailer operators.

Hal