From: Andriy G. Tereshchenko
Sent: Wednesday, July 14, 2004 8:55 PM
[Seth Goodman]
Why? I'm paying my provider at hourly rate for their Internet
Services (read
ISP).
You misunderstand what I was saying. The example you gave
is that you
are were traveling in Singapore, your ISP is in the U.S.
and you needed
to send a message to someone in Singapore. A local ISP in Singapore
would not a accept your message, signed by DK or otherwise,
because they
have no idea who you are and you are _not_ their customer.
If they did,
they would be running an open relay and they would be quickly
blacklisted.
I use _my_ Singapore ISP smtp server to send mail to
_another_ Singapore
ISP.
Either you _do_ have an ISP in Singapore or you _don't_. From your
earlier post:
As 6.4 from domain keys note - it's can possible to use
web-mail or remote
SMTP server with AUTH.
But this is not effective to contact my USA SMTP/WWW server
if I'm currently
in Singapore and sending email to my client in Singapore.
This implies that you _don't_ have an ISP in Singapore. If that is the
case, then any ISP in Singapore that accepts your outgoing message when
you are not a customer _is_ operating an open relay. If you _do_ have a
Singapore ISP, why don't you just declare their MTA in your SPF record?
I don't see what the problem is.
Personally, I dislike DK because in order to reject during the SMTP
session, the recipient MTA has to do public key crypto after receiving
the entire message, which is doubly expensive. This makes it an
excellent DoS mechanism: send a victim loads of mail with DK signatures
that don't validate. As an attacker, it costs you next to nothing to
produce it but it costs the recipient a lot to reject it. You force the
recipient to waste their bandwidth receiving the whole message and then
you force them to waste their CPU to discover that the signature doesn't
verify. Unless you want to put crypto accelerator hardware in every MTA
(that's OK with me, I do hardware design), this approach seems to be
advertising for a DoS attack.
You can always move the verification to the MUA, but then we're back to
accepting all the garbage and silently dropping it, which we know is a
bad idea. We've already got great content filters that take less CPU
than PK crypto. We also have S/MIME and PGP for strong authentication.
I guess I don't see what DK brings to the table that we don't already
have. The main difference seems to be that the public key is in DNS
instead of the PKI, but that's not the biggest cost in doing PK crypto.
--
Seth Goodman