|
Re: [Asrg] 3. Proof-of-work analysis
2004-05-19 15:36:34
As an example, Lancaster University provides a central UNIX-shell
cluster for all students, among the services of which was the official
e-mail system. Because it's a UNIX shell system, the mail is sent
from
the members of the cluster, not from the terminal used to log on. So,
in theory, the Internet sees 10,000 students sharing three 4-way Sun
workstations (this, at least, was what the configuration used to be).
sorry, you're not counting hosts here, but MTAs. I have no global
figures on MTA populations to hand -- and I'm not sure if anyone else
has that sort of data
On the contrary, I explicitly pointed out that the three physical
machines involved were at least capable of running MUAs for up to 10000
students. The fact that the physical displays are scattered around the
campus, and possibly the city to some extent, is irrelevant. The fact
that many students use alternative e-mail systems is relevant, but a
sufficiently high proportion do still use the UNIX shell.
looking at RIPE I see that Lancaster has 144.88.0.0/16 (as well as a
/20
and some IPv6 space). You aren't allowed /16s with just 4 hosts, so
though I doubt that the 10K students are actually using 64K hosts, I
suspect that the ratio of people to hosts is somewhere near the overall
Internet average
Most of the address space is taken by the labs and staff office
computers. I purposefully left the staff (about 1000 or so) out of the
population figure for that reason. It might also be reasonable to
exclude the research students, as these often have assigned computers
as well, but they are a relatively small section of the student
population. FWIW, the bedroom LAN connections are behind a NAT system
and do not contribute to the address space.
My point is that there are a few systems that genuinely handle large
numbers of users for e-mail. Web-mail systems and UNIX shells are
probably the prime members of this group. I believe some vendors are
actively pushing "thin client" systems, which would also fall into this
category.
And yes, I agree that this particular use-case is fairly pessimal in
terms of proof-of-work scenarios. However, intra-campus
communications
are typically quite well-ordered, so (with careful management around
the beginning of the academic year) it could still be possible to use
the same three workstations in a proof-of-work world.
we disagree --- unless of course you have in mind some sort of
composite
scheme where not all email carries a proof-of-work.
...which I do. I thought I'd made that clear.
While I don't yet have a document describing exactly how it works, the
essence is that high-value hashcash can be replaced by a low-value
hashcash combined with a whitelisted signature. The signature is also
included with high-value hashcash tokens so that whitelists can be
built easily. The required hashcash value for return mail is indicated
by another header.
I don't have any strong opinion on how the whitelist should be built -
that's a matter between the recipient and their MUA. In the case of
Lancaster University, each student could be given a default whitelist
upon enrolment that included various campus-wide and departmental
mailing lists, along with relevant professors and admin staff. Study
groups, friends, relatives, and clubs could then be added in the normal
way.
Adam's point about latency times in sending any email that did need a
proof-of-work calculation is one that should cause pause for thought
-- that pause being several times longer that the calculation itself
:)
Right. Sending latency is not really a problem for end-users with
always-on connections, but it could easily be for a dial-up user, or
for an e-commerce system. Some proof-of-work schemes - including
hashcash - can precompute a token from the moment the recipient list is
known, which might overlap the time the user spends creating the
message.
Even so, it's clear that an (on average) hour-long computation is going
to be unacceptable - for one thing, it would drain up to half a typical
laptop's battery. Ten minutes is probably pushing it, too, though it's
still possibly acceptable. I consider 60 seconds to be the practical
upper limit, and *that* has to fit into the midrange machines from a
couple of years ago, which are still in common use.
60 seconds implies that you limit people to 1440 emails per day. If you
look again at the paper you will see that at this level the spammers
who
use zombies would be restricted to only about 5% of current activity
(ie
the solution would perceptually be no better than filtering) or
alternatively (if you think spammers will purchase kit to do the proof-
of-work sums "legitimately") you are forcing the price of spam up to
around 0.1 cents/email -- which is not sufficient to remove a lot of
topics from our mailboxes.
Reducing the capacity of the zombie network is bound to be worthwhile.
I would also suggest that victims are more likely to notice their
infected machine if it has high CPU usage than if it has high network
usage.
I would also suggest that 0.1c per mail would make for less frivolity
than the present 0.001c per mail. Your paper says that 0.1c/mail was
used by spammers as a price in the past. The pertinent question is:
how far in the past, and what were the spamming levels like back then?
To get the work factor high enough to have an impact, you need to be
thinking in terms of an hour or so :(
Strongly disagree. To make an impact, the worst-case I can think of
would demand about a minute of work on average, and I would hope we
could work with less.
Your idea of "make an impact", however, seems to be equivalent to our
idea of "virtually eliminate the problem single-handed". My idea of
"make an impact" starts from "prevent the problem from getting even
worse than at present" and works from there.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|