UCE - a simpler approach using just digital signing?

[Jerry Leichter]

On Jan 30, 2009, at 4:47 PM, Ray Dillinger wrote:

> I have a disgustingly simple proposal.  [Basically, always include a  
> cryptographic token when you send mail; always require it when you  
> receive mail.]
There is little effective difference between this an whitelists.  If I  
only accept mail from people on my whitelist, spammers can only send  
me mail through three modes of failure:

	1.  They randomly pick a return address that happens to match someone  
on my
		whitelist.  I think we can agree that this is rare enough that it  
isn't
		worth worrying about.

	2.  A spammer somehow finds pairs of people S and R, where S sends to  
R, and
		fakes S as the sender for spam directed to R.  This would be a new  
mode
		of attack - spammers today just spurt out millions of messages based  
on
		very little information.  Sure, someone *could* start this kind of  
attack -
		but it's difficult to get the necessary information to mount it, and  
it
		seems unlikely that it would make economic sense to spammers, who  
can live
		with tiny response rates because they can so cheaply generate targets.

	3.  This is a variant of (2) that actually does occur today:  The  
spammer takes
		over S's machine and sends to the same people S sends to.  Viruses
		try to spread by this mechanism; they often succeed.  In principle, a
		spammer could write a virus that simply sent the (S,R) information  
from
		the infected machine, though I don't know that they've ever bothered.

	     Either a type 3 attack, or a type 2 attack where the information  
comes from
		invading S's, machine, can of course just as easily grab all the  
tokens
		on S's machine.  The solution proposed is that this will be noticed
		quickly, and the tokens will be marked as no longer valid.  But that's
		really no different from R simply removing S from his whitelist.

Really, cryptography is a non-issue here.  As long as S and R share  
some information - even S's address will do - that R can use to filter  
messages; and there is no cheap way to get large amounts of (S,R)-pair  
information; that information can be the key to a whitelist.  (Some  
mailing lists do this:  E.g., if you want to post to RISKS, you're  
asked to include the string "notsp" at the beginning or end of the  
subject line.  This is public information, so a spammer could easily  
do this *if he chose to specifically target the RISKS mailing list*;  
but there's no way he can do this automatically on a mass scale.  An  
individual could easily reach a similar agreement with anyone sending  
him mail.

Of course, the downside is that you can now *only* receive mail from  
those on your (logical) whitelist.  That's fine in some cases,  
unacceptable in others.  You can semi-
automatically grow your whitelist by sending using some kind of  
challenge/response.  For example, if you could send back the message  
with a note saying:  "You're not on my whitelist, if you want to reach  
me resend this message with 'xyzzy' in the subject line."  Spammers  
don't bother to look for such messages right now (though if you made  
this automatic enough, and enough people adopted it, they would have a  
reason to!) so they won't be able to sneak on your whitelist that  
way.  However, many people writing to you won't want to be bothered -  
and automated mailings that you *do* want to receive and don't know  
the details of ahead of time (e.g., approval messages for mailing list  
requests you make) won't get through either.
                                                         -- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com