Seth Goodman writes (regarding DKIM):
Well, we can take that view, but it comes with a high price tag. For those
among us who have not yet looked it over, DKIM is an RSA signature scheme
that uses DNS to distribute signatures, or possibly digests of the
signatures that are included in the message body. Despite what the vocal
(to put it mildly) proponents of this technology say, this puts an
_enormous_ computational load on the recipient.
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.
Read the headers of this message and you'll discover that it is signed
with DKIM. It's also signed with plain DK (DomainKeys), which is very
similar to DKIM. On the receiving side, every message arriving here
has its DK and DKIM signature or non-signature checked. Each message
is also AV-scanned, and the computational load from AV scanning *far*
exceeds that from DK/DKIM. So does the load from SpamAssassin.
DKIM, like DK, uses DNS to distribute public *keys*, not signatures.
After a short period of operation, your resolver has most of the keys
you need in its cache.
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.
Instead of causing a DDoS vulnerability, DKIM could be used to reduce
the vulnerability, because only the signature need be looked at -
actually only a hash of the signaure need be looked at. Same hash,
same signature, same message - seen this one, reject.
DKIM does have problems, but so does SPF and everything else that's
come up so far.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com