Re: [Asrg] 6. Email Path Verification

> > I like the idea of hashcash as an increase-spammer-costs strategy, 
> > but there's one big fly in the ointment.  The computational 
> > requirements effectively make a hashcash-based system impractical for 
> > small, ultra-portable or autonomous devices.
> this problem has been fully acknowledged and dealt with.  
> Ultraportable or
> autonomous devices are highly unlikely to be end SMTP nodes on the net
> delivering e-mail to other end nodes.
I suppose that's true, but they are still effectively MUAs in the 
e-mail system.
> After all, how many e-mails will people send using crippled keypad 
> devices (AKA
> telephones)  :-)
SMS "texting" is wildly popular here in Europe, despite the 
inadequacies of the phone keypad.  Someone I knew a couple of years 
ago, was already complaining loudly about the inadequate "free minutes 
/ texts" allowance on his mobile tariff - both of these allowances were 
well into the hundreds per month.  It's only a tiny user-interface step 
away from full e-mail, and I believe certain "super phones" do in fact 
have e-mail and limited Web capabilities.
To say nothing of PDAs, which actually have less powerful CPUs because 
they don't have to do DSP (voice compression).  I don't know how many 
Newtons there are still in circulation, but those were certainly 
capable of Internet stuff.
> > A modern PC might only take a few seconds to generate a 20-bit 
> > hashcash, but
> > an ARM-based PDA or mobile phone might take a lot longer (burning 
> > battery
> > power all the while), and a toaster would take forever.  Not to 
> > forget the
> > old Macs (usually 68030 based) that are commonly resurrected to help 
> > elderly,
> > disadvantaged or disabled people establish lines of contact.  (Yes, I 
> > know
> > someone who actually does this.  Old Macs are amazingly durable.)
> there are two solutions.  first: defer processing to upstream machine 
> (back of
> the envelope numbers look plausible.  Need to do some empirical tests 
> on real
> mail servers).  The second solution is to look at a memory based POW 
> which
> exercises the memory bus instead of just the cache and CPU which 
> reduces the
> effect of Moore's Law inflation at a potential cost of stalling the 
> entire
> machine as you flush the cache hard.
Memory speeds haven't scaled so well with Moore's Law, that's true - 
but memory sizes have.  A memory POW that properly exercises a 
large-cache Opteron (or, worse, POWER or Itanic) is going to overflow 
the memory of these tiny old Macs, which probably don't even have 
virtual memory to contain it.  And don't tell me spammers can't afford 
even one Itanic or POWER, expensive though they might be.
So, offloading it to an upstream machine, or dedicated hardware, looks 
more plausible.  I suppose it's not entirely infeasible to make an ADB 
version of the accelerator to complement the USB one.  I think I even 
found a chip vendor who could supply a single interface chip which had 
USB, ADB, PS/2 and serial support, limited only by the physical cable 
you chose to stick on it.
> > How long is it acceptable for a hashcash algorithm to take on such a 
> > low-end
> > box?  That's the limiting factor when deciding how much each mail will
> > "cost".
> not surprisingly, I disagree.  The limiting factor is how long you are 
> willing
> to keep the machine on for.  Properly done stamp generation happens in
> background away from user visibility.
Still, Granny is used to hitting "Send" and having the modem dial out 
immediately, then cutting off again a minute or so later and shutting 
down the machine.  Changing that habit, especially to one where the 
modem dials out (mails * 50 minutes) later, is going to be painful.  
Better hope she has access to one of these accelerators.
And yes, I understand the point about it only happening for strangers, 
but we can't really lump people's mail habits into one box based on 
what class of computer they use.  For all we know, Granny could be the 
hub of an outreach program, talking to similarly-disadvantaged 
strangers every day.
> > A 20-kilogate FPGA development kit costs $300, individual 20Kgate 
> > FPGAs cost
> > in the $tens, and a set of custom PCBs can be had for $hundreds at 
> > worst. [...]
> > That puts Granny and her long-suffering Mac*[1] at even more of a
> > disadvantage.
> that's why we need to develop a repertoire of proof of work stamps, 
> postage due
> notices which handle rejection classes (insufficient postage, wrong 
> postage,
> etc.), and widespread availability of accelerators built actually into
> motherboards and available at CompUSA on plug-in cards for $25.  You 
> see, if a
> spammer can develop such a device, Taiwan Inc. can develop a faster 
> device that
> cost less and get it distributed further which means postage costs 
> takes a huge
> jump upward (further encouraging sales of accelerator's) and the arms 
> race needs
> to go in a different direction.
>
> seriously, I do believe that the additional stamp definitions and 
> proper postage due notice system can handle most of the attacks caused 
> by spammer specific hardware acceleration.
This is a fair point.  But I don't think we really want an arms race...

> being a strong advocate of recycled machines for things like firewalls 
> (IPCop,
> another one of my crimes against humanity), I have learned that 
> sometimes certain classes of old machines just aren't worth the effort 
> anymore.  You need to learn when to go for higher quality junk instead 
> of wasting your time swearing and bleeding over a cantankerous 486.
You might have noticed I was talking about "old Macs", not "old PCs".  
:-)
Because old Macs are mostly very similar, and are durable enough to 
have few to no physical problems after 10 years' service in (say) a 
school, you can get them on the net using an involved, but still 
routine procedure.
Mostly, this involves installing and configuring system, driver and 
application software (all of which are free to use), and plugging in a 
modem (doesn't need to be fast, can be really cheap, from ebay).  A RAM 
upgrade may also be needed, but that's not difficult.
This makes them highly suitable for recycling in this manner.  You 
could easily go through 20 LC-IIIs (a popular model in schools, similar 
to but smaller than the IIcx) in a week once you knew what to do, and 
that means 20 people who now have outside-world contact they didn't 
have before.
> > It still doesn't help Granny if it takes her (say) 4 hours to make 
> > hashcash,
> > even if she only needs to do that once in a blue moon.
> I think you exaggerate.
I was out by one or two orders of magnitude - in a follow-up post I 
calculated that a one-second task on an Athlon would be a 50-minute 
task on the IIcx.  I think my point survives this inconsistency.
> I will say however that that is spoken with the bias of someone who 
> leaves machines on 24 by 7 by 365 modulo power failures.
As do I, but I know my mother doesn't.  In fact, my mother makes a 
really good example of an utterly clueless luser (she has trouble using 
a Mac after years of experience), so expect to see her pop up 
gratuitously in future discussions.  ;-)
Fortunately, I don't think she's fundamentally realised that opening 
attachments is even possible.  Even more fortunately, her Windoze 
machine helpfully screwed up it's modem drivers last year, and I never 
bothered fixing it - just told her to use the Mac instead.  Thank 
goodness for small mercies.
I'll use my dad as a representative example of a none-too-clueful but 
intelligent and half-competent user - he's been using e-mail, in one 
form or another, ever since his university got it.
> > However, there's another problem with CAMRAM, though it's less 
> > obvious. Users
> > will build up a list of public keys over time, presumably stored on 
> > their own
> > machine.  Their private keys will also presumably be stored locally.  
> > It's
> > reasonably trivial for a worm to pick up a selection of these keys as 
> > it
> > propagates, and deliver them to the black-hats by any of a variety of 
> > means.
> problem understood and quite frankly, there is no camram specific 
> solution to
> this.  Any time someone can get their code to run on your machine 
> outside of the
> sandbox, you are well and truly fucked.  As we place more and more 
> important
> piece of data on known vulnerable machines, they become increasingly 
> attractive
> to attackers hoping to profit from this data or system resources.
Indeed.  But that's why my authentication scheme placed responsibility 
for throttling on the MAA, which has enough of a business relationship 
with the user to warn him if something's not right, but enough 
flexibility to cater for different users' needs.  Centralising 
responsibility at the MAA also allows for better security than the user 
can (on average) provide himself, though I'm willing to accept that it 
still won't be perfect.
How is the MAA's responsibility managed?  By the trust directory - if 
the MAA is compromised or doesn't do it's job, it will be delisted.  
How is the trust directory's responsibility managed?  By recipients who 
can switch if they're not happy.  I think there's as much 
checks-and-balances in that scheme as is reasonable.
> One solution would be to use a stored value key (i.e. USB flash+) to 
> hold
> private keys and other kinds of important data.  Accessing the data 
> requires
> specific acknowledgment and you take the key with you when you leave 
> the
> machine.  Such a device could also hold accelerator for proof of work 
> puzzles.
> Two problem solved at once..maybe...
>
> However, you cannot overcome laziness and any attempt to do so will be 
> met with
> resentment and firm resistance.  People will demand features that will 
> enable them to get screwed because it is convenient to or increases 
> the effectiveness of how they work.  Short of a major eugenics 
> program, that part of human nature isn't going to change.
Which is why I think holding the actual authentication keys on a user's 
machine, in any form (even a physical token) is a Bad Idea.  Even if 
you make a device that has a "confirm" button on the front of it, 
someone else will eventually come along and make one that doesn't have 
a button, it'll be cheaper so everyone will buy it (especially OEMs 
that influence what most consumers get in the first place), and we're 
back to square one.
At most, we want to store the user's dial-up and MAA passwords in his 
own machine.  Once again, it's the MAA's responsibility to prevent 
abuse of their service, since they're in a position to do so.  That 
means stealing a user's password using a worm isn't such a big threat 
as stealing his private key would be.
Stealing his CPU time for hashcash would be a more serious problem.  A 
typical luser's machine isn't terribly fast, but having lots of them at 
the spammer's command (a future Sobig variant?) means they can be quite 
powerful in combination.  To guard against this, if we use hashcash, it 
*must* be in combination with authentication, not as a standby 
replacement for it.
> > disadvantaged folks in the American desert.  So, if someone wants to 
> > know
> > exactly how long a given algorithm will take on that machine, there's 
> > at
> > least half a chance I'll run it and let them know.
> Please run the C hashcash code found at hashcash.org.  I would 
> appreciate seeing
> the performance numbers.  I would also like to see them for any non 
> Intel
> machines as well like Sparc and Alpha.
I'll see what I can pull together.

I might have access to a Sparc machine of some description, though I'm 
less sure of it's spec (it's the all-access university UNIX system).  
Aside from that, I have the handful of x86, 68K and PPC boxen I 
mentioned earlier.  No Alphas, I'm afraid.
--------------------------------------------------------------
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