Network Working Group W. Kruithof Internet-Draft Unix-AG Universitaet Hannover Expires: July 8, 2005 January 7, 2005 Spam reducing protocol draft-kruithof-spam-reducing-03.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 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A highly spam resistant protocol is shown, which could be implemented for negligible costs. Accepted email's do the sender not cost money, not accepted ones do. A decentralized server for keeping track of money and information is needed. The protocol, in which encryption naturally appears and can be used transparently aside of the existing mail protocol, allows to freely distribute your emailadress. The protocol avoids the micro payment problem. Kruithof Expires July 8, 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 . . . . . . . . . . . . . . . . . . . 6 4. Technical remarks on the protocol . . . . . . . . . . . . . . 9 5. Practical problems/issues in applying the protocol . . . . . . 10 6. Financial aspects . . . . . . . . . . . . . . . . . . . . . . 11 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Kruithof Expires July 8, 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]. The key word "ELEMENT" means element of, "ORG" means organization, "AND", "IF", "THAN", "REQUEST(S)", "COST", "ACCEPT", "REJECT", "BY", and "CONNECT" stand for their logic meaning. The key word "GETKEY" means download the key, "TIMEOUT" a specified time value. The term "COMPANY(IES)" is used for a ISP which is ELEMENT ORG. The organization means agreement on the practical implementation of the protocol, and should decide whether certain COMPANIES fulfill the conditions. Kruithof Expires July 8, 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 email's always pass the anti-spam solutions. The essence of the proposed protocol: if a telephone number costs one euro per minute, you will not call them without a very good reason. Suppose you are in a room with thousand 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, and someone has to show good faith? 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. This document proposes a spam resistant protocol that ensures that a minimum amount of spam will be read by the receiver. 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 server of the 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 euro. As a remark, the micro payment problem, usually found in epostage, is avoided by spreading the accounting of data on a decentralized server, which could be in practice a piece of additional software run on the normal SMTP server. Only users of mailboxes who pay (in)directly can use the service. Misuse by other people/viruses is reduced by introducing hard and soft limits on using the deposit. Most disadvantages found in epostage are shown to disappear for the proposed protocol. 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 spam resistant. 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 implementation, but shows the theoretical foundation. This makes sense, but should be seen in context. This document will also discuss some practical problems. Kruithof Expires July 8, 2005 [Page 4] Internet-Draft Spam reducing protocol January 2005 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 8, 2005 [Page 5] 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 directly. For successful communication both Alice and Bob MUST have a (in)directly paid email account. The large ISP's MUST work together to make use of this protocol. In the database of each participating COMPANY for each email address of that COMPANY 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 upload before her public key, which is accessible by Bob if he accepts her email, and which is not accessible 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 hard (changed by sending a letter to the COMPANY) and soft (software changeable) limits, otherwise viruses e.g. could initiate unwanted transactions. The protocol can be an extension to the normal SMTP protocol. Suppose Alice has the mail address alice@alice.com, Bob has bob@bob.com. Now the ISP's has to be in the organization which have an agreement about the specified mail protocol, and also apply it to their mail servers. Both Alice and Bob need to have a paid mail account, directly or indirectly. Indirectly by for example hiring an ADSL line. The financial part will be discussed later on. Now Alice wants to send a mail to Bob, via the new protocol. Alice's client authenticated connects over an encrypted connection to the mail server, which checks first: alice ELEMENT ORG, and sends IF bob.com ELEMENT ORG AND IF bob@bob.com ELEMENT THAN REQUEST COST bob@bob.com and saves this cost in costbob. Alice.com caches this value, costbob also, and denies all request from alice handling Bob if Alice has not enough deposit, or zero deposit (the cost has always to be greater than a fixed value, which is specified in the protocol and changes with the year to correct for inflation), to pay the key of Bob for a fixed time (TIMEOUT value). Alice can read now in her mail client, before composing the message how many it costs. She writes her email, now her client sends again: IF bob.com ELEMENT ORG AND IF bob@bob.com ELEMENT AND COST bob@bob.com EQUAL costbob THAN GETKEY bob@bob.com. Now alice.com connects to bob.com, downloads the key to alice.com, and delivers it to alice. Alice.com now saves costbob. Kruithof Expires July 8, 2005 [Page 6] Internet-Draft Spam reducing protocol January 2005 Now, and this is the weakness for which the organization is needed, alice.com MUST book off costbob on alice deposit at alice.com. In the protocol, as seen, a delay (the same TIMEOUT which is mentioned before) is needed between paying a key and the right to pay for his key, because Bob could have changed his value in the meantime. Now the receiving part. Bob's client connects over an encrypted connection authenticated to the mail server, which checks first: bob ELEMENT ORG, downloads the list of connections of bob. Now the client downloads the email's. If the connection is accepted, the email is always put through. If a new connection occurs, the mail is put through with a flag of new connection. If Bob accepts/reject the message, bob's client connects again: ACCEPT alice@alice.com. The server checks: IF alice ELEMENT ORG AND IF bob ELEMENT ORG AND IF bob REQUESTS THAN CONNECT bob.com, requests: ACCEPT/REJECT alice@alice.com BY bob@bob.com. Bob.com now checks: IF alice ELEMENT ORG AND IF bob ELEMENT ORG THAN ACCEPT/REJECT costbob. 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 encrypted emails 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 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, Kruithof Expires July 8, 2005 [Page 7] Internet-Draft Spam reducing protocol January 2005 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 (in the sense of coming through anti-spam solutions). Now Bob MAY freely distribute this email address in the Internet. Kruithof Expires July 8, 2005 [Page 8] 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 email's. 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 solution 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 synchronization can be used as a fault masking voter using majority vote. This is widely used in hardware to mask errors that occur due to unforeseen 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 initiating connections, not handling the email traffic itself. More research is needed at this point, but at least this shows that the weakness of money loss 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 creditmail servers. Kruithof Expires July 8, 2005 [Page 9] 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 email address you want your mail on, also accepts unencrypted messages. Because money is used as factor to decide whether a communication 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 euro. 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 (changeable) paid advertisement. Kruithof Expires July 8, 2005 [Page 10] Internet-Draft Spam reducing protocol January 2005 6. Financial aspects An indication how the financial part of the protocol would look like. It has to be clear, that only email accounts which have a connection with money/control on the user can be used in the protocol. In practice, all COMPANIES could for example give standard 10 euro credit per month to customers, who hire an (A)DSL line and get a emailaccount 'for free'. But also accept universities in ORG, if they give the same amount of money per month to their university students. If they want more credit, they could buy more from their COMPANY or university. This is just an example, that it has to be possible to find a nice solution to this problem, which has to be economically researched. As encrypting software for example PGP (GPG) could be used. It should be financially possible to realize the introduction of an additional piece of server software for SMTP servers. If the protocol is studied, it can be expected that the overhead on the servers will not be that much. An increasing amount of spam is more expensive probable. Kruithof Expires July 8, 2005 [Page 11] Internet-Draft Spam reducing protocol January 2005 7. 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 8, 2005 [Page 12] Internet-Draft Spam reducing protocol January 2005 8. 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 database of each COMPANY, 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. Following the protocol, in case of receiving the mail from the mail server by the receiver, the mail address of the sender is earlier known, than the message is arriving, because the public key has to be downloaded, and than the mail address is known to the server. Access to the central server is decrease dramatically if the receiver first downloads from the server the list of emailadresses which have paid to get one public key of him. The client SHOULD download first the list of known connection, and later on check whether new connections are added. Then the receiver downloads the mail messages. Following the protocol, it can be expected than spammers will send enormous amounts of encrypted messages, and hope that the server will be down due to many checks on the sender. This will not happen because the client will check locally whether the sender is on the list. If the spammer has forged the email address this will not work, unless he has the correct public key of the receiver. The receiver will first try to decrypt the message, the client software can check whether the decrypted text is right (just by requiring that the first byte of the message has to be a certain string (one byte satisfies actually)). If it is not encrypted by the public key, it is discarded. The receiver does not see anything of this, and in this way it is not a problem. 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 Kruithof Expires July 8, 2005 [Page 13] Internet-Draft Spam reducing protocol January 2005 each case, and after establishing the new connection, all the old keys, which MAY be in the hands of third parties, MUST thrown away. Now we have to see what spammers would do. They can not request the whole time for a certain address, because TIMEOUT is used. They have to do the request from a mailaccount which is in the organization. If the account is stolen, we have a problem, we may setup a hard limit on how much per month can be spent, and a soft limit which can be changed. If it is a virus, probably also the soft limit cannot be changed. The weakness which is left is the book keeping data server part. In case of compromising this part, money can be lost. Kruithof Expires July 8, 2005 [Page 14] Internet-Draft Spam reducing protocol January 2005 9. Acknowledgments The author would like to thank several people for many helpful comments and suggestions, including Anne Franssens (NL, University of Twente, Computer Science). 10 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 8, 2005 [Page 15] 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 8, 2005 [Page 16]