From: Theo Schlossnagle
Sent: Friday, November 26, 2004 9:58 AM
<...>
DK is as expensive as SPF in my eyes. SPF requires several DNS requests
and is victim to DoS attacks in that respect as well (just capping the
time or count doesn't prevent that well). So, as processors will
certainly get faster tomorrow, latency will not change. Half dozen of
one, six of the other.
As processors get faster over time, so does the mail volume to process.
High overhead is still bad.
You won't get any argument from me that SPF has the potential to abuse DNS.
Wayne has brought up that issue repeatedly and his warnings have fallen
largely on deaf ears. FWIW, I suspect there are rational ways to deal with
that problem, though I am no DNS expert.
SPF and DK are authentication technologies. One handles RFC2821 and the
other 2822. DK adds to that the preservation of message integrity.
They are different, but will go along with the "they have the same
value" mentality. But, as they tackle different problem scopes, the
benefit of their value aggregates.
I really don't get your argument. pre-data rejection would be done by
technologies like SPF. Dk has value on top of that.
SPF has limited ability to reject forgeries as long as it relies on SRS to
do forwarding. There is no way to detect a forged forward with an SRS
return-path, so that is predictably what forgers will do if SPF is widely
adopted. If you want to reject forgeries before data, you need something
other than SPF+SRS.
<...>
DK takes about 4ms to validate. YMMV. I'm a computer scientist, so
when I say order of magnitude, I mean <<1. And yes, SA is dramatically
more expensive than DK -- if SA slipped in DK tests, no one would even
notice a slowdown.
I'm glad that someone else has the guts to state this figure publicly. When
I tried to bring this up on MAILSIG, I was summarily run out of town. Most
MTA's do not have the throughput of your products and that is the context in
which we have to look at DK. Four milliseconds per message is a lot of CPU
for most MTA's.
If you can reduce your load for SpamAssassin dramatically, then the cost of
authentication is still important for total throughput. If the
authentication technology you are using does not reduce the need to run
SpamAssassin significantly, you really need to question why you are doing
it.
<...>
Again using "we" too loosely. You may have enough crap. I certainly
have too much crap. I am looking for things that are concise, simple
and work. DK is that. And, as this message is DK signed and I didn't
burden you with cryptographic responsibility, I don't see how you
argument holds water. DK is both transparent to the end user and does
not require participation.
Except that if a recipient implements it, all mailing list traffic from
lists that are not DK-aware will fail authentication on every DK-signed
post. That is hardly transparent.
If you choose not to sign messages, fine.
Technical considerations are often trumped by politics. If Yahoo requires
this on incoming messages, you have little choice, no matter how bad the
idea.
If you choose not to validate them, fine. Just like SPF, there is no
obligation to participate.
Except when there is.
--
Seth Goodman