EMAIL SENDER AUTHENTICATION DEVELOPMENT AND DEPLOYMENT (PROJECT CHEESEPLATE) Volume I Technical and Management Proposal pobox.com IC Group, Inc. [email protected] v1.01 20041217 Full Proposal Control Number EB8A Email Sender Authentication OFFICIAL TRANSMITTAL LETTER IC Group, Inc., a New York State corporation, doing business as pobox.com, respectfully submits a proposal in response to solicitation BAA04-17 for Cyber Security Research and Development. It is submitted under Category 3, Technical Topic Area 7, Technologies to Defend Against Identity Theft, for consideration as a Type II Prototype Technology. Solicitation Title: BAA 04-17 Topic Title: Technologies to Defend Against Identity Theft Type Title: Type II (Prototype Technologies) Full Proposal Control Number: EB8A Proposal Title: Email Sender Authentication A companion proposal, Reputation System Clearinghouse (1RGT), is also being submitted under the same category and type. We request that these two proposals be read together. This proposal should be read first. This proposal was authored by Meng Weng Wong, Founder and Chief Technology Officer for Special Projects. He can be contacted at [email protected]. Meng Weng Wong IC Group, Inc. 1100 Vine St Ste C8 Philadelphia, PA 19107 December 15th 2004 EIN: 113236046 Central Contractor Registration: 3EKUCT Email Sender Authentication 2 EXECUTIVE SUMMARY Pobox.com aims to fight phishing by adding sender authentication “Phishing” is a class of high-tech scam that functionality to the Internet email system. First we will build a library uses fraudulent e-mail to deceive consum- ers into visiting fake replicas of familiar to implement a useful set of recently devised anti-forgery specifica- Web sites and disclosing their credit card tions, including ip-based approaches such as SPF and crypto-based numbers, bank account information, Social approaches such as DomainKeys. The library will also be able to Security numbers, passwords and other sensitive information. – BAA04-17 query arbitrary third party reputation and accreditation services. It will be constructed as a reference implementation and documented as a standard. Then we will integrate that library into the Mail Trans- fer Agents (MTAs) which carry the bulk of the Internet's email. At the end of the project, it will be possible for most mail systems to simply upgrade their MTAs. After upgrading, systems can “flip a switch” and automatically recognize, block, or flag suspected spam and phishing emails. This meets the requirements of tta 7. In this system, receivers of email will enjoy protection from iden- tity theft and phishing. They will have the option to easily block obvious forgeries. They will also have the option to flag mail which does not pass some form of authentication, or which does not meet minimum standards of reputation. These capabilities do not exist today in a non-proprietary, non-commercial form suitable for fast free widespread adoption. This project creates these capabilities and introduces them to the email system. The project will last approximately eighteen months. The bulk of the money will go toward paying programmers to write software and plug it into popular MTAs both commercial and opensource. The project will be managed by the team who produced the successful SPF specification and software development effort. Software produced by the project will be as free as is practical. Li- censing will work according to generally accepted opensource prac- tices. Participation in the antiforgery system will be voluntary and free of external costs for both senders and receivers. Most of these benefits will not require end-user involvement. Software deployment will rely on trained system administration pro- fessionals. Portions that do affect end-users are designed to be as simple as possible and no simpler – at about the level of complexity of the web browser padlock icon. To achieve these goals, we seek a grant between us50,000 and us750,000. The base level of funding covers the development of the core library. Higher levels of funding will allow us to upgrade more software to use that library. Email Sender Authentication Performance Goals 3 PERFORMANCE GOALS The ultimate goal of this project is to change the way Internet email works. This ambition deserves explanation. When email was invented, abuse considerations were secondary to functionality. The ability to get mail from random strangers was considered a primary virtue. Today, spam outnumbers non-spam email (ham). In the absence of filtering, messages from strangers are now, more likely than not, spam. This position may be regrettable but it reflects reality. It calls for a new paradigm of email. While content filtering has proven effective in the past, it is unsat- isfactory in a number of fundamental ways. The first generation of antispam technologies filtered out bad messages based on what they contained. The next generation of antispam technologies will filter in good messages based on who sent them. Sender authentication is now generally considered essential to See remarks by the FTC in the Federal Register, fight phishing, spam, worms, viruses, and other forms of online mes- http://www.ftc.gov/opa/2004/09/emailauth.htm saging abuse. Authentication technologies, when widely deployed Reputation systems are described in the accom- and used in conjunction with reputation systems, promise to make a panying proposal, Reputation System Clearing- house. permanent contribution to the antispam and antiphishing effort. Under the new paradigm, email receivers use authentication tech- nologies to tell if the senders and authors of messages really are who they say they are (spoof detection). Then receivers use reputation technologies to check if those senders are recognized or not (stranger detection). Receivers can use these technologies together in service of policy: if a message is authenticated and recognized, then it is not spoofed and not from a stranger. Receivers can opt to treat the mes- sage positively. If the sender is not authenticated or not reputable, then the message is from a stranger. It may contain undesirable con- tent, and receivers can opt to treat the message negatively. (The cri- teria used for determining “strangerness”, and how positive and neg- ative dispositions are handled, are locally determined by individual end-users and receiver systems.) Receivers can use these technolo- gies and apply these policies to automatically screen out unwanted messages, including phishing attempts and traditional spam. The proposed project uses the above approach to meet the goals specified in tta 7. The project will implement a collection of authentication and reputation technologies and deploy them across a wide variety of software programs that make up the Internet email system. THE NEED FOR A COORDINATED ROLLOUT History shows that if we leave industry to its own devices, rollout Email Sender Authentication Performance Goals 4 may occur in a slow, haphazard, and “every man for himself” fash- ion. Such a rollout could threaten the integrity of the email system. Furthermore, some MTA offerings, particularly opensource prod- ucts, may lack the resources to implement the desired improvements in a timely fashion. If we coordinate the rollout, we can ensure that implementations meet a minimum standard of quality; we can test interoperability; and we can set a rough schedule for deployment. After a receiver site implements sender authentication, and after Government domains are also expected to a useful fraction of sending sites emit authenticated messages, it will participate in sender authentication to protect themselves from receiving spoofs and from be- become significantly easier for end-users to recognize phishing at- ing spoofed. tempts, and for machines to automatically block them altogether. The bulk of these technologies are intended to occur at the core of the email system and will be deployed by trained system administra- tion professionals. Some user-visible changes to Mail User Agent (MUA) software are, however, unavoidable; they add an element to the MUA user experience roughly comparable to the padlock icon in web browsers. THE NEED FOR FUNDING To end spam and phishing, the email system must evolve. Free and open standards must form the basis for this evolution because email is too important to be owned or controlled by anyone. The single most widespread and successful such standard is SPF. In twelve months SPF has grown to cover approximately 20% of all Internet email. During that time, however, the project received only Nathaniel Borenstein, Distinguished Engineer about 3,000 in donations. This has not been enough to pay pro- at IBM and author of the MIME specification, has counted at least thirty-one consortia grammers, so people who work on SPF do so in their spare time. chartered to fight spam. Many of them have The world seems to want a final solution to spam very badly, but budgets in the millions of dollars. Many of it doesn’t seem to want to spend much to get it. At the same time, them have held expensive conferences to discuss the spam problem. None of them, it seems quite happy to spend billions of dollars treating the symp- to my knowledge, have allocated resources toms. towards actually writing any antispam code. Money spent on treating symptoms: $3,000,000,000. Experts estimate direct losses from phishing at Money given to curing the disease: $3,000. anywhere from $150 million to $500 million. http://news.zdnet.co.uk/internet/security/ 0,39020375,39175678,00.htm Yes: the most successful project to end a worldwide scourge is More broadly, what does spam cost the being run on a budget of 3,000 by hobbyists working nights and economy? It depends who you ask. Ferris Research estimated a loss of $11.4 billion in weekends. Imagine how much better they could do if only they had 2002. Other experts say that number is bogus. a little more time and money. But it’s obvious that enterprises and ISPs spend With proper funding, programmers could devote more time to millions to handle spam volume – millions that could be better spent elsewhere, or not spent the project.