From: George Schlossnagle
Sent: Monday, November 29, 2004 9:52 PM
On Nov 29, 2004, at 7:58 PM, Seth Goodman wrote:
From: David Woodhouse
Sent: Monday, November 29, 2004 6:33 PM
On Mon, 2004-11-29 at 18:14 -0600, Seth Goodman wrote:
Microsoft and Yahoo have resources that the average site does not.
Not everybody can afford IronPort boxes or specialized MTA
software like yours.
Er, yeah -- but not everybody would _need_ it either.
Some people in the middle will get pushed over the edge by the extra
load.
Well your choices are manifold:
1) Don't check or sign DK if you don't believe in it.
2) Make the implementation in your MTA faster.
3) Find someone and encourage them to make the implementation in your
MTA faster.
4) Use a validation scheme that is lighter weight.
Crypto accelerators would obviously solve the problem. As a hardware
engineer who works with DSP's, I would personally benefit from
an expanded market for such accelerators. Designing them is both
enjoyable and profitable for me. However, as an Internet citizen,
I would not like to see that become part of the price of admission
for email.
It wouldn't be. Mail servers aren't generally CPU-bound and wouldn't
become so with DK. This really isn't a problem.
So say the DK proponents, but the Sendmail data says otherwise. Please
explain how the throughput was reduced to approximately half with short
messages unless that mail server was CPU-bound. The only additional
I/O for the DK authentication is a single DNS query.
Have you even looked at their code? They write a copy of the message
to disk for signing. And local DNS queries, while fast, are still
expected to be in the 'couple millisecond' range. Honestly, there's
very little you can do with a message that won't push you into the
'several milliseconds' performance hit.
Those DNS queries don't take several milliseconds of CPU, do they? That's
several milliseconds that is mostly waiting for the reply.
If you're receiving 25 million spam mails per day (their single
machine, 1k message size verification numbers), you can hopefully
afford to invest in the extra $500 machine necessary to take you back
to 50 million spams per day. For instance, your bandwidth costs for
sustaining this will dwarf your hardware costs. You're exaggerating
the cost rather ridiculously and so I suspect you have another motive
for advancing these arguments.
We both know that MTA's receiving 25 million messages per day don't
generally run on $500 department store boxes. Though it is possible to do
so, I wouldn't want to leave my phone number for every time it breaks down,
and I doubt you would, either. An MTA running that volume should have
redundant power, gigabytes of ECC memory, RAID and a host of other features
that push the cost completely out of that range. Hardware of that class is
not cheap, nor is the facility you put it in, nor are the people who
maintain it, etc.
Yes, I absolutely have a motive for pointing out the costs of RSA signature
validation. I would like people to consider the quantity and placement of
the burden for PK crypto validation and to question if that makes sense. I
suggest that placing this degree of burden on the recipient of large
quantities of spam is not a good architectural choice. The validation
burden can be shifted more to the sender, though still be kept lower than
RSA, by signing with HMAC's based on one-way hash functions and validating
with lightweight callbacks via DNS or custom UDP. These signatures can be
short enough to live in the return-path, giving the recipient the
possibility of rejection before data. Since it can go in the return-path,
it is an ideal complement to SPF and happens to solve its inherent
forwarding problem without requiring forwarders to implement SRS. The total
transaction cost (sender + recipient) for legitimate email is also
substantially lower than for an RSA scheme, so it is a win in that area as
well.
There are other ways to cryptographically authenticate besides RSA and other
PK schemes. My motive is to get people to consider these schemes, as they
have a lot of advantages, particularly when combined with SPF.
--
Seth Goodman