Subject: RE: proposal for built-in spam burden & email privacy protection

From: [email-masked]
Date: Thu, 12 Feb 2004 10:23:28 +0200

> The real problem isn't from companies who send bulk email and allow you to opt out.

Not true (amymore). Opting out involves either a click or and email response. Both are well know methods for the "bad guys" to harvest better email lists and thus this behaviour is a bad idea - even for the "potential-good-guys" because its rather difficult to tell the difference with unsolicited email.

So opt out mechanisms are not useful for the union of "bulk" and "unsolicited" email (IMHO).

(Just one of my 2 cents worth :)

Sorry for the bulk nature of this limitted-content email!

Cheers, Rod.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 12 Feb 2004 12:34:22 -0800

Folks,

Thanks for the diverse and interesting feedback. I'm replying to 
each message off-list, not to burden the entire ietf.org 
discussions. I'm also collecting all comments for an Internet 
draft to be submitted to the IETF. If you have further comments,
I suggest you send them to me privately. I'll post here a URL
for the draft text, and comments, before the draft is submitted.

The motivation for this work is that, today, email is still the
equivalent of sending and receiving postcards. Open for anyone 
("friends" and foes alike) to read and even write on them. In 
the postal mail paradigm this is indeed useful ... but only for 
trivial messages between friends. 

Someday, however, users will want to stop using postcards for all 
their electronic conversations. At that time, at  zero added cost, 
we can easily introduce a mandatory per-message burden to spammers 
and make it backward compatible (so that we don't disrupt anything). 
The proposal points out that both goals (privacy and anti-spam) can 
be served not with signing but with encryption (even though, as an 
add on, signing may also help).

Of course, there will always be those who want to use postcards for 
their communication and that's why current postcard email should 
be preserved in any proposal to make email private.

Cheers,
Ed Gerck

---

From: Dean Anderson <[email-masked]>
Date: Thu, 12 Feb 2004 16:31:18 -0500 (EST)

> add on, signing may also help).

This is where the thinking is not clear: You can't add a cost to only
spammers.  Any cost increase in the cost of email would affect other large
email users (mailing lists, and such) at best equally to spammers, and
maybe not even equally.  Most spam is sent from infected computers, so the
spammer wouldn't pay anyway (whether it is money or computational power).

Further, any cost increase in email that is less than the cost of bulk
postal mail will not deter genuine spammers. But even the regular user
would feel the crunch if each email cost $0.37.  If the IETF had to pay
$0.37 per email, or even $0.15 per email, its 2 million/yr or so budget
would not cover its email costs, and your draft would not be published.

		--Dean

---

From: "Robert G. Brown" <[email-masked]>
Date: Fri, 13 Feb 2004 10:12:39 -0500 (EST)

> would not cover its email costs, and your draft would not be published.

I totally agree with Dean.  I see no significant increase in costs to
the spammers, who use almost entirely automated tools in any event even
when one IS considering their local resource consumption.  This isn't
just a matter of opinion -- one can easily measure what the increase in
the worst-case "cost" to spammers will be.

Currently, email addresses are relatively "simple" objects and as such
are easy enough to remember (for humans) and communicate (for humans).
You propose to make an address a "complex" object: the simple address
plus kilobyte-sized blocks of text or binary data such as:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)

mQGiBDprOxURBADW+ybmMpoBfbRADv3OzXaaIQVWGDoaNsR4uxstcJgo+FYMcO9B
Ag7eXRLfOQFPPS3211W/f1/GaQa70ZaPZaQV/A9POIGfRIbcfePHaIUUXYulO3Nh
Bqewb5JZjzkj0yZWdjzK/OSBEPITXMXyTDVnG0+Y4YHHLDOODnnkSOlZKwCg453O
...(much much more)

BOTH components will need to be included in a mail header presuming that
when one sends mail one WILL want one's correspondants to be able to
read and reply to your message.  BOTH components will have to be
published in various ways and given out if you want to continue to be
able to receive mail, be it from friends or strangers.

Automated grazers that collect the simple objects now can just as easily
collect the complex objects since they will of necessity both be
associated with any publiction of somebody's address.

On the other hand, this additional degree of complexity will be a
horrible burden in time, energy, and money to ordinary users of mail at
every level and especially to systems administrators responsible for
training those users and de facto responsible for managing the data
problem the composite "address" object would represent.  Communicating,
managing, and remembering email addresses like "[email-masked]" is
already "challenging" to many, if not most, users of email and is
obviously equally challenging at the corporate/professional level.  Let
us recall that most current AV software is still stupid enough to
consider the From address to actually be valid for viruses and SPAM and
cannot even manage to parse the real message header in sensible ways.
Now visualize these same bozos trying to deal with messages whose header
contains a 1-2K key:-/

Obviously, people will no longer be able to just say "here's my email
address".  Business cards will need to be roughly 4x6" and covered
mostly in small type.  Most users will simply rebel.  Most systems
people will simply rebel.  People CAN send encrypted, signed email now,
but how many do?  It's cumbersome and unnecessary for all but a certain
(small) class of sensitive traffic.

You are also suggesting that the encryption step, by being "expensive"
computationally, will at least slow down the spammers.  This assertion,
which has been made several times now, is simply not true.  Encryption,
especially RSA-type public/private key encryption, is NOT terribly
demanding in terms of numerical operations required per encrypted byte
-- this is one reason it is a popular and powerful algorithm.  Both SSL
and SSH routinely encrypt realtime traffic with little or no perceptible
delay relative to other sources of latency.  I use tools like rsync on
top of ssh to send entire compressed AND encrypted filesystem trees at
rates that (greatly) exceed a MB/second.  CPUs are powerful and cheap
and then there is Moore's Law.

Even with gpg used as a command line tool, it requires less than a
second to encrypt roughly a megabyte (possibly less -- the process is
likely not optimized for speed in the tools I'm using to crudely
measure).  That would be 500-2000 "typical" SPAM messages per second.  I
expect that this rate would easily ntuple if the relevant code were
extracted and written into an optimized binary, as gpg as a command line
tool has lots of per-invocation overhead that could be eliminated if
one's goal was simply to take a single message and a DB of keys and feed
an MTA queue.

Compare that as a bottleneck to the time required to send a thousand
email messages in the first place.  For each message there is a
nameservice hit to resolve the address, a protocol negotiation phase of
indeterminate length as the MTA connects to a remote agent and sends the
message on its way, and the local bandwidth bottleneck.  In nearly all
cases of stealth/virus driven SPAM, the per-message latency will likely
exceed the encryption time by a factor of two or more (quite possibly a
LOT more). A T1 link has a peak bottleneck of little more than a MB/sec,
for example, if you are pouring data through in an optimal stream.

Note that the encryption step is trivially parallelizable.  That means
that for a given MTA, EVEN if one is having a hard time keeping it busy
because of time spent encrypting (which I doubt), one can add one or
more cheap systems to the network to function as encryption slaves that
serve no purpose but to keep the MTA's outbound queue full.

I think that it is clear that your proposal won't have any significant
impact on SPAM generation, but it will have an enormous, and negative,
impact on ordinary mail users.

This is just a bad idea.  It is a VERY bad idea to push it as an actual
protocol requirement.  It is a bad idea to push it as best practice.  It
isn't even that great an idea to push it as a future design
recommendation.  It might be an "interesting" idea to discuss on an
appropriate list, and of course it is fair game for entrepreneurs and
developers with a vision and a perceived marketplace.

This is an issue that can be completely decided by those programmers
with a vision and the marketplace, not by a task force responsible for
developing protocols and open standards.  If one feels for any reason
that MTAs should be integrated with public key databases and
nameservices and key certificate agents extended to the level of
individuals, the protocols and open standard based tools all exist for
one to create software to support it (and indeed some individuals
already USE keys, signatures, and encryption for various purposes
including mail).  

So fine, invest the development effort to create the product and see who
buys it, or in the open source world, who adopts it and distributes it.
It is not appropriate for us to either mandate or suggest that ALL
developers "should" modify all their products to use a particular
layering of these tools as the default standard and force developers to
invest the resources required to do so at the very substantial risk that
no reward awaits them in the marketplace for having done it.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Ed Gerck <[email-masked]>
Date: Fri, 13 Feb 2004 17:20:36 -0800

"Robert G. Brown" wrote:
> ....(much much more)

The key can be given by:

1. return mail requesting an encrypted message with the
attached key (as I wrote in my first posting on this suggestion),

2. key server, by using an URL

3. by searching google

4. by using DNS records

5. by reading the email's signature line when my mail reaches you
and you want to reply to me.

So, there are many, simple and automatic ways for PK distribution.
PK certification is another thing, but encryption does not it.

Also, humans have been using complex postal addresses for centuries,
without even the benefit of computers to help with them until quite
recently. Complexity is in the eyes of the beholder.

> Now visualize these same bozos trying to deal with messages whose header

This will all require a level of automation and user-friendliness way
above what we have today. Nonetheless, possible and necessary if
we want to (1) preserve email confidentiality and (2) provide an even
mandatory burden to sending email.

On the flip side, I can see all your arguments above applying to
the difficulty of sending spam -- in addition to the time burden.

> address". 

Not true. After you send an email and you'd get a bounce requesting an
encrypted message, with the public-key included. In fact, you can 
easily use your email as a way to distribute your PK with the benefit 
of challenge-response -- if your email is active, the sender gets the 
current key for that address. You can also use it to update your PK, 
easily.

>  Business cards will need to be roughly 4x6" and covered
> people will simply rebel.  

:-) not really...see above.

> People CAN send encrypted, signed email now,
> but how many do? 

5%. The failure is actually ours, not making it easy to use. Just ask
any email user...How do they feel when they understand that email 
is really like a postcard... open for anyone to read? How do they
feel about spammers having near zero cost to send them messages
while they need to use valuable time and resources to weed them out?
 
> which has been made several times now, is simply not true. 
> [snip, good comments]

The point is that it CAN be made very expensive for sending 100,000s
of emails. In addition to the PK encryption of the random symm key
used to encrypt the message (in PGP, for example) you can also add 
the recipient's PK MACs to tie the recipient's PK to the message as 
well. Further, the proposal should include "puzzles" to be solved
by the sender (a la hashcash) that can penalize an unknown sender as
much as desired and trickle its output as much as needed.
 
Users can also require less burdensome encryption from known parties,
without "puzzles".

There is nothing to prevent a spammer -- as an entity with NO previous 
relationship to the receiver -- to be penalized at will, while known 
users mail send messages with regular encryption or even no encryption 
at all (by using whitelists).

I'm thus led to the opposite conclusion that you suggest: I think 
that it is clear that this proposal can have a significant
impact on SPAM generation, while but it will not have any, or  hardly
any, negative impact on ordinary mail users.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 13 Feb 2004 23:13:18 -0500 (EST)

I guess this didn't make it off list...

On Fri, 13 Feb 2004, Ed Gerck wrote:

> encrypted message, with the public-key included. 

Actually, there are already a couple systems that work like this.  
Qsecretary is one.  If I recall, someone is trying to patent this, even
though as a scheme, its been around since majordomo, or longer.  It
doesn't work well in a number of situations. I think if qsecretary sees
another qsecretary bounce, it can do the right thing (not positive about
that---Dan?).  But there is no guarentee that two different
bounce/responder systems will work correctly.  These systems also fail
with agents.

Eg, How does my voip gateway email me my phone messages?  What about my
Network management software? I want an email saying my customer just went
down.  How does my pager handle all of this?

Agents are becoming more and more pervasive. No doubt my microwave will
soon email me that my popcorn is ready, and my oven will tell me when to 
baste the turkey, and my car will email me when its time for service.

These things work ok in small close knit groups, but don't scale well.  
The fact that they don't scale is what makes them useful to the small
group. If you solve the agent/scaling problem, you solve the spammers
problem, too, and the usefullness is lost.

		--Dean