AMTP as an Alternative to SMTP
SamMichaels writes "AMTP was published as an Internet Draft last week. It suggests using a 'Mail Policy Code' during the transaction to identify what kind of mail is being sent (administrative, personal, commercial, etc). Another plus is the use of TLS using x.509 certificates signed by a CA so you know exactly where the mail came from. Sounds like a solid plan...now to get a certificate signed for a decent price is the challenge."
does it involve the Evil Bit ?
But in general end to end security models like this have had trouble because it has not been possible to get central signing in a way that can be administrated cheaply enough to allow wide deployment. I fear that this will fester in the same acceptance purgatory as DNSSEC, for roughly the same reasons
Now, viruses browse your contact list and send a message to everyone in the list. If this breaks through, the viruses will browse your contact list, and send a message to everyone in the list using the key, something which Outlook will probably do automatically.
Oh, yes, there is one difference. The CA will get lots of profit for selling certificates.
A new 4 point plan for SPAM:
1. Hijack domain
2. Get CA to issue cert
3. Spam (or ?????)
4. Profit???
People who routinely hijack entire netblocks to send SPAM are not going to be bothered by providing fraudulent credentials to a CA.
Simply put, it isn't.
If you actually had red the draft, especially section 3 you would have seen that it is in essence smtp enhaced by tls:
3. The AMTP Model
Authenticated Mail Transfer Protocol (AMTP) is based upon Simple Mail
Transfer Protocol (SMTP, [RFC2821]) and addresses the twin problems
of authentication and codification. AMTP uses Transport Layer
Security (TLS, [RFC2246]) to create an environment of trust between
Mail Transfer Agents (MTAs) involved in a transaction. MTAs then
exchange Mail Policy Codes (MPCs) to establish permission for mail
delivery.
AMTP inherits the specification of SMTP and builds upon it. This
document specifies only the changes to SMTP and therefore implicitly
incorporates the latest SMTP specification [RFC2821] except where
indicated.
So RTF!
This draft fails to provide any significant advance over SMTP. The use of TLS and authentication between MTAs merely provides a mechanism to identify policy violators. It does not (as the draft recognises) prevent fraud against a CA, it does not address the problem of distributing certificate revocations, it opens the door to a new era of DoS attacks against CA services (which will likely be far less robust than the DNS system), increases the barrier to entry for the ISP market (with costs being passed on to consumers, of course), and the opportunity for politically based service interrupts (like we already see with SPAM black lists) is just plain scary.
Further to the last point: ISPs are generally forced to react to SPAM rather than be proactive (it is generally impossible for an ISP to distinguish between UBE and opt-in lists). This means that spammers will always be one step ahead, and any network with enough bullying power can summarily demand the revocation of another ISP's certificate for policy violations. An entirely new class of disputes will arise, making SPAM black listing arguments seem tame.
The additional responsibilities this draft places on end users is also unacceptable. You will have to remember to flag your message "commercial" or "personal" and whether the distribution is "individual" or "customer". And of course is someone complains about the classification you could end up having your service terminates, so that the ISP can prove it took appropriate action against the "abuse".
We have to accept that it is a fact that we cannot get away from SPAM. The postal and Internet mail systems rely on the opportunity to send a message to any recipient. Implementing a client side PKI-based whitelist for mail would be trivial (and many people do this), but destructive to the communication medium. The object is not to get away from SPAM, but to ensure that we, as recipients, do not bear the cost of SPAM.
Any system that filters messages at your mailbox, or your ISP's server, costs you money. Your bandwidth and your ISP's bandwidth are wasted. AMTP may reduce this, but adds other hidden costs like a certified key and probably the ongoing maintenance of good relations with many peer MTAs to avoid accusations of abuse.
Anyone interested in alternatives to the SMTP system should take a look at D. J. Bernstein's Internet Mail 2000 ideas; in brief, the sender holds the message in his/her mailbox and make his/her bandwidth available to allow the mail to be downloaded by the recipient (who can obviously choose not to download it).
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I'm company A.com, and I buy a certificate (or get one for free from some free-sign authority). I use it completely legitamately. Only for receipts to paying customers, and to deliver "timely updates" for their software or whatever.
Now I fall on hard times. And go broke.
In the liquidation proceedings, a spammer swoops down and buys my certificate. It's a valued commodity to him, and the courts, I don't believe, are not going to care about the nefarious purposes he may have in mind.
But now lots of people are getting spam in my name.
So, would the CA have the power to "ungrant" the certificate, and therefore also be able to hold thousands of companies hostage. (Imagine starting as a 'free' service, and then suddenly 'changing your policy'.)
Or will the clients at the end have to say that certain CA's aren't valid. If so, how is this different form white-list/black-list.
Now, anything that tries to fight spam I am for. However, I believe the number one thing needed is accountability. If someone sends me mail, I need to be able to reach out and touch them, with a phone number or anything else I feel like. And the latest round of email viruses wouldn't work if I couldn't fake the address it was being sent from.
I demand a million helicopters and a DOLLAR!
If you sign your own certificate, you don't have the level of trust as getting a cert from CACert.org.
3
CACert works on a point system for the level of trust. You must provide proof of your identity to other people that vouch for you - either with legal documentation (depending on the country/legal jurisdiction that you reside in) or inherited trust from another CA - or even from PGP/GPG.
CACert is currently working on getting its root certificate included with browser distributions, such as Mozilla.
To vote, go here: http://bugzilla.mozilla.org/show_bug.cgi?id=21524
If you need to register on Bugzilla first, go here: http://bugzilla.mozilla.org/createaccount.cgi
Certificates can be created for businesses and persons, unlike from most (all?) other certificate providers.
It's always darkest before