spf-discuss
[Top] [All Lists]

RE: possibilities for 2822 (was SPF implementations)

2005-08-17 14:56:31
From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: Wednesday, August 17, 2005 2:53 PM

<...>

Speaking as someone with actual DKIM experience, I beg to differ.
DKIM has issues, but computational load is not one of them, not for
any modern mail system doing AV scanning and anti-spam processing.

If you are running SpamAssassin and AV on everything that hits your MX, what
you are saying is true.  That ignores the whole purpose of SPF and other
efficient authentication protocols.  The idea is to reject as much as
possible before DATA.  If you make it into DATA, reject it, if possible, at
the end of DATA without running SpamAssassin or AV tools.  Since most of the
traffic at most MTA's is either rejected or accepted and then silently
discarded, the amount of resources you spend before rejecting a message is
important.

Spam from zombies won't pass SPF and will be rejected before DATA.  Neither
will that spam pass DK or DKIM, but you have to receive the entire message,
retrieve the key or key digest and attempt to validate the signature before
rejecting.  Since you will reject in either case, you will not run
SpamAssassin or AV on that message.  In that case, which today accounts for
a lot of the traffic hitting MTA's, there is a large difference in CPU
expended.  Compared to the overhead of receiving a message with no
authentication, RSA signature validation when signed with long keys is quite
expensive.  SPF authentication is much lower overhead.


<..>

DKIM, like DK, uses DNS to distribute public *keys*, not signatures.

I did use the word 'signature' twice when I meant keys.  Sorry for the typo.


After a short period of operation, your resolver has most of the keys
you need in its cache.

On a large system, I would take issue with that claim.



  It is inherently prone to
replay, and combined with the high computational load, make it an
irresistible DDoS vehicle as the amplification factor is enormous.

DKIM is *not* prone to replay.  Yes, you could send the exact same
message over and over in mailbomb fashion, but mailbombing is hardly a
replay vulnerability introduced by DKIM.  At most, DKIM causes an
amplification small compared to that from AV-scanning.

I think you misunderstand the attack.  Someone copies a set of DK headers
and inserts it into their own message.  They change one character in the
signature, leave the selector and the other fields alone and compute a new
body hash.  This is all very inexpensive.  The attacker then sends the
message.  The recipient must receive the entire message, then has to fetch
the key or key digest.  You claim it's already in the cache, but on a large
system, it won't be much of the time.  Now the recipient, depending on
implementation, either validates the signature or first the body hash and
then the signature.  In either case, the CPU work to validate the signature
is expended.  You can reject this message, but the next one will come from
another domain with a different message body and a different signature.  The
attacker spent a tiny amount of resources, but you spent a lot.

If you want to create a DDoS vulnerability, think of a way that an attacker
can, with minimal effort, force you to do a lot more work than the attacker
did.  Since the attackers are distributed, you can't block them by IP.
Let's put this in perspective.  Anyone can be DDoS'd off the net no matter
what protections you put in place.  However, when you design a new protocol
for widespread use, you don't want to create something that has this high an
amplification factor.  It is both an invitation and a means to be attacked.

--

Seth Goodman