Subject: Re: [Asrg] 6. Email Path Verification

From: Scott Nelson <[email-masked]>
Date: Mon, 15 Sep 2003 00:53:50 -0700

At 12:38 AM 9/13/03 +0100, Jonathan Morton wrote:
>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.
>

No problem - compute power is cheap.  
I can, today, buy an 800 Megahertz PC for $200.
Assuming I buy a new one every year, that's still over 1200 seconds of
compute time for a penny.  Adding two minutes of compute time
to a delivery means adding one 1/10 of a cent to the cost.
A 20 bit hashcash stamp would take less than 5 seconds, about 0.005 cents.
I'd be happy to generate 20 bit hashcash stamps for your low power
device for 1/10 of a cent,
provided you bought them in batches of at least 5000.

And therein lies the real problem - 
Spammers won't have any trouble generating 20 bit hashcash stamps.
adding 1/200 of a cent to the cost of a spam isn't going to be much
of a deterrent, and that assumes that spammers are using 
off the self hardware, and actually paying for the equipment.
They could build custom hardware to generate stamps for less, 
but given that most spam is being sent via trojaned machines,
I think they'd just use the boxes they already "own3d" to send spam
to generate the stamps.  Clearly 100,000 trojaned machines can 
send 100,000 pieces of spam in the same time it takes a normal 
user to send 1.  Open proxies / trojaned boxes used to send spam
is currently estimated in the millions.

Scott Nelson <[email-masked]>

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

---

From: "Eric S. Johansson" <[email-masked]>
Date: Mon, 15 Sep 2003 08:57:41 -0400

> provided you bought them in batches of at least 5000.

I really must find the time for a camram FAQ:

You assuming that the costs camram puts on a spammer are financial.  They are 
but only indirectly.  Camram imposes a time penalty on sending messages.  Given 
a three second stamp, T1 data path yields a 140X slowdown for a spammer.  Add a 
couple of bits to the stamp and the slowdown is now 560X.  In the spam world, 
revenue is a function of volume.  Slow them down and you reduce their revenue. 
Slowly it down enough and you end up with reducing or eliminating profitability.

Now, one might think you would be easy to put together a room and run 150 or 
more machines generating stamps.  The problem is generating stamps creates heat 
and lots of it.  It is working that CPU to death.  That means the systems must 
be extremely well cooled and the server room must have very two to three times 
the normal cooling level.  If you don't, you end up with rapidly failing machines.

Take this observation to absurd directions and you get the impression that one 
could target spammers with heat seeking missiles... ;-)

what I am really trying to point out is that the large-scale generation of 
stamps is not a trivial proposition and puts costs in terms of time, 
infrastructure and personnel on a spammer.

always work the math on problems like these from many angles because the desired 
effect may not always be obvious.  I learned that lesson when trying to analyze 
why we have monopolies at last mile and the construction of duplicate facilities 
just isn't going to work.

> is currently estimated in the millions.

remember what I said about not obvious effects and he generation above.  If 
there are Trojaned machines out there and they start generating stamps, they 
won't get a very high generation rate if they want to remain invisible.  If you 
are generating stamps at any level, performance goes to hell, the machine 
overheats, becomes unreliable, stamp generation stops.  If it is a personal 
machine then someone is bound to notice a) the performance degradation or b) 
that something smells bad just before it stopped working.  Unless you slow down 
the stamp generation process, it is clearly visible.

I'm not try to minimize the Trojan problem.  It is a serious issue in many ways. 
  However, it does have its limits and is not invisible like the current 
Trojans.  On the plus side, it may make compromised machines easier to find and 
repair.

---eric

---

From: J C Lawrence <[email-masked]>
Date: Mon, 15 Sep 2003 11:10:26 -0400

On Mon, 15 Sep 2003 08:57:41 -0400 

> You assuming that the costs camram puts on a spammer are financial.
> They are but only indirectly.  Camram imposes a time penalty on
> sending messages.  Given a three second stamp, T1 data path yields a
> 140X slowdown for a spammer.  Add a couple of bits to the stamp and
> the slowdown is now 560X.  In the spam world, revenue is a function of
> volume.  Slow them down and you reduce their revenue. Slowly it down
> enough and you end up with reducing or eliminating profitability.

Translation: only one-off single-addressee messages are cost effective.
Bulk mail of any form, be it spam, mailing lists or other mass
broadcasts are penalised.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

---

From: Paul Tenny <[email-masked]>
Date: Mon, 15 Sep 2003 14:33:16 -0400

Please pardon me for jumping in on a conversation that I have definitely 
not kept up with in any way, but I have something to add here.
Spamming is a business. Not all of them are people of low intelligence 
and not all of them are one man operations. Not all of them are
running on financial fumes.

If we can assume all that, then figure this one into your equation. PC 
processors have a large instruction set so they are great for
very non-specific tasks. The massive amount of heat comes from the 
abnormal amount of transistors. Fabrication of processors
with large instruction sets with complicated designs is very costly. 
FPGA's however are not excessively hard to design nor are
they enormously expensive to fabricate. My memory is quite rusty on this 
but I seem to recall a non-profit group wanted to
attack the distributed.net problem from a new angle. Rather than using a 
large number of commodity PC's, they had something
like 10-15 FPGA's (field programmable gate-array's, task-specific 
processors that can be reprogrammed on the fly) with
very specific instruction sets on a special PCB that connected directly 
to a normal PC (I don't recall how).

I do believe the cost was somewhere in the range of $15,000 - $20,000 
for the hardware and they were blowing away PC clusters
with nodes well over 200. Because these chips don't have anywhere near 
the transistor count of a PC processor they didn't
generate anywhere near the equivalent amount of heat. Their performance 
simply wasn't tied to the clock cycle like PC processors
are.

That's a small price to pay, and that was back in the late 90's.

If the idea here is to cause penalty for sending email (doesn't matter 
in what way), it's fundamentally flawed.
Whatever the software does, it has to run on a processor of some sort, 
and not necessarily the kind you
want it to be run on. Linear speed is not always going to be a limiting 
factor.

Eric S. Johansson wrote:

> Now, one might think you would be easy to put together a room and run 
> 150 or more machines generating stamps.  The problem is generating 
> stamps creates heat and lots of it.  It is working that CPU to death.  
> That means the systems must be extremely well cooled and the server 
> room must have very two to three times the normal cooling level.  If 
> you don't, you end up with rapidly failing machines.
>
> Take this observation to absurd directions and you get the impression 
> that one could target spammers with heat seeking missiles... ;-)
>
> what I am really trying to point out is that the large-scale 
> generation of stamps is not a trivial proposition and puts costs in 
> terms of time, infrastructure and personnel on a spammer.
>
> always work the math on problems like these from many angles because 
> the desired effect may not always be obvious.  I learned that lesson 
> when trying to analyze why we have monopolies at last mile and the 
> construction of duplicate facilities just isn't going to work.
>
> remember what I said about not obvious effects and he generation 
> above.  If there are Trojaned machines out there and they start 
> generating stamps, they won't get a very high generation rate if they 
> want to remain invisible.  If you are generating stamps at any level, 
> performance goes to hell, the machine overheats, becomes unreliable, 
> stamp generation stops.  If it is a personal machine then someone is 
> bound to notice a) the performance degradation or b) that something 
> smells bad just before it stopped working.  Unless you slow down the 
> stamp generation process, it is clearly visible.
>
> I'm not try to minimize the Trojan problem.  It is a serious issue in 
> many ways.  However, it does have its limits and is not invisible like 
> the current Trojans.  On the plus side, it may make compromised 
> machines easier to find and repair.
>
> ---eric

---

From: "Eric S. Johansson" <[email-masked]>
Date: Mon, 15 Sep 2003 14:49:38 -0400

> broadcasts are penalised.

like I said, I really should have an FAQ :-)

you are right that any bulk mail to strangers[1] is penalized either by paying 
the postage or trying to navigate the filter hazards.  However, as I have said 
one million times in teh past and I will say million times in the future 
"strangers cost, friends fly free".

In the short-term mailing lists will be defined as friends through manual white 
list.  White listing mailing lists is hazardous and creates a hole for 
spammers[2].  in the longer-term with white list by public key, mailing lists 
will only need to sign a message once and then they can deliver to the 
subscriber list without penalty.

[1] a stranger is defined as someone you have not e-mailed in the past.  This 
will evolved to someone you have not accepted their public key yet when the 
camram infrastructure is in place.

[2] white listing the mailing list creates spammer holes because they can just 
put the mailing list address in CC and they get by simple white listing by name 
filters extremely easily.  Personally, I want to filter most of my mailing lists 
because they are gateways for spammers such as the freeswan and openSSL mailing 
lists.

I hope that clarifies its sufficiently.  If not, feel free to e-mail me and I'll 
try to do better.

---eric

---

From: "Eric S. Johansson" <[email-masked]>
Date: Mon, 15 Sep 2003 15:05:44 -0400

Paul Tenny explained:

> Please pardon me for jumping in on a conversation that I have definitely not
> kept up with in any way, but I have something to add here. Spamming is a
> business. Not all of them are people of low intelligence and not all of them
> are one man operations. Not all of them are running on financial fumes.

understood.  It is going to take a combination of factors to take out spammers. 
  I have a couple in my back pocket I will reveal with camram 0.2.  Some of the 
others proposed will also help by attacking other weak parts of the spammer 
equation.

> I do believe the cost was somewhere in the range of $15,000 - $20,000 for the
> hardware and they were blowing away PC clusters with nodes well over 200.
> Because these chips don't have anywhere near the transistor count of a PC
> processor they didn't generate anywhere near the equivalent amount of heat.
> Their performance simply wasn't tied to the clock cycle like PC processors 
> are.
> 
> If the idea here is to cause penalty for sending email (doesn't matter in
> what way), it's fundamentally flawed. Whatever the software does, it has to
> run on a processor of some sort, and not necessarily the kind you want it to
> be run on. Linear speed is not always going to be a limiting factor.

we did talk about that earlier and the advantage is always in the hands of the 
distributed network.  unfortunately, I can't locate the posting in the archives. 
  In any case, the basic line of thought was it a spammer does it brute 
force/bloody ignorance with specialized hardware, Taiwan Inc. can replicate the 
work cheaper and faster, put it on every motherboard and a bunch of PCI cards 
for the earlier motherboards which means there'll be a big jump in the cost of 
postage and we're back at square one with the spammers still losing[1].

Remember, the advantages always in our hands because we can increase postage at 
any time.  For every bit of postage increase, the spammers workload doubles.  We 
can also afford a greater postage increase that a spammer because we have the 
advantage of a white list which significantly reduces the load of generating 
stamps at our end.  However, I believe a more probable approach will be the 
development of proof of work puzzles that are not so amenable to hardware 
solutions.  But the advantage still remains.

---eric

[1] big caveat.  As much as we pontificate and postulate on this list, we have 
virtually no clue where the future will go or how our inventions will mutate in 
wonderful and horrible ways.  spam is an evolutionary process and as our tools 
change so will spam which means we will change in response.  I say let's 
experiment and with that, I'm going to vanish for a couple days to apply a big 
evolutionary hammer to my code.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 15 Sep 2003 21:06:37 +0200

At 2:33 PM -0400 2003/09/15, Paul Tenny wrote:

>  FPGA's however are not excessively hard to design nor are they enormously
>  expensive to fabricate. My memory is quite rusty on this but I seem to
>  recall a non-profit group wanted to attack the distributed.net problem
>  from a new angle. Rather than using a large number of commodity PC's,
>  they had something like 10-15 FPGA's (field programmable gate-array's,
>  task-specific processors that can be reprogrammed on the fly) with very
>  specific instruction sets on a special PCB that connected directly to a
>  normal PC (I don't recall how).

	EFF's "Deep Crack" was based on FPGAs, and was used to 
brute-force 56-bit DES encryption in less than 3 days.  They used 
similar hard to help the distributed.net effort.  See 
<http://www.eff.org/descracker/> for more info.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Paul Tenny <[email-masked]>
Date: Mon, 15 Sep 2003 15:41:48 -0400

I was way off in a lot of numbers, stale memory does that to a person.
But it still seems a small price to pay for the amount of money some
spammers are supposedly making, no?

(To anyone concerned, you don't have to CC to me, I'm subscribed
to this list and have been for a long time.)

Brad Knowles wrote:

>     EFF's "Deep Crack" was based on FPGAs, and was used to brute-force 
> 56-bit DES encryption in less than 3 days.  They used similar hard to 
> help the distributed.net effort.  See <http://www.eff.org/descracker/> 
> for more info.
>

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 15 Sep 2003 22:23:26 +0100

> help the distributed.net effort.  See <http://www.eff.org/descracker/> 

Sorry, as I understand it Deep Crack was built using ASICs - that's 
pure custom silicon, not FPGAs.  FPGAs are a more recent development 
and are much cheaper than ASIC design, assuming your intended task is 
not excessively complex.

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

---

From: Brad Knowles <[email-masked]>
Date: Tue, 16 Sep 2003 00:46:32 +0200

At 10:23 PM +0100 2003/09/15, Jonathan Morton wrote:

>  pure custom silicon, not FPGAs.

	You are probably correct.  That would explain why the chips were 
marked "Deep Crack" on the board, something I couldn't figure out 
previously.

>                                   FPGAs are a more recent development
>  and are much cheaper than ASIC design, assuming your intended task
>  is not excessively complex.

	I would expect FPGAs to be nearly as powerful as ASICs, since 
you're basically building the same kind of custom circuit designs 
that you'd want to be using anyway.  The difference is that ASICs are 
"programmed" via the mask that is used to perform the 
photolithography, whereas the FPGAs can be programmed in the field to 
any circuit you want.

	The transistor count on FPGAs is lower than on ASICs, but it is 
still many orders of magnitude better than what you can get in 
software on general-purpose machines.  See 
<http://developers.slashdot.org/article.pl?sid=02/12/04/1526226&mode=thread&tid=106> 
and 
<http://slashdot.org/article.pl?sid=03/08/19/2229238&mode=thread&tid=126&tid=127&tid=137&tid=156&tid=186> 
for two higher-profile examples from relatively recent memory.

---

From: David Jonsson <[email-masked]>
Date: Tue, 23 Sep 2003 10:48:05 +0200

The problem with email path verification is how to start it up. I 
suggest the following.

First there is the buildup stage. All mails arriving whose path is not 
verified are marked as unauthorised to the recipient and a copy of the 
mail is sent back to the sender and the senders postmaster to inform 
them that their address has been used in an unverified way. In that way 
the sender becomes informed if their address is being misused or that 
their servers lack mail path verification. Together with the returned 
email is sent information on how to find information to arrange email 
path verification in DNS and sendmail (and other MTA's). The return 
email also contains information about from which date unverified emails 
are going to be rejected.

This buildup stage runs for some months (a predefined period) until all 
Internet has been aware of the problem and the solution and reasonable 
time has been offered for organizations to implement solutions. After 
the buildup stage comes a deadline where all unverified emails are rejected.

As far as I can see the deployment of this solution can be managed by 
the Internet society. If this proves impossible I say we must turn to 
Koffi Annan, George Bush, Göran Persson or someone else within politics.

David

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 24 Sep 2003 16:14:24 -0400

> the buildup stage comes a deadline where all unverified emails are 

 From the techical considerations document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt):

---------snip---------
A key construct to examination of adoption and benefit is 
"core-vs-edge".  Generally, adoption at the edge of a system is easier 
and quicker than adoption in the core. If a mechanism affects the core 
(infrastructure) then it usually must be adopted by most or all of the 
infrastructure before it provides meaningful utility. In something the 
scale of the Internet, it can take decades to reach that level of 
adoption, if it ever does.

Remember that the Internet comprises a massive number of independent 
administrations, each with their own politics and funding. What is 
important and feasible to one might be neither to another. If the latter 
     administration is in the handling path for a message, then it will 
not have implemented the necessary control mechanism. Worse, it well 
might not be possible to change this. For example a proposal that 
requires a brand new mail service is not likely to gain much traction.

By contrast, some "edge" mechanisms provide utility to the first one, 
two or three adopters who interact with each other. No one else is 
needed for the adopters to gain some benefit. Each additional adopter 
makes the total system incrementally more useful. For example a filter 
can be useful to the first recipient to adopt it. A consent mechanism 
can be useful to the first two or three adopters, depending upon the 
design of the mechanism.
--------snip----------

This is why the ASRG was chartered to look at consent speficially since 
this is something that works on the "edge" of the network. Now regarding 
specific verification methods, take a look at this presentation:

http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf

> Koffi Annan, George Bush, Göran Persson or someone else within politics.

The IRTF/IETF does not enforce standards, just researches them and 
defines them. There are several foundational documents currently being 
discussed and any help with them would help.

Yakov