Network Working Group W. Kruithof Internet-Draft Unix-AG Universitaet Hannover Expires: July 4, 2005 January 3, 2005 Spam reducing protocol draft-kruithof-spam-reducing-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 4, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A protocol is shown which is highly spamresistant and can transparently be used as an extension of the regular email protocol. Accepted emails do the sender not cost money, not accepted ones do. A central server for keeping track of money and information is needed. A protocol, in which encryption naturally appear, is shown in which you can freely distribute your emailadress without ever having to read spam, for negligable costs. Kruithof Expires July 4, 2005 [Page 1] Internet-Draft Spam reducing protocol January 2005 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Introduction and overview . . . . . . . . . . . . . . . . . 4 3. Overview of the protocol . . . . . . . . . . . . . . . . . . 5 4. Technical remarks on the protocol . . . . . . . . . . . . . 7 5. Practical problems/issues in applying the protocol . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 12 Kruithof Expires July 4, 2005 [Page 2] Internet-Draft Spam reducing protocol January 2005 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Kruithof Expires July 4, 2005 [Page 3] Internet-Draft Spam reducing protocol January 2005 2. Introduction and overview Nowadays, spam is dealt with by using white- and blacklists and spam filters. It is to be expected that the spam problem will not satisfactory be solved by these solutions. Neither is guaranteed that receivers will not get spam, nor that non-spam emails always pass the anti-spam solutions. The essence of the protocol: if a telephonenumber costs 1 euro per minute, you will not call them without a very good reason. Suppose you are in a room with 1,000 other people. Everybody is talking to you, because talking to you is free. In such a situation you are unable to effectively pick out the things that are important to you. But what if talking to you is not free? Say you charge one euro and promise to give it back if the information was important. This way, only people with important information will want to talk to you, knowing it will not cost them a penny. People with non-important information will not be bothering you, for they risk losing money. And the other way round, if a company chooses to talk to you anyway, you know they will have something interesting to say. This document proposes a spamresistant protocol that ensures that a minimum amount of spam will be sent. The second advantage is that a sender will know for sure whether the receiver has received the message. The basic principle is that a sender has to pay for getting a way of communicating via encrypted communication with the receiver. In case of accepting (more specifically: not rejecting) the message the money is booked back to the sender, if not, the money is booked to the central server company. if for example a spammer earns 0.0025 eurocent by each sent email, setting a price of 0.10 cents for your mailbox will work. Bill Gates may want to set his account to 500 euros. The protocol in this draft could just be the push developers need to implement a protocol stacked on top of the smtp/pop protocol which is spamresistant. This document will put the system to the test to see if it can cope with the requirements that such a system should meet. The draft does not go deeply into the practical issues. This makes sense, but should be seen in context. This document will also discuss some practical problems. The term 'spam' is used in this document to refer to unsolicited or unwanted email messages. This document does not attempt to define what exactly constitutes spam. Kruithof Expires July 4, 2005 [Page 4] Internet-Draft Spam reducing protocol January 2005 3. Overview of the protocol Suppose Alice wants to send an email to Bob, whose email address she knows. She can just send the email, but she wants to make sure that it will not disappear in Bob his spam folder causing the message to be forgotten or even deleted. For successful communication both Alice and Bob MUST deposit money to a (SHOULD be non-profit) company, which transfers it to virtual money. In the database of the company his server for each email address SHALL be seen how many it costs to send an email to the receiving party. This SHOULD also be done by client software. OPTIONAL is searching in the database. Alice MUST pay the amount of money that is set by Bob for downloading from the server the public key of Bob. Alice her email address MUST be associated with this public key on the server by the database. Alice SHOULD at the same time upload her public key, which is accessible by Bob if he accepts her email, and which is deleted if he rejects the email. This private-public key pair MAY be real time generated on the server and could be send encrypted to Bob if Alice pays, or the client SHOULD upload several public keys. It SHOULD also be possible to specify which amount of money could be spent per certain amount of time, otherwise virusses e.g. could initiate unwanted transactions. If Alice sends her email to Bob, this MUST be encrypted with the public key of Bob for which she paid. Bob his email client receives the email, and MUST check whether the email is encrypted. if so, his clients MUST connect to the server to get the public key, with which the email is encrypted. This SHOULD be done by matching the senders email address, otherwise Bob has to try every private key on the encrypted message. if the email address matches, a public key of Alice SHOULD also be transferred to Bob, to complete the safe communication. If the email is not encrypted, it SHALL be lead further in the 'normal' email processing (spam filters etc), which shows the transparency of the new protocol aside of the normal email protocol. Now Bob knows which private key he has to use to decrypt the email message. If not, the email can be lead further in the normal system. It still could be a normal encrypted message if no matching email address is found in the database. If the receiver does not explicitly reject the email, the cost MUST be booked back. OPTIONAL is accepting email from Alice email address n times. The connection is now established, because Alice MAY setup her client software to accept always from email addresses for which she paid to get the public key. If the receiver does not accept the message, which SHALL be done by the receiver explicitly, the money is neither booked back to the sender, neither booked to the receiver. It SHALL be booked to Kruithof Expires July 4, 2005 [Page 5] Internet-Draft Spam reducing protocol January 2005 the company his account. For each new connection (new person or new email address) a new public-key/private key pair SHOULD be generated. This is for just in case a public key of Bob gets out in the open to people who Bob does not want to know his email address. As soon as a connection is made, the used private key with each email address SHOULD be saved by client software, so that in the future the server is not needed again. In case of a 'one-time' key pair, the public key SHOULD be deleted from the server by the client or even the server. Bob can reject the email, which is why spam will not be sent. Advertisements will only be sent if the company really thinks it will gain more than they lose. Of course, this will be the case in the equilibrium situation; Bob wants his 'to pay' to stay as low as possible, but just not low enough for companies which think they can cope with the costs. In practice, Bob MAY setup an email address for which he will exclusively use the new protocol. Each email which is not encrypted MAY be bounced with a message how to send an email which will be guaranteed be delivered. Now Bob MAY freely distribute this email address in the Internet. Kruithof Expires July 4, 2005 [Page 6] Internet-Draft Spam reducing protocol January 2005 4. Technical remarks on the protocol Of course there are some technical issues that need to be dealt with in order to approve the protocol for usability. As can be logically derived, the heart of the protocol is full-proof. Using a private-public key pair in such a way can indeed take care of unwanted communication. Nevertheless there could be requirements that may damage the usability of this protocol. First of all, servers containing the databases should be globalized in order to minimize access times. This is of course not a problem in todays world. More of a problem could be the need for realtime synchronization among servers. It can not be that if one server is unavailable, the user is not able to read his email. Though the same can happen with your pop-server, the real problem lies in sending emails. It MUST NOT happen that, due to the need of knowing the costs of sending, an email can not be sent because a server is down. Therefore there MUST always be a complete functional server available. Secondly the weakness that can cause money to get lost. If a server is compromised accounts can be altered causing money to be lost. As a problem that happens once or twice this is moretheless acceptable. But if even the design of the protocol does not satisfactory handles this problem the protocol will not stand and its standard will not hold. A possible sollution can be found in the sollution of the first problem; multiple servers that are realtime synchronized. If an attack or system crash causes an account to be altered by in a non-regular way, the realtime synchronisation can be used as a fault masking voter using majority vote. This is widely used in hardware to mask errors that occur due to unforseen and unpredictable errors that are simply there in nature, making it reliable enough to cope with a hacker compromising a system. As email is a massively used tool this might not be practical considering traffic and cpu intensitivity of a majority voting system. On the other hand, the system is only used in iniating connections, not handling the email traffic itself. More research is needed at this point, but at least this shows that the weakness of moneyloss can be solved. Thirdly there is the issue of hackers. If a system prevents spam from being spread and also handles a lot of money, there is the all-time great risk of hackers. The entire spam community could go after the creditmailservers. This means that high precautions need to be taken and that the security of such systems SHOULD equal the securitylevel of online banking. Kruithof Expires July 4, 2005 [Page 7] Internet-Draft Spam reducing protocol January 2005 5. Practical problems/issues in applying the protocol The solution of massive mailinglists etc. can of course be found in the regular email protocol. These companies could require that the emailaddress you want your mail on, also accepts unencrypted messages. Because money is used as factor to decide whether a commucation channel is initiated or not, problems may arise in the equilibrium state considering different countries. The payment SHOULD require to pay an equivalent in dollars or euros. Because of the differences in GNP (Gross National Product) this could lead to (dis)advantages in different countries. An interesting effect may be the advertisement business, which will be sent even though the sender has to pay for example 10 eurocents. The receiver than knows, that the content may be interesting for him. So, it is possible to receive paid advertisment. Kruithof Expires July 4, 2005 [Page 8] Internet-Draft Spam reducing protocol January 2005 6. Conclusion The protocol as such is a simple, flexible and effective way of minimizing spam in a very natural way. Nonetheless, a lot of research has to be done in the field of economics and in how easy it is to implement. Maybe this protocol will eventually just be used in businesses. After all, they are the ones in most desperate need of getting rid of spam. Kruithof Expires July 4, 2005 [Page 9] Internet-Draft Spam reducing protocol January 2005 7. Security Considerations This section handles the case a server has been compromised and why various SHOULDs lead to a system in which also compromising of this server does not affect all the communication, it only requires the resetting of the communication channels. The weakness is the possibility of loosing money if the server is compromised. Essential is the central server, which is used for keeping track of the virtual money. Public-private keys SHOULD be generated by the clients, because it avoids generating 'bad keys' in case of errors/misuse of the server software. One-time key-pairs SHOULD be used, because if Alice accidentally or intentionally leaks the key to someone else, Bob can delete this key-pair. Also SHOULD the key-pair be generated by the client, so that only the client has the private key. This avoids when the server is compromised the spread of private keys to the public. The public key SHOULD be in case of One-time-key-pair be deleted on the server if Alice has paid for the key. Than a compromised server cannot spread this public key anymore. If it is discovered that the server is compromised, in case of all the SHOULDs in this section are followed, the communication channel can be reset by sending to each connection a new public key, with encrypting with the old key. This communication cannot be read in each case, and after establishing the new connection, all the old keys, which MAY be in the hands of third parties, MUST thrown away. The weakness which is left is the book keeping data server. In case of compromising this part, money can be lost. Kruithof Expires July 4, 2005 [Page 10] Internet-Draft Spam reducing protocol January 2005 8. Acknowledgments The author would like to thank several people for many helpful comments and suggestions, including Anne Franssens (University of Twente, NL, Computer Science). 9 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Wilbert Kruithof Unix AG Universitaet Hannover Welfengarten 1 30167 Hannover Germany Phone: +495 11 7623226 EMail: wilbert@stud.uni-hannover.de Kruithof Expires July 4, 2005 [Page 11] Internet-Draft Spam reducing protocol January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kruithof Expires July 4, 2005 [Page 12]