Spam Spotlight on Reputation

Hadmut Danisch hadmut at danisch.de
Mon Sep 6 18:15:33 EDT 2004


On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote:
> 
> E-mail security company MX Logic Inc. will report this week that 10 percent
> of all spam includes such SPF records,

I have mentioned this problem more than a year ago in context of 
my RMX draft (SPF, CallerID and SenderID are based on RMX).
Interestingly, nobody really cared about this major security problem.

All RMX-derivatives block forged messages (more or less).  But what
happens if the attacker doesn't forge? That's a hard problem.  And a
problem known from the very beginning of the sender verifikation
discussion.


The last 17 month of work in ASRG (Anti Spam Research
Group, IRTF) and MARID (Mail authorization records in DNS, IETF) are
an excellent example of how to not design security protocols. 

This was all about marketing, commercial interests, patent claims,
giving interviews, spreading wrong informations, underminding
development, propaganda. It completely lacked proper protocol design,
a precise specification of the attack to defend against, engineering
of security mechanisms. It was a kind of religious war. And while 
people were busy with religious wars, spammers silently realized that 
this is not a real threat to spam. Actually, it sometimes was quite
the opposite: I was told of some cases where MTAs were configured to 
run every mail through spam assassin. Spam assassin assigns a message
a higher score if the sender had a valid SPF record. Since most
senders with valid recors were the spammers, spam received a higher
score than plain mail, which is obviously the opposite of security. 
People spent more time in marketing and public relations than 
in problem analysis and verifikation of the solution. That's the 
result.

What can we learn from this?

Designing security protocols requires a certain level of 
security skills and discipline in what you want to achieve. 

Although RMX/SPF/CallerID/SenderID does not make use of cryptography,
similar problems can be sometimes found in context of cryptography.
Knowing security primitives is not enough, you need to know how to
assemble them to a security mechanism.  Good lectures are given about
the mathematical aspects of cryptography. But are there lectures about
designing security protocols?  I don't know of any yet.

And there is a new kind of attack: Security protocols themselves 
can be hijacked and raped by patent claims. 


regards
Hadmut













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



More information about the cryptography mailing list