On 6 Mar 2004 at 8:08, Vernon Schryver
<vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> spoke, thus:
From: "Sabahattin Gucukoglu"
...
and important catch in this proposal, that being a modification to all
MUAs and MTAs to allow the acceptance and carrying of a password token
which should persist throughout the entire mail delivery, ...
My proposal is a scheme for anti-forgery, which makes use of a non-blank
token, or password, which can be verified by a recipient system ...
How does your scheme prevent forgery better than SMTP-AUTH, SMTP-TLS,
S/MIME, or PGP? Most MTAs support SMTP-AUTH and SMTP-TLS.
That should, you're right, be "Sender forgery". SMTP Auth is not carried
from host to host and only guarantees some privileged user his rights,
such as relaying or submission, during any given transaction; it doesn't
permit an end-to-end verification of sender across multiple hosts,
necessary for normal mail delivery. It doesn't (or shouldn't) prevent any
mail from being delivered at all to a domain if the destination host is an
MX for that particular domain, regardless of any details of the mail.
There are issues concerning today's worms/viruses that make port 25-
blockage on all but the local smarthost more plausible and reasonable,
too, and the submission port won't take long to follow when the next gen
of worms flood the net. I don't like it, y'know, but I'm ready to *grrrr*
face it. It is, in summary, useless as a measure against sender forgery
in short term, and I'm ready to bet long term as well, despite having its
real uses as a trusted submitter/relay-permitted client authentication
method. Good security practice to keep hackers from hopping your firewall
and trying to relay through your system from a local vantage. PGP is
strictly per-user, and isn't practical for mail delivery. Use of it for
quality spam detection to any useful worth is akin to whitelisting, and
PKI infrastructures and corporation-determined trust are a point of
weakness (as you say, below). Same for StartTLS and S/MIME, even if TLS
*were* encouraged to global use. If any of these were at all useful, they
would either need to be updated and/or used and deployed almost
immediately, which is obviously impractical. At least this means holds as
much configuration and balanced (and uncontrolled) distribution as DNS
itself, not to mention gentle backward compatibility.
The difficulties in preventing spam sender forgery are not in defining
token protocols but in
- defining forgery in a way that excludes common, legitimate practices.
This proposal attempts exactly that! Other proposals we've seen all
depend on administrative configuration which predetermines some particular
aspect of mail delivery, i.e. IP addresses from which any given mail
should emerge for a particular domain, all of which harm - as you say -
legitimate transactions. This scheme leaves that choice to the user.
Admins simply maintain a list of user-chosen passwords, and it is the user
who, by providing the correct password to his MUA when submitting mail
through his work's MTA under his Hotmail address, guarantees its delivery
when, at the other end, the user's password (not his domain name, not his
IP address) is verified against the same password at the user's home
domain - Hotmail - by a query from his mate's MTA a moment later.
Why isn't sending mail with your Hotmail account as sender while
sitting at your desk at work or with your work sender address while in
a customer site, hotel room, or airplane "forgery" that would be
prevented by the proposed sender-verifying mechanism?
Again: only the password is verified! Forgery is now dependent only upon
the misuse of the password. The administration of the domain referenced
in the envelope sender is now soley responsible for any of its spamming
users, case by case, and there is no opportunity for a domain to be
misrepresented provided those passwords are the cause of the mail's
acceptance. That is the whole point! I *do* hope you read my entire
message ... but let's suppose you didn't. If you are suggesting that all
those things really *are* forgery, then I'm afraid I'm addressing the
wrong person for comments. I'm going to suppose - to hope - that you
don't. I appreciate your need for good sense and conservatism, all the
while encouraging good and useful inovations in SMTP, and I'm trying hard
to strike that balance. The sacrifice, and there always is one, is an
additional piece of user information, a token. Only difference between
that and the SPF is that the token is supplied by a user, not an
administrator, and goes wherever the user goes. I believe in the use of
TLS for security, in SASL for avoiding problems with IPV4 (spammers
hopping ACLs to get relaying permission), for guaranteeing relaying when
you need it in the car on the way to visit Auntie Jane, or whatever. I
don't, though, believe in sitting at a local cafe in mexico and using my
home MTA just to send out a bit of mail to the local hotel, particularly
when my MTA sits here in the north of London, England! If you agree that
this last situation is in fact plausible, then you are not being
conservative.
- key distribution.
Verisign/Microsoft would be happy become the toll collecter for
all Internet mail using the current or a variation of the current
commercial PKI. Some of us are not keen on that idea. All other
key distribution mechansims have their own substantial problems,
including those that would use the DNS.
No, I wouldn't be happy with such corporation or government-run trust,
either. This is a problem of cryptographic PKIs, yes. Even now, the
situation is troubling, with Key Escro possibly being the largest threat.
As for the substantial problems inherent in other systems of key
distribution, I'm interested in hearing the problems specific to mine. :-)
This "Key distribution" is nothing more than a database or other simple
client-server query made by a destination system. It is limited to sender
forgery only - nothing less, nothing more. It depends on getting a yes/no
answer from the domain owner's database in response to a password, all the
while ensuring that the database itself is not available for public
(internet) viewing. Keys are not even distributed, there is no trust
relationship, no guy in charge. DNS holds only information about reaching
such a database, both the DNS record and the database being under the
jurisdiction - presumably - of the domain holder, if the database even
exists.
- preventing spammers from buying as many tokens as they need.
The major spammer that currently calls itself Zhang Jun and Qing
Zhang has been burning several new domain names per day for the
last 2 or 3 months. Why won't it be able to make or buy tokens
to go with each of its domain names? Why won't domain2004.com,
managernic.com, namelite.com, nicsimple.com, sitesadmin.com, and
the rest of its DNS servers serve its SPF RRs or your password
tokens as readily as they serve NS, MX, and A RRs? Why can't it
replace those DNS servers as they become recognized with new DNS
servers, as it has been doing for years?
You're right. This specification does nothing to address such a problem.
Remember, though, that it was a mark of progress in spammer tactics when
they stopped using non-existent domain names, all of which could be
readily identified by a simple DNS query, and started using legitimate
ones. This proposal does nothing to stop people from using legitimate
domains under their own power to spam with, or even domains under someone
elses' power if that domain chooses to support spammers or be negligent of
them. Still, a lot of mail comes from domain names - legitimate, non-
spamming domain names - whose systems were not used to deliver spam
purporting to come from those domains, and whose administrators are very
definite about their anti-spam policy - "No spam here". I'm pretty sure
the effect of this sort of specification would make our desires felt, and
a noticeable impact on our inboxes, just as SPF should. Having said all
that, this specification ensures that the only people sending from a
domain are those in authority to do so, whether truely or maliciously, so
the envelope sender of a spam suddenly becomes music to the ears of a spam
fighter and, thencefrom, a good solid RHSBL. The only kind of domain who
would then suffer would be careless or uninterested domains, whose
reputations tell their fate.
1. Sender MUA submits message through some host X, indicating token to X
using the stok extension to be defined in SMTP as an extention to its
"mail from:" command: mail from:<someone(_at_)example(_dot_)org> stok=blorb
...
4. MX begins a password query. It must connect to some kind of password
query resource. The MX may connect to a designated MTA for a domain and
use the stok keyword to query for a password (>>"stok blorb" <<"250 Token
is tasty!") or some other simplified database query. ...
5. Authenticated submitters are welcome, unauthenticated submitters
aren't, policy-dependent. ...
Have you looked at SMTP-AUTH?
Yes. See above. If you are the guy I should be talking to, then you'll
see at once why this isn't good enough. If you aren't, then you probably
do see it as sufficient, almost in self-contradiction. Are you the guy?
What about SMTP-TLS with verified certs required?
Yes. See above. PKI = bad. Also, I've seen more than enough bad
implementations of this specification which, after a failed handshake of
TLS caused purely by - say - the CA certificate of the sending MTA's cert
not being in the list of the recipient as in self-signature for local
benefit, would break and fail to consider a non-secure transaction for
continuing the session. Thanks, but no thanks.
I hope you won't be too offended if someone points out
http://www.rhyolite.com/anti-spam/you-might-be.html
Not at all. Read it already. Probably responsible for the very first
line in my original message. You did read that, didn't you? :-)
I wrote it during the first months of the ASRG mailing list.
Hmmm. I can see that now. It all makes sense.
Cheers,
Sabahattin
--
Thought for the day:
Intuition (n): an uncanny sixth sense which tells people
that they are right, whether they are or not.
Latest PGP Public key blocks? Send any mail to:
<PGPPublicKey(_at_)sabahattin-gucukoglu(_dot_)com>
Sabahattin Gucukoglu
Phone: +44 (0)20 7,502-1615
Mobile: +44 (0)7986 053399
http://www.sabahattin-gucukoglu.com/
Email/MSN: <mail(_at_)Sabahattin-Gucukoglu(_dot_)com>