Re: [Asrg] 3. Proof-of-work analysis

[Jonathan Morton <[e-mail]>]

>> 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:     [e-mail]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg