spf-discuss
[Top] [All Lists]

Re: Attacking Domain Keys

2004-11-29 12:49:05

On Nov 29, 2004, at 2:36 PM, Seth Goodman wrote:
From: George Schlossnagle
Sent: Friday, November 26, 2004 9:48 AM
On Nov 26, 2004, at 10:35 AM, James Couzens wrote:

On Fri, 2004-11-26 at 10:16 -0500, George Schlossnagle wrote:


So err, whats the point of DK then?

It's an authentication system - like SPF is.  It doesn't tell you
anything about the quality of the sender, just like SPF doesn't. And
it isn't designed to be a computational penalty. Look at hashcash,
penny black or something of that ilk if you want to purposefully
incorporate computational cost into SMTP.

So DK is expensive

It's not.  Go back and read my messages.

It is.  Go back and read Sendmail's data.  They showed that for short
messages, like spam, the throughput of Sendmail was reduced to about half. That is significant. And these were people who were trying hard to make it
look good.

I don't need to read sendmail's data. We have our own implementation and we do not see a two-fold slow down based on the size of the message. You always apply asymmetric encryption to the same size buffer. You don't sign the message, or a canonicalization of the message, you sign a digest of a canonicalization of the message. So, the only price that varies based on message size is the cost of canonicalization and message digestion. Canonicalization is order(n) -- about 100 thousand messages per second (which is clearly not a bottleneck). This leaves only SHA1 which is damn fast and can easily be accelerated with hardware if you are one of the few people in the world that would have this become a bottleneck.

In our tests, almost all of the time spent is spent waiting for DNS resolution. SPF suffers from this more so than DK. And SPF on a rather large scale has not shown to be a problem.

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth


<Prev in Thread] Current Thread [Next in Thread>