Subject: RE: [Asrg] (no subject)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Apr 2004 14:20:28 -0700

> Yeah well via some creative editing you managed to reverse my point
> and create a straw man to argue with.

Not at all, the argument you made was spurious under either interpretation.

> I countred that the fact that we obviously handle those 5B msgs/day
> would not seem to argue AGAINST the possibility of adding a little
> more processing to each, it would seem to argue FOR the possibility.

It would seem to me to be at best completely and utterly irrelevant.
The ability to move an email message without any form of authentication
whatsover does not seem to argue for the possibility of moving a
payment with that email.

The fact that the volume is 5 billion a day does argue that any 
settlement system is going to have to be substantial. 

> But a proof? No, not a proof, not either way. Which was my point
> exactly.

Actually your claim was:

>  > > Obviously if we can deliver that many emails per day 
> THEN WE CLEARLY
>  > > CAN HANDLE THAT MANY TRANSACTIONS PER DAY! Nicht wahr?

I don't know how you expected this statement to be interpreted.
I will merely observe that if the French had not rescued you 
from certain defeat at Yorktown you would now be speaking English.

		Phill

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

---

From: Barry Shein <[email-masked]>
Date: Wed, 28 Apr 2004 18:12:34 -0400

> from certain defeat at Yorktown you would now be speaking English.

E-mail transactions, philip, that was the original assertion I was
responding to, not my assertion. What you are responding to is
anybody's guess.

And I'll resist making obnoxious comments about Normandy and speaking
German...

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: "Roger B.A. Klorese " <[email-masked]>
Date: Wed, 28 Apr 2004 15:35:21 -0700

>responding to, not my assertion. What you are responding to is

The idea, Barry, is that the business transaction (as in database and 
application interaction -- you know, what 99% of the IT world thiks of 
when you say "transaction") that is needed to support postage is likely 
to be much heavier-weight than the protocol interaction that is required 
to deliver the message itself.

---

From: Barry Shein <[email-masked]>
Date: Wed, 28 Apr 2004 22:47:32 -0400

Then I would suggest not designing the it like that.

Why is there this prevalent belief that if one doesn't like an
approach, for some other reason, the right thing to do is to propose a
really bad design for it and then assert that those design flaws make
the original idea untenable?

I can't imagine, for example, anyone ever having approved the original
DNS proposals if this were the atmosphere. And that was back in, what,
1983? Imagine! A series of query-response transactions down through a
tree of hosts just to map a host name to an IP number! Couldn't ever
work! Do you have any idea how many host names, between mail and ftp
and everything else people do, are looked up *per second*?! etc etc
etc.

Anyhow, does anyone else see how futile it is if a proposal is
immediately jumped on with "Too many computrons!!!", unless there's
something terribly inherent to the proposal, like you have to break a
significant crypto code to send mail? I don't think mere
recordkeeping, authorization, etc qualifies as a priori sort of too
many computrons.

-- 
        -Barry Shein

---

From: "\"Roger B.A. Klorese \" " <[email-masked]>
Date: Wed, 28 Apr 2004 22:21:35 -0700

Barry Shein wrote:

>Do you have any idea how many host names, between mail and ftp
>and everything else people do, are looked up *per second*?! 
>

Lookups are cheap.  Atomic multi-record updates are expensive.  DNS is 
99.99+% read-only.  Postage is heavily update-biased.

---

From: John Levine <[email-masked]>
Date: 29 Apr 2004 06:38:21 -0000

What's the point of e-postage?  All the e-mail systems I know would
have no trouble handling their incoming mail if they only got mail
that their users wanted, even with a little unwanted mixed in.  This
tells me that the goal of e-postage is some combination of
compensating recipients and deterring or at least rate limiting
senders.

If you're going to compensate recipients, you either need a single
central post office (or a cartel of post offices that trust each
other, which amounts to the same thing), or else you need settlements
to get the money from the sender's stamp provider to the recipient's.

We presumably agree that we don't want a central post office to meter
the mail as it's injected into the system.  I have a pretty good idea
of what it would cost to build a transaction infrastructure big enough
to count the stamps to get the raw data needed for settlements, which
tells me that settlements aren't going to happen, either.

So let's think about rate limiting or deterring senders.  Perhaps I'm
suffering from a failure of imagination, but I don't see useful rate
limiting without some cooperation from the recipients.  This is for
two reasons: one is that recipients don't want to rate limit the mail
they want, and the other is that without some way for the recipients
to audit the rate limiting, naughty senders will lie and claim they're
rate limiting when they aren't.

There's a minor exception here to the cooperation rule for for ISPs
and their customers.  If I were an ISP, I would rate limit my
customers' outgoing mail since anyone who sends a whole lot of mail
and hasn't told me they're running mailing lists is a zombie.
Although I can imagine various ways to rate limit by charging by the
message, it seems a lot easier and more effective to rate limit by
rate limiting, either slowing down senders or just firewalling them
until they fix their problem.  If you charge, you'll have trouble
collecting (credit card companies aren't thrilled about penalties
other than their own) and spammees won't find the fact that you made
extra money from the spam your users sent them very reassuring.

Receipient rate limiting might take the form of hashcash, although
that seems too easily circumvented so long as the bad guys have
zombies to do their hashing.  With better authentication, recipients
might be more able to count mail by sender and tell the overeager
senders to back off.  With agreements a la Bonded Sender, recipients
might demand consideration to accept mail from dubious sources, but
then you're back to a cartel or settlements to make the demands stick.

So where does this leave e-postage?  Other than as a clumsy way to get
people to fix their zombie machines, nowhere I can see.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 29 Apr 2004 09:47:50 +0100

A good summary, John.

> zombies to do their hashing.

This is a quantitative rather than qualitative argument against 
hashcash, which is easily answered by increasing the bit count demanded 
by the recipient, if it seems it's not having enough effect.  This is a 
measure that can be implemented by individual recipients who feel it 
necessary, rather than needing to be implemented unilaterally.

--------------------------------------------------------------
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: John Levine <[email-masked]>
Date: 29 Apr 2004 17:12:24 -0000

>A good summary, John.

Thanks.

>by the recipient, if it seems it's not having enough effect.

The problem is that if you increase the bit count demanded from the
bad guys, you also increase the bit count demanded from the good guys.
Since the bad guys have more computers at their disposal than the good
guys do, if you demand a big enough hash from the bad guys to deter
them, you're going to lock out the good guys altogether, e.g., demand
a hash from Aunt Sadie that will limit her 486 to one e-mail message a
week.

You might want to demand larger hashes from bad guys from good guys,
but if you could tell which was which, you could reject the bad guys'
mail outright and dispense with the hashes.

Regards,

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 29 Apr 2004 18:58:57 +0100

> mail outright and dispense with the hashes.

Note that SHA-1 is noticeably more computationally expensive on x86 
than most RISC platforms (or, probably, AMD64), which automatically 
makes the present incarnation of hashcash biased against the current 
crop of Wintel zombies.  As a point of comparison, it takes about 2500 
cycles per hash on an Athlon-XP, versus only 1000 on a PowerPC G3 or 
G4.  This has positive implications for third-party vendors - see 
below.

I've partially worked out a scheme which offers two solutions to this 
problem:

- Users with low-end machines (including handhelds) may buy hashcash 
tokens from a stand-alone third party vendor.  This doesn't require the 
micropayment infrastructure that full-blown e-postage needs.  Hashcash 
vendors need only recoup their own costs, thus a competitive market is 
easy to achieve without any need for regulation.

- The stamp optionally includes a signature to facilitate whitelisting. 
  This can reduce the hashcash demanded from regular correspondents to 
as low as 8 bits, which is computationally trivial - thus even low-end 
users will not normally need to buy tokens regularly.  Unlike existing 
high-confidence schemes like PGP and S/MIME, it is only for 
reasonable-confidence identification of regular correspondents, and as 
such is considerably more lightweight and doesn't require anything of 
the message body.

Can anyone shed some light on how many cycles a Z80 processor would 
take to handle a typical SHA-1 hash cycle?  Since derivatives of the 
Z80 may still be used in a few of the lowest-end handhelds, I'd like to 
have a handle on how long it would take for it to generate the 
"computationally trivial" 8-bit hashcash token that the signature 
requires.  If nobody happens to have a Z80 and a compiler to hand, I'll 
put in some work and try it for the 6502 instead - I have a handful of 
old BBC Micros lying around.

---

From: John Levine <[email-masked]>
Date: 29 Apr 2004 21:18:32 -0000

>Now several things can happen in the state graph.
>
>a. Sender has no more msgs to devlier anyway.
>b. Sender has more, and follows Recip's desired 1/h
>	- At some point, Recip decides that Sender has been faithful,
>		and may be allowed a higher rate.
>c. Sender has more, and ignores Recip's desired 1/h
>	- Sender is blacklisted.
>
>Optionally:
>
>d. Sender has more, and requests a higher rate allowance by providing
>	an accreditation, hashcash, 'introduction protocol' referral ID,
>	etc.
>e. Sender provides a one-time, or reusable key that was provided out of
>	band by recipient - i.e. when signing up for a mailing list -
>	which entitles Sender to a higher rate limit.

f. Sender pretends to be 300 other people and sends you buckets of spam.

Bad guys won't play by your rules.

Regards,

---

From: David Maxwell <[email-masked]>
Date: Thu, 29 Apr 2004 14:04:03 -0400

> rate limiting when they aren't.

This sounds like it's begging for a consent protocol implementation.

Sender: Hello, I have mail for you.
Recip: I have no record of talking to you before. I'll accept 1msg/h
Sender: Understood. 1msg/h. Here's a msg.

Optionally:

Well known senders gradually receive high rate limits. New spammer
domains recieve low limits, and are blacklisted due to content (possibly
by distributed blacklists) before they can deliver a significant amount
of spam.

A variation of this scheme could be used between users and their ISP.

P.S. My idle speculation is that you might be able to implement this
without changing SMTP, by using SIP to arrange the connections.

-- 
David Maxwell, [email-masked][email-masked] -->
All this stuff in twice the space would only look half as bad!
					      - me

---

From: David Maxwell <[email-masked]>
Date: Thu, 29 Apr 2004 17:57:30 -0400

> Bad guys won't play by your rules.

That's not an assumption in the example. Sender can't pretend to be a
different Src IP.

---

From: Barry Shein <[email-masked]>
Date: Thu, 29 Apr 2004 21:45:04 -0400

Atomic multi-record updates? How about just a log which is processed
asynchronously? Why in the world would this have to be kept in perfect
sync in real-time?

And, that said, do the main dns servers keep log files? Seems that'd
be similar.

Besides, all you're saying is that it'd probably take more computrons
to run an e-postage system, given various assumptions about how it
might work, than the current dns system does. Ok. But there still are
many similarities, particularly in distribution and scale and need for
organization.

Anyhow, that's very different than showing that too many computrons
are required to be reasonable.

$1,000 computers are today over 1,000 x as fast as $1,000,000
computers were when DNS was designed.

     -b

---

From: Barry Shein <[email-masked]>
Date: Thu, 29 Apr 2004 22:16:00 -0400

I don't find compensating recipients interesting or relevant so that's
a straw man. Does the post office charge postage soas to pay
recipients? W/o stretching the point?

Anyhow, e-postage is a way to make the price reflect the usage.

Here's another simple outline that would not be subject to all these
straw man arguments:

1. A stamp is a cryptographic signature identifying the ISP affixed to
e-mail.

2. The certificate for creating such stamps is bought by the ISP from
approved certificate-issuing authorities, much like SSL certs at least
in theory.

3. The cert is issued for some rough amount of email, 100K/day,
1M/day, etc. and the price reflects that. The ISP will in some
industry-agreed upon way provide some basic evidence that the cert is
probably about right. This can be verified via auditing, sampling,
etc., basic business records might help (everyone knows AOL has
whatever, 2.5m customers, no one would believe them if they said they
only plan to send 100,000 mail msgs per month, etc.)

Similar sampling-based methods (to keep things reaonably honest) have
been used for over 75 years for radio music royalties, also similar
systems are used for trade magazines subscription/ad ratios, etc. so
if you're not familiar with examples such as those look into it
because it would seem to be a rich source of ideas.

The important point is that you don't have to be absolutely accurate,
just accurate to a degree, i.e., not buy a 100K/day cert when
intending to send 10M/day. Getting caught cheating should be fairly
serious. Obviously a simple mistake can be fixed etc (oh don't jump on
it there are many business contracts where you have to
estimate/project usage and then settle up later.)

4. Recipient ISPs (and end-users for that matter, tho it's not
necessary) can verify the authenticity of certs and if they like
verify that a cert hasn't been revoked (one might do this with an
authority server for every 100K uses or once a day or hour, the
downside isn't all that serious usually.)

5. Recipient ISPs can choose to do what they like with email msgs
without good certs. They might deliver them, but they might be advised
to (after some transition period) reject them because that's what
would make the system work.

6. ISPs may pass these costs along to their own customers however they
like, that's a marketing decision. Most likely they'd allow some
number of msgs "for free" (included in basic acct fee) and charge for
usage beyond that. They might sell a mailing list package for $20/mo
extra that includes another 100K msgs/mo, whatever.

7. But the important point is that ISPs would be highly motivated,
assuming a reasonable cert price structure, not to allow customers to
send millions of msgs per day unrestrained. How they handle accidents
or break-ins would be their own choice of policy, but they might be
well-advised to practice some leniency if they wish to keep their
customers happy.

I don't see any settlements, per-message real-time interactions,
onerous book-keeping, etc in any of that.

        -Barry Shein

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 29 Apr 2004 22:52:13 -0400

Barry,

This sounds like accreditation, not e-postage.

Yakov

--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"

---

From: John Levine <[email-masked]>
Date: 30 Apr 2004 03:34:34 -0000

>That's not an assumption in the example. Sender can't pretend to be a

The spam senders I know, withe their farms of zombies, don't have to
pretend to be different source IPs, because each zombie has a separate
IP all of its own.

---

From: "Roger B.A. Klorese" <[email-masked]>
Date: Thu, 29 Apr 2004 22:09:49 -0700

> asynchronously? Why in the world would this have to be kept in perfect

Because it's the transfer of MONEY, Barry, which requires both exactness 
and atomicity.

---

From: John Levine <[email-masked]>
Date: 30 Apr 2004 16:55:18 -0000

>> f. Sender pretends to be 300 other people and sends you buckets of spam.

Sorry, that was supposed to be:

f. Sender pretends to be 30,000 other people and sends you buckets of spam.

>Now, if you like, add greylisting for unknown senders, so that those
>300 msgs won't be accepted on the first try. Then, add a distributed
>blacklist which you check your mailqueue against before delivery to
>users' inboxes. Application of the blacklist can be part of whatever
>other content spam filters the user has.

DCC already does that.  It works reasonably well, with no need to
invent new consent protocols.

Regards,

---

From: David Maxwell <[email-masked]>
Date: Fri, 30 Apr 2004 11:24:20 -0400

> pretend to be different source IPs, because each zombie has a separate

That's not a problem. Each IP is a new Source, since it has no
reputation, it will be allocated 1msg/h (or whatever your initial
setting is). That means that you're down to 300 spam/h received in your
entire domain.

Now, if you like, add greylisting for unknown senders, so that those 300
msgs won't be accepted on the first try. Then, add a distributed
blacklist which you check your mailqueue against before delivery to
users' inboxes. Application of the blacklist can be part of whatever
other content spam filters the user has.

Now, each zombie can be used roughly once, before it gets into the
blacklist (they probably expire at some point). Spam sent from a
blacklisted zombie won't affect anyone who checks the list.

If you want some feedback to the zombie'd user, add a blacklist check to
your webpage - replace normal content with "This web page can not be
viewed by virus-infected client machines." - and maybe people would have
cause to clean up their PCs.

-- 
David Maxwell, [email-masked][email-masked] --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering, 
unthinking mass.  This is the same reason why you probably don't tell your 
boss about everything you read on BugTraq!    - Signal 11

---

From: Barry Shein <[email-masked]>
Date: Fri, 30 Apr 2004 16:56:03 -0400

> Because it's the transfer of MONEY, Barry, which requires both exactness 

Nonsense, utter nonsense.

-- 
        -Barry Shein

---

From: "\"Roger B.A. Klorese\" " <[email-masked]>
Date: Fri, 30 Apr 2004 15:01:52 -0700

>Nonsense, utter nonsense.

Your "utter nonsense" is utter nonsense.

Especially since you're dealing with people with whom you DO NOT 
otherwise have an existing relationship, billing in arrears is 
impractical and unenforceable.  It only makes sense for it to be 
immediate pay-as-you-go.

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 1 May 2004 00:44:50 +0100

> - The stamp optionally includes a signature to facilitate 
> whitelisting.  This can reduce the hashcash demanded from regular 
> correspondents to as low as 8 bits, which is computationally 
> trivial...
>
> ...If nobody happens to have a Z80 and a compiler to hand, I'll put in 
> some work and try it for the 6502 instead - I have a handful of old 
> BBC Micros lying around.

To answer my own question, I've worked out that a 6502 can process an 
SHA-1 block in about 40000 cycles, which compares surprisingly well to 
the 68030 (and begs an investigation into precisely why the '030 is so 
inefficient).  This is completely untested code - I didn't even type it 
into the machine, just worked out the timing piecemeal from the 
assembly manual - but the ballpark figure should be accurate.

To put this in perspective, it means that my 1982-vintage BBC Micros 
(with 2MHz 6502 chips) should be able to mint 8-bit hashcash in about 5 
seconds on average, and most other 8-bit accumulator machines 
(including the Z80 family) should be comparable.  This, in turn, means 
that my whitelist-grade signature scheme should be computationally 
feasible for pretty much every "computer" capable of running a TCP/IP 
stack.  This encourages me to continue working on a more detailed spec 
for discussion.

Code size may be more of a problem, however, as the 40000-cycle 
performance assumes a fairly unrolled-loop code configuration, which 
consumes a significant portion of a 16-bit address space (exact size 
not calculated, but 4-8KB is possible).  It also assumes a fixed area 
of RAM, including 25 bytes of zero page and 340 bytes elsewhere, is 
available and hard-coded into the program.  For machines with a paged 
ROM system and a half-decent memory map, this shouldn't be a serious 
problem, but for some microcontrollers it may require a tradeoff of 
code size and/or position-independence against performance.

In any case, it is certainly no problem for any truly 32-bit machine.