Re: remailer spam throttle

Hal Finney <hal@rain.org> writes:
> For example, one idea is to have a list of people who are willing to
> receive anonymous mail without questions.  It could be that the remailer
> is set up to ask before sending mail normally, but to people on such a
> list it doesn't have to ask, it just sends it, because they have given
> permission.
>
> Some people have objected to this proposal because the existence of the
> list might give a hint about which people send mail through the remailers.
> Even though the list is of people willing to *receive* anonymous mail,
> it could well be that there is a strong correlation with people who want
> to send such mail.

Instead of keeping this list in cleartext, one could keep 1-way hashes
of the addresses. Thus a remailer (or anyone) can check whether a given
address is on the list, but they can't just go through the list and
"investigate" the addresses on it.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

Dr.Dimitri Vulis KOTM wrote:
> 
> Hal Finney <hal@rain.org> writes:
> > For example, one idea is to have a list of people who are willing to
> > receive anonymous mail without questions.  It could be that the remailer
> > is set up to ask before sending mail normally, but to people on such a
> > list it doesn't have to ask, it just sends it, because they have given
> > permission.
> >
> > Some people have objected to this proposal because the existence of the
> > list might give a hint about which people send mail through the remailers.
> > Even though the list is of people willing to *receive* anonymous mail,
> > it could well be that there is a strong correlation with people who want
> > to send such mail.
> 
> Instead of keeping this list in cleartext, one could keep 1-way hashes
> of the addresses. Thus a remailer (or anyone) can check whether a given
> address is on the list, but they can't just go through the list and
> "investigate" the addresses on it.

Well, they can compile the list of addresses off of USENET postings and
such and then compute the hashes of the compiled names and identify
those that are on the anon acceptance list. Not that it completely
invalidates the idea, but certainly it is a problem.

	- Igor.

ichudov@algebra.com (Igor Chudov @ home) writes:

> Dr.Dimitri Vulis KOTM wrote:
> > 
> > Hal Finney <hal@rain.org> writes:
> > > For example, one idea is to have a list of people who are willing to
> > > receive anonymous mail without questions.  It could be that the remailer
> > > is set up to ask before sending mail normally, but to people on such a
> > > list it doesn't have to ask, it just sends it, because they have given
> > > permission.
> > >
> > > Some people have objected to this proposal because the existence of the
> > > list might give a hint about which people send mail through the remailers
> > > Even though the list is of people willing to *receive* anonymous mail,
> > > it could well be that there is a strong correlation with people who want
> > > to send such mail.
> > 
> > Instead of keeping this list in cleartext, one could keep 1-way hashes
> > of the addresses. Thus a remailer (or anyone) can check whether a given
> > address is on the list, but they can't just go through the list and
> > "investigate" the addresses on it.
> 
> Well, they can compile the list of addresses off of USENET postings and
> such and then compute the hashes of the compiled names and identify
> those that are on the anon acceptance list. Not that it completely
> invalidates the idea, but certainly it is a problem.
> 
> 	- Igor.
> 

That's a valid point.  One can obtain a list of "suspected" addreses,
say, from the subscribers to the cp list(s), and run that against the
hashed lists.

Another feature I really don't like about asking the first-time recipients
to agree to accept e-mail while it's on the reamailer is:

With the present scheme, if a remailer is "raided", it has precious little
interesting stuff on it at any one time. Now consider the scenario:

X sends 1000 copies of child porn/seditious libel to 100 people believed not
to be using remailers right now.  The remailer keeps the 100 e-mails onits
hard disk and e-mails each receipient a ping, inviting them to agree to the
disclaimer terms and to retrieve their anonymous e-mail.  The first recipient
to retrieve the e-mail gets upset and contacts the feds.  The feds figure, the
remailer still has the 99 other e-mails and the information on who's supposed
to receive them in its queue; why not seize it and take a look.


I just came up with another idea which definitely has some holes in it,
but perhaps someone wants to improve on it.

There's a big distributed database of pgp keys on the several keyservers.
Add a bit to the database specifying whether the key owner wants to receive
anonymous e-mail.  By default set it to true for the existing addresses.

When the final remailer in the chain wants to send someone an anonymous
message, it attempts to retrieve a key from the keyservers.

If it fails to find a key, it junks the mail (you don't want to keep it
around, it's baiting the LEAs!) and instead sends a notification to the
recipient that some anon e-mail was addressed to it, but it was junked;
and if they want to receive anon e-mail, they need to give a pgp key
to one of the key servers this remailer uses.

If it finds a key, it looks at the anon mail bit; if it's on, it encrypts 
the e-mail with the recipient's key and sends it; otherwise it junks it.

Obviously, the key servers would need to be modified to allow users to
specify whether they want anon e-mail when then store their keys, and
to change this setting any time.

Right now, there's a very large number of addresses in the key servers.
Instantly making them into a list of addresses that accept anon mail
will make it hard (hopefully infeasible) for the LEAs to investigate
everyone willing to accept anon e-mail as a suspect in sending it.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

Dimitri Vulis <dlv@bwalk.dm.com> writes:
> Igor Chudov <ichudov@algebra.com> writes:
> > [uses list of hashes of email addreses to reduce value of the database
> > to the attacker]
> > 
> > Well, they can compile the list of addresses off of USENET postings and
> > such and then compute the hashes of the compiled names and identify
> > those that are on the anon acceptance list. Not that it completely
> > invalidates the idea, but certainly it is a problem.
> 
> Another feature I really don't like about asking the first-time recipients
> to agree to accept e-mail while it's on the reamailer is:
> 
> With the present scheme, if a remailer is "raided", it has precious little
> interesting stuff on it at any one time. Now consider the scenario:
> 
> X sends 1000 copies of child porn/seditious libel to 100 people
> believed not to be using remailers right now.  The remailer keeps
> the 100 e-mails onits hard disk and e-mails each receipient a ping,
> inviting them to agree to the disclaimer terms and to retrieve their
> anonymous e-mail.  The first recipient to retrieve the e-mail gets
> upset and contacts the feds.  The feds figure, the remailer still
> has the 99 other e-mails and the information on who's supposed to
> receive them in its queue; why not seize it and take a look.

Here's a partial solution to that: in the ping email informing the
recipient there is mail waiting, you include a key, encrypt the
message body that you are retaining data with the key and then discard
the key.  Give a deadline: "your message will be deleted in 5 days".
They re-supply the key when they request the message.  You immediately
decrypt and send it back to them, discarding all knowledge of them
(email, encrypted message, encryption key).

One snag is that you still have addresses for recipients on your
machine so they can go harass people and ask them for the keys to the
as yet uncollected messages.

Refinement to solution (I like this one), get rid of the intended
recipients address immediately after sending the ping, just keep the
encrypted body of the message.  Include in the ping something which
reliably selects a message (say first encrypted line, SHA1 hash of
encrypted message, whatever, to save you having to try to decrypt all
of your messages).

> [keyserver with I-accept-anon-email bit consulted by remailer, no
> key in remailer => instant trash of message and ping message
> explaining how to accept anon email]

This sounds a lot like the distributed block and accept list idea
which has been discussed a bit.

I like your treatment of the remailed material as a `hot potato',
instantly pass it on or burn it.

> Right now, there's a very large number of addresses in the key servers.
> Instantly making them into a list of addresses that accept anon mail
> will make it hard (hopefully infeasible) for the LEAs to investigate
> everyone willing to accept anon e-mail as a suspect in sending it.

The per remailer block list system kind of does this at the moment,
only the list of people initially marked down as willing to accept
anon email is the world.

Everyone can recieve email, but people get blocked when they complain.

Incidentally, it has occurred to me for a while now that the reverse
problem also exists: if I suspect you (Dimitri) use remailers, I can
forge a message from you to all the remailer operators requesting that
I (ie you) be blocked.  I can include some exceedingly dire legal
threats to the remailer operator, and dig up some vile messages from
some dark corner of usenet which I falsely claim came through that
operators remailer.  As the remailer operator doesn't keep logs he
won't be able to recognize the falsehood of the accusation.

To solve this problem you need to do a ping message, "please reply
with this nonce to be blocked".

Adam

-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Adam Back <aba@dcs.ex.ac.uk> writes:

> > X sends 1000 copies of child porn/seditious libel to 100 people
> > believed not to be using remailers right now.  The remailer keeps
> > the 100 e-mails onits hard disk and e-mails each receipient a ping,
> > inviting them to agree to the disclaimer terms and to retrieve their
> > anonymous e-mail.  The first recipient to retrieve the e-mail gets
> > upset and contacts the feds.  The feds figure, the remailer still
> > has the 99 other e-mails and the information on who's supposed to
> > receive them in its queue; why not seize it and take a look.
>
> Here's a partial solution to that: in the ping email informing the
> recipient there is mail waiting, you include a key, encrypt the
> message body that you are retaining data with the key and then discard
> the key.  Give a deadline: "your message will be deleted in 5 days".
> They re-supply the key when they request the message.  You immediately
> decrypt and send it back to them, discarding all knowledge of them
> (email, encrypted message, encryption key).

That's a good idea, but it'll take up a lot of disk space at the
machine running the remailer.  Right now, remailers that provide
latency don't keep an e-mail for more than about 12 hours. Once
you start keeping them around for a few days (a reasonable grace
period for a first-time user), it's a lot more disk space.

> One snag is that you still have addresses for recipients on your
> machine so they can go harass people and ask them for the keys to the
> as yet uncollected messages.
>
> Refinement to solution (I like this one), get rid of the intended
> recipients address immediately after sending the ping, just keep the
> encrypted body of the message.  Include in the ping something which
> reliably selects a message (say first encrypted line, SHA1 hash of
> encrypted message, whatever, to save you having to try to decrypt all
> of your messages).

That's a good refinement, but it's still not enough, IMO.
Suppose a LEA wants to search the computer hosting the remailer.
They come across a bunch of encrypted files.
The operator has to convince the LEA that they don't have the means
to decrypt the e-mails or even to figure out who they're from.
That just may be close to contempt of court. Say, you might be
asked to explain how you generate the "random" keys so they
can be recreated.

IMO, the 'net has changed from what it used to be a few years ago.
One can no longer send e-mail to an unknown recipient and hope that
they're willing to accept anonymous e-mail. I'm not 100% sure what
needs to be done, but I firmly believe that in today's climate
unless the remailer knows that the recipient took some positive
action to indicate that s/he has a clue (such as, added a key to a
keyserver), their anon mail should be immediately discarded and
they should instead get a note:

Someone tried to send you anonymous e-mail; because we don't
know whether you want to receive anon e-mail, it's been discarded
and can't be recovered; anon e-mail can be bad; disclaimer
dislciamer disclaimer; and here's what you need to do to
receive future e-mail if you want it.

> > [keyserver with I-accept-anon-email bit consulted by remailer, no
> > key in remailer => instant trash of message and ping message
> > explaining how to accept anon email]
>
> This sounds a lot like the distributed block and accept list idea
> which has been discussed a bit.

Yes - nothing really new.

> I like your treatment of the remailed material as a `hot potato',
> instantly pass it on or burn it.

Yes - 5 days worth of anon mail, even if it's encrypted and the
recipient is stripped, is an attractive target for LEA's looking
for child porn and the like.

> > Right now, there's a very large number of addresses in the key servers.
> > Instantly making them into a list of addresses that accept anon mail
> > will make it hard (hopefully infeasible) for the LEAs to investigate
> > everyone willing to accept anon e-mail as a suspect in sending it.
>
> The per remailer block list system kind of does this at the moment,
> only the list of people initially marked down as willing to accept
> anon email is the world.
>
> Everyone can recieve email, but people get blocked when they complain.

Unfortunately this model is based on assumptions that are no longer
true.  I've been on the 'net since the early 80s.  I used to
prozelityze(sp?) everyone I knew that the 'net is a great tool
and that  we all should use it. Well, now the 'net is full of
assholes and you can no longer assume that just because someone
has access to the 'net, they have a clue.

However I think it's a safe assumption that someone who put their
key in a key server has enough of a clue to be able to handle
an anon e-mail; and if they don't, they should be able to turn
it off easily.

> Incidentally, it has occurred to me for a while now that the reverse
> problem also exists: if I suspect you (Dimitri) use remailers, I can
> forge a message from you to all the remailer operators requesting that
> I (ie you) be blocked.  I can include some exceedingly dire legal
> threats to the remailer operator, and dig up some vile messages from
> some dark corner of usenet which I falsely claim came through that
> operators remailer.  As the remailer operator doesn't keep logs he
> won't be able to recognize the falsehood of the accusation.
>
> To solve this problem you need to do a ping message, "please reply
> with this nonce to be blocked".

Yes, that's a possibility. E-mail from has has been forged in the
past, as Igor can attest. :-) Again, the 'net has changed. As some
folks are aware, I run 3 mailing lists at another site. 2 are near-dead,
but one has been up since '89 and is pretty active. Recently I had
to institute the policy of confirming subscriptions because of the
several forged subscription requests.  Such things were unthinkable
even 4 or 5 years ago.

A key server presumably has some mechanisms for checking that someone
who wants to store or update a key for a@b appears to be a@b.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

At 06:46 PM 3/28/97 EST, Dimitri wrote:
>That's a good idea, but it'll take up a lot of disk space at the
>machine running the remailer.  Right now, remailers that provide
>latency don't keep an e-mail for more than about 12 hours. Once
>you start keeping them around for a few days (a reasonable grace
>period for a first-time user), it's a lot more disk space.

Typical remailers carry maybe 100-500 messages/day;
typical messages run 1-20KB unless they're pictures or warez.
	(Yes, I'm making these numbers up....)
That's about 1-10MB/day of traffic.  If you keep it 7 days,
that's up to 70 MB storage, which you'd probably keep in /tmp
to avoid backups and maybe avoid disk quotas.
If you're running it on your own desktop machine, that's small;
it's a bit large for a laptop, and whether it's reasonable for an
ISP shell account depends a lot on your ISP's policies and disk quotas
(and /tmp clearing policies.)

>Suppose a LEA wants to search the computer hosting the remailer.
>They come across a bunch of encrypted files.
>The operator has to convince the LEA that they don't have the means
>to decrypt the e-mails or even to figure out who they're from.
>That just may be close to contempt of court. 

But you don't have to explain it to the LEA - you may have to
explain it to a court, but you get to bring along a lawyer.
It's not contempt if you're telling the truth (that you can't decrypt it.)

On the other hand, if you're using a two-part key (one sent to the
recipient, one kept in transient memory on your machine plus in your head),
you _do_ get to explain to the judge why you're refusing to testify,
and why the ECPA protects the privacy of all the messages that
may be revealed if you release your half of the key,
and why you need sworn testimony from the LEAs about exactly which
messages they've eavesdropped besides the ones addressed to their target,
and about why giving them the key would violate the privacy of
the recipients of those other messages so they can't have it,
but you also refuse to decrypt the ones for the victim yourself,
at least without a direct court order (as opposed to a mere warrant) -
_then_ you'll have the opportunity to get close to contempt of court :-)

>Say, you might be asked to 
>explain how you generate the "random" keys so they can be recreated.

If the "random" key includes a part you know as well as a part
the user knows, and the user's part not only includes a hash of
the message (so you need to know the contents of the message to
recreate the session key) but also the usual things like the
system clock to the microsecond and the contents of the rand pool,
and maybe a few hits from /dev/random - then it's perfectly fine
to tell them.

>IMO, the 'net has changed from what it used to be a few years ago.
>One can no longer send e-mail to an unknown recipient and hope that
>they're willing to accept anonymous e-mail. 
I'd agree, but from the first anonymous remailers open to the public
there were people who didn't like receiving anonymous mail :-)

>unless the remailer knows that the recipient took some positive
>action to indicate that s/he has a clue (such as, added a key to a
>keyserver), their anon mail should be immediately discarded and
>they should instead get a note:

That's an interesting approach - a bit extreme, but the main cypherpunks
applications for anonymous remailers are things like whistleblowing
(which can be posted to the net or emailed to people like Foo Inspectors
who _ought_ to be willing to accept anonymous mail) and potential
co-conspirators (who _ought_ to be willing to accept it if they're
interested in co-conspiring), and of course yourself under various aliases.

>> > Right now, there's a very large number of addresses in the key servers.
>> > Instantly making them into a list of addresses that accept anon mail
>> > will make it hard (hopefully infeasible) for the LEAs to investigate
>> > everyone willing to accept anon e-mail as a suspect in sending it.

A nice touch.

>> To solve this problem you need to do a ping message, "please reply
>> with this nonce to be blocked".
Yep.


#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#     (If this is a mailing list, please Cc: me on replies.  Thanks.)

Bill Stewart <stewarts@ix.netcom.com> writes:

> At 06:46 PM 3/28/97 EST, Dimitri wrote:
> >That's a good idea, but it'll take up a lot of disk space at the
> >machine running the remailer.  Right now, remailers that provide
> >latency don't keep an e-mail for more than about 12 hours. Once
> >you start keeping them around for a few days (a reasonable grace
> >period for a first-time user), it's a lot more disk space.
>
> Typical remailers carry maybe 100-500 messages/day;
> typical messages run 1-20KB unless they're pictures or warez.
> 	(Yes, I'm making these numbers up....)

Let them send pictures and warez. A remailer operator shoudn't care. :-)

> >IMO, the 'net has changed from what it used to be a few years ago.
> >One can no longer send e-mail to an unknown recipient and hope that
> >they're willing to accept anonymous e-mail.
> I'd agree, but from the first anonymous remailers open to the public
> there were people who didn't like receiving anonymous mail :-)

Well... Let me quote the complaint that Jim Ray (himself a one-time
remailer operator) sent to postmaster@dm.com because he didn't like
the anonymous messages that he thought might be coming from me:

]Received: from miafl2-16.gate.net (miafl2-16.gate.net [199.227.2.143]) by osceola.gate.net (8.7.6/8.6.12) with SMTP id HAA187758; Wed, 16 Oct 1996 07:13:05 -0400
]Date: Wed, 16 Oct 1996 07:13:05 -0400
]Message-Id: <199610161113.HAA187758@osceola.gate.net>
]From: Jim Ray <liberty@gate.net>
]To: root@bwalk.dm.com, postmaster@bwalk.dm.com
]X-Priority: Normal
]Subject: Dr.Dimitri Vulis KOTM
]X-Mailer: Pronto Secure [Ver 1.10]
]X-Prontosecureinfo:  T=signed, P=x-pgp
]
]-----BEGIN PGP SIGNED MESSAGE-----
]
]Mime-Version: 1.0
]Content-Type: text/plain
]Content-Transfer-Encoding: 7bit
]
]To: root@bwalk.dm.com, postmaster@bwalk.dm.com
]Date: Wed Oct 16 07:10:45 1996
]Can you folks somehow get Dr.Dimitri Vulis KOTM <dlv@bwalk.dm.com> to quit
]sending anonymous messages to cypherpunks? I have killfiled him, but he
]sends things with subject headers like "RSA" through the anonymous remailers
]and it is impossible to killfile them and still get interesting anonymous
]messages.
]
]He is evidently angry at another subscriber, Tim May, for showing the list
]how much of a fool he was regarding economics in the past, but now he shows
]how much of a fool he is. Below is an example, the subject was RSA, and it
]could only have come from him, I assure you. [BTW, this is not a threat of
]legal action on my part against you, it's just that you are lowering your
]reputations by letting him continue spewing garbage, and now that even
]killfiling him hasn't worked, I am trying to convince you to talk to him and
]encourage him to please take his lithium regularly.]
]JMR
]
]- -----Begin Included Message -----
]
]Date: Tue, 15 Oct 1996 15:35:04 -0400 (EDT)
] From: amnesia@chardos.connix.com (Anonymous)
]To: cypherpunks@toad.com
]Cc:
]
]Timmy C. Mayflower was born when his mother was on the
]toilet.
]
]
]
]- ---- End of forwarded message ----
]One of the "legitimate concerns of law enforcement" seems to be
]that I was born innocent until proven guilty and not the other
]way around. -- me
]
]Defeat the Duopoly! Vote Harry & Jo http://www.HarryBrowne96.org/
]___________________________________________________________________
]PGP id.E9BD6D35 51 5D A2 C3 92 2C 56 BE  53 2D 9C A1 B3 50 C9 C8
]I will generate a new (and bigger) PGP key-pair on election night.
]<mailto:jmr@shopmiami.com> http://www.shopmiami.com/prs/jimray
]___________________________________________________________________
]
]-----BEGIN PGP SIGNATURE-----
]Version: 2.6.2
]
]iQCVAwUBMmTCum1lp8bpvW01AQHAugP/e/GTay0y778Ziy3JbWCGBb+tRxM8Q1Zi
]Z3aIP97hNYYoD7QKi9yP1gS3ZRbg/9ZXJonWTi+zmZ7yUjmWndczmXJ2IAC+Rgpx
]7MQmrhjU4htmiMCuawNmVLZRNZMl/+kNnX15taA8GdXTcuPXUsGN0y39oMbbqT5g
]do3B4yicgrY=
]=iix/
]-----END PGP SIGNATURE-----


Say, didn't this Mmmmm... Black Unicorn shmuck threaten to sue me
for saying someone's on lithium?? :-)

> >unless the remailer knows that the recipient took some positive
> >action to indicate that s/he has a clue (such as, added a key to a
> >keyserver), their anon mail should be immediately discarded and
> >they should instead get a note:
>
> That's an interesting approach - a bit extreme, but the main cypherpunks
> applications for anonymous remailers are things like whistleblowing
> (which can be posted to the net or emailed to people like Foo Inspectors
> who _ought_ to be willing to accept anonymous mail) and potential
> co-conspirators (who _ought_ to be willing to accept it if they're
> interested in co-conspiring), and of course yourself under various aliases.

If the maintenance of destination blocking/unblocking is divorced from
the remailer operators, then the whistleblower might be able to find
out whether the recipient accepts anon e-mail. Under the scheme I sort
of proposed, if I wanted to e-mail X, I might look up via the key servers
whether X accepts anon e-mail. If he doesn't, I ping him, knowing that
my ping will be discarded and instead he'll get a form letter telling
him how to enable receipt. I can check (say) the key servers a few days
later and see if he's ready to recieve anon e-mail; then I send the
real message.

Another advantage: there's no need to put the remailer's real address
in the form line.  Right now most operators say something like
"e-mail foo@bar and/or remailer-operators to be dest-blocked".
Under the scheme I'm not quite proposing yet, you can put any
junk in the from: (it's irrelevant!) and put the instructions
for dest-blocking via a 3rd party in a comment header.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

On Fri, 28 Mar 1997, Dr.Dimitri Vulis KOTM wrote:

-> I just came up with another idea which definitely has some holes in it,
-> but perhaps someone wants to improve on it.
-> 
-> There's a big distributed database of pgp keys on the several keyservers.
-> Add a bit to the database specifying whether the key owner wants to receive
-> anonymous e-mail.  By default set it to true for the existing addresses.
-> 
-> When the final remailer in the chain wants to send someone an anonymous
-> message, it attempts to retrieve a key from the keyservers.
-> 
-> If it fails to find a key, it junks the mail (you don't want to keep it
-> around, it's baiting the LEAs!) and instead sends a notification to the
-> recipient that some anon e-mail was addressed to it, but it was junked;
-> and if they want to receive anon e-mail, they need to give a pgp key
-> to one of the key servers this remailer uses.
-> 
-> If it finds a key, it looks at the anon mail bit; if it's on, it encrypts 
-> the e-mail with the recipient's key and sends it; otherwise it junks it.
-> 
-> Obviously, the key servers would need to be modified to allow users to
-> specify whether they want anon e-mail when then store their keys, and
-> to change this setting any time.
-> 
-> Right now, there's a very large number of addresses in the key servers.
-> Instantly making them into a list of addresses that accept anon mail
-> will make it hard (hopefully infeasible) for the LEAs to investigate
-> everyone willing to accept anon e-mail as a suspect in sending it.

Unfortunately, key servers can not be trusted.  I'm sure you're aware that
anyone can submit a key, and thus forgeries abound.

If the above model is adopted, key servers will be the first target of
the prospective spammer.


 ............................................................................
 . Sergey Goldgaber <sergey@el.net>      System Administrator        el Net .
 ............................................................................
 .   To him who does not know the world is on fire, I have nothing to say   .
 .                                                      - Bertholt Brecht   .
 ............................................................................

Sergey Goldgaber <sergey@el.net> writes:
> -> Right now, there's a very large number of addresses in the key servers.
> -> Instantly making them into a list of addresses that accept anon mail
> -> will make it hard (hopefully infeasible) for the LEAs to investigate
> -> everyone willing to accept anon e-mail as a suspect in sending it.
>
> Unfortunately, key servers can not be trusted.  I'm sure you're aware that
> anyone can submit a key, and thus forgeries abound.
>
> If the above model is adopted, key servers will be the first target of
> the prospective spammer.

Why Sergey, you mean to tell me that there are key servers out there that
accept a key from a purported address and don't send back a cookie to that
address to see if it's not fake? :-) That's just terrible. Definitely no
key coming from such a server should be trusted. :-) :-)

Today is March 29, 1997 - almost April 1st. The Internet ain't what is
used to was 15 or 10 or even 2 years ago. If you get an e-mail that
purports to be from X, and it requests that you add X's public key
to your key server, or (un)subscribe X to a mailing list, or
block X from receiving anonymous e-mail - it may be a forgery.
Never act on such requests without trying to authenticate them
with a cookie.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

On Sat, 29 Mar 1997, Dr.Dimitri Vulis KOTM wrote:

-> Sergey Goldgaber <sergey@el.net> writes:
-> >
-> > Unfortunately, key servers can not be trusted.  I'm sure you're aware that
-> > anyone can submit a key, and thus forgeries abound.
-> >
-> > If the above model is adopted, key servers will be the first target of
-> > the prospective spammer.
-> 
-> Why Sergey, you mean to tell me that there are key servers out there that
-> accept a key from a purported address and don't send back a cookie to that
-> address to see if it's not fake? :-) That's just terrible. Definitely no
-> key coming from such a server should be trusted. :-) :-)
-> 
-> Today is March 29, 1997 - almost April 1st. The Internet ain't what is
-> used to was 15 or 10 or even 2 years ago. If you get an e-mail that
-> purports to be from X, and it requests that you add X's public key
-> to your key server, or (un)subscribe X to a mailing list, or
-> block X from receiving anonymous e-mail - it may be a forgery.
-> Never act on such requests without trying to authenticate them
-> with a cookie.

DNS maps can easily be forged.  Key servers run on machines with questionable 
physical and operating system security.  Finally, key server ops themselves
can mess with keys.

This is why people who use keys off of keyservers are encouraged to verify
the key via it's key fingerprint, or at via the web of trust.

However, this can not be done via automation on a large scale for the purpose
of address blocking, unless via a certification authority.

The bottom line is that keyservers can not be trusted, despite any primitive
security measures they supposedly have in place.


 ............................................................................
 . Sergey Goldgaber <sergey@el.net>      System Administrator        el Net .
 ............................................................................
 .   To him who does not know the world is on fire, I have nothing to say   .
 .                                                      - Bertholt Brecht   .
 ............................................................................