Re: going off-list, Re: proposal for built-in spam burden & emailprivacy protection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




"Robert G. Brown" wrote:
> 
> 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)

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.

 
 
> 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 "joe@xxxxxxxxxxxxx" 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:-/

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.


> Obviously, people will no longer be able to just say "here's my email
> 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
> mostly in small type.  Most users will simply rebel.  Most systems
> 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?
 
> 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. 
> [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.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]