Subject: [Asrg] 6. Email Path Verification

From: Jonathan Morton <[email-masked]>
Date: Mon, 8 Sep 2003 18:10:23 +0100

Hi, I'm new to ASRG so feel free to point out any obvious flaws (or 
redundancy) in my post.

After reading an article on The Register, which quoted Dr. Solomon as 
suggesting that a "penny post" scheme would be the best anti-junk 
system around (but conceding that present takeup and attitudes to the 
idea were not encouraging), I got to thinking about schemes which might 
work.

Starting from the "penny post" principle, I figured out a high-level 
method of attaching a cryptographic signature to an e-mail, via a 
third-party "payment agent".  The recipient would then have the option 
of checking the signature both against the e-mail and against the 
agent.  The agent, moreover, could be looked up in a directory of 
agents, chosen by the recipient.

At this point, I realised that the agent not only need not actually 
charge for it's services, and also need not be attached to the sender's 
smarthost or ISP.  This makes deployment and acceptance much easier in 
the early stages, certainly easier than IPv6.  The agent does have to 
check whether a user is apparently trying to sign a large batch of 
mails, but this is not technically difficult.

The actual volume and pricing policy would be set by the agent, which 
would be under market pressure from both ends - allowing sufficient 
volume and low prices to please senders, while still keeping the 
quantity and quality of mail sent through it in line with recipients' 
(really the directory maintainers') expectations.  I can suggest a 
number of models which might be considered by different agents.

At this point I started looking through the RFC and I-D databases to 
see what other people were doing in this line, and eventually came 
across the ASRG's work.

The end result of my idea's evolution (over several days) looks less 
like the SHRED system presented by AT&T Labs, and more like the last 
entry in the Email Path Verification paper.  My system, however, adds 
an extra trust layer in the form of the agent directory, which would 
operate in a similar manner to the present RBLs, but generally as a 
whitelist rather than a blacklist.

The system operates entirely independently of the mail transport 
system.  Signatures are added as headers in the RFC2822 scope, so they 
survive through SMTP, POP3, IMAP and all similar protocols with no 
modifications to existing MTAs.  Signing and verification are both 
optional, and initiated by the MUA at the appropriate end.

I've also considered scalability problems introduced by large mailing 
lists, some problems associated with the limited resources on some 
e-mail clients, the usability and security problems introduced by 
storing cryptographic keys on inexperienced users' machines, and can 
suggest a solution to each of these.  I believe the idea is 
implementable using existing infrastructure and technologies, with 
minimal impact on most users' experience of e-mail.

If you'd like me to go into more detail, please ask.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

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

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 13 Sep 2003 00:38:44 +0100

> You might want to check out the camram.org project.
>
> 	http://camram.org/

(Above URL is broken, use http://www.camram.org/ instead.)

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.

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.)

IIRC, the '030 (which is a contemporary of the i386) is neither 
superscalar nor pipelined, usually has a pitifully low clock speed, and 
is therefore hopelessly slow by modern standards.  Even simple 
image-compression algorithms are hard work for such a machine.  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".

Finally, I should point out that it is possible to implement most 
crypto algorithms in hardware, resulting in a much greater hashcash 
availability to a determined organisation (such as a spammer ring) 
after some capital investment.  The EFF showed that it was possible for 
3DES with "Deep Crack", and while it cost $250K to build Deep Crack, an 
equivalent machine would be much cheaper today because of the 
availability of inexpensive FPGAs.

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.  So, let's say the incremental cost is of the order of $25 per 
FPGA, giving perhaps 25 hashcash tokens per second on average (yes, I'm 
being faintly optimistic).  Even allowing for one-off development and 
equipment-manufacture costs, spam would appear to be worth enough to 
make such a system affordable.  That puts Granny and her long-suffering 
Mac*[1] at even more of a disadvantage.

However, a system that uses hashcash as a fallback for other 
authentication methods would be an interesting concept.  For example, 
use hashcash only to initiate "stranger" communications, and use a 
strongly-authenticated whitelist otherwise.  Reading the rest of that 
site, I see that's in fact what it suggests.  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.

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.

Suddenly, they have the means to send spam to a lot of people - and 
even better (in the case of a mass-mailing attachment-based worm), 
these are mostly the clueless types who are most likely to respond 
positively to spam and scams.  Oh dear.

This second problem is the main reason why any mainstream 
authentication solution requires the authentication to be done via 
third-party, (semi-)trusted servers.  It's much harder to pick keys off 
a dedicated server than some newbie's desktop, and if they are, that 
server can be de-listed quite quickly until it fixes the problem.

*[1] - Mac IIcx, 16MHz 68030+68882, 5MB 120ns RAM, 40MB HD, 640x480, 
monochrome.  I pulled one of these out of a skip last year, and after 
drying it out I found that it still works.  It has similar capabilities 
to Macs I've heard of being distributed, free of charge, to 
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.