From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
...
First premise: Filters do not work better than 95%
All the filters proposed thus far are based on technologies that are known
to have severe limitations. That includes the Bayesian filtering approach
for which some have been claiming ridiculous 99.5% success rates with no
failures.
I'm not sure whether "the" numbers is 80%, 90%, 95%, or perhaps even
99%, but I'm sure it's not 100%. Part of the cause for the ridiculous
claims of 99.5% averages for Bayesian filters (but notably not on
official Bayesian web pages) is that someone who receives one or two
legitimate messages per week and 28 spam/day really can see better
than 99% accuracy. People who receive 100's of legitimate messages/day
will have other views.
Second Premise: False Positives Matter a LOT
A lot of interest in the JamSpam consortium comes from people who send out
lots of mail that does not get through. People like C|Net and relationsip
management companies that send out email from your bank or airline with
account status and special offers.
That went wrong in a couple of ways. People like C|Net and specifically
including C|Net have well earned reputations as senders of unsolicited,
unwanted, unasked for, irritating, commercial bulk mail. That's partly
because all big outfits will always occassionally hire an idiot that
will send some spam before being educated or fired. It's also partly
because outfits that depend on advertising are incapable of understanding
that many people *never* want unsolicited bulk advertising or any
unsolicited "sample subscriptions" to "newsletters."
The second wrong turn is that what advertisers like C|Net want don't
matter, except to the extent it affects their own behavior. The only
people with standing to complain about false positives are people who
failed to receive mail. People who failed to send can go pound sand.
As the slogan goes, "My mailbox, my rules."
Proposal: Use Filters and Authentication together
Content filters should use authentication based approaches to whitelist
known good mail from AUTHORIZED sources. PKI allows the authorization to be
quite broad. I know that AOL now has rate limiting on outbound mail so I
will take any AUTHENTICATED email from AOL, Hotmail, Yahoo, etc.
How will Hotmail and Yahoo ensure that a new user is not a spammer?
They can't afford to check identities for free accounts.
Ralsky can contact Hotmail for a new account, get his certificate signed,
and start pounding away for at least a day or two until his certificate
is revoked--provided you use some kind of on-line verification.
On the other hand, if Hotmail requires a credit card number, they can
detect Ralsky, or at least wreck the credit rating of the owner of the
credit card. However, they could to that today without Verisign's "help."
PKI has been a success in the e-commerce space. I do not know of any case
where a credit card number was stolen from a communication over the wire. If
everyone used PKI to protect the credit card numbers in storage as well
there would not be problems with theft of cc databases.
Nonsense! PKI has been a resounding failure. The fact that no credit
cards have been stolen on the net is as irrelevant as the fact that no
babies have been killed on the net. PKI has failed to do what it promised
and there is no hope that it can ever be fixed given the business model,
price points, and public opposition to government identity cards. The
Microsoft certificate story (not to mention the cert revocation story)
demonstrated the already obvious fact that $350 is at least 10X and
probably 100X too small to allow even a well intentioned organization
to ensure that the prospective holder of a certificate is who he says he is.
In the real world, all that's need to get a certificate is a check
for $150-350 and some faxes of typical business registration forms
that you assure the cert vendor really are the real things. Judging
from my investigations before I gave up and went with self-signed
certs, the commercial certificate vendors do not even try to validate
those forms or anything more than perhaps a check the email address
in whois records is plausible.
PKI for email clients has not been a big success. This has partly been
because of the unfair advertising advantage that the FBI gave to PGP. It has
also been because there has been no infrastructure for discovery of
encryption keys and because the business model has been screwed up in the
consumer space.
That's worse nonsense than the claims about credit card numbers, HTTPS,
and PKI. The business model in the commercial space is just bad because
it is the same "send us some money and we'll sign your key, but don't hold
us responsible for anything at all." The only reason that Verisign is
still selling commercial certificates is that consumers believe Verisign's
bald faced lie that the reason credit card numbers are not stolen by packet
sniffing has something to do with PKI and Microsoft's nonsense that
authentication (e.g. ActiveX) has something to do with authorization.
I believe that I address these problems with XKMS which is a DNS linked PKI.
* The PGP/X.509 Mindshare war is over
...
* The public key discovery problem is solved
XKMS is DNS linked. ...
* The fat client problem is solved
Any XKMS client can access the most sophisticated (i.e. complicated)
PKI that is in use. The complexity is managed at the XKMS service, not on
the client. So you can have full strength PKI accessible from Zaurus or your
pocketPC.
I think we could solve the marketing issues as well.
The result of that would be to cram the Internet back into the old
AOL/Genie/Compuserv fancy BBS model. You don't need the crypto frosting
to do that. All the PKI trappings do is give Verisign a piece of the
action. You might be right about the marketing issues, but I hope you're
wrong and that people will not go back to the old AOL BBS model.
I'm sorry to be so blunt about the Verisign nonsense, but
SHEESH--give us a break!
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg