Network Working Group W. Kruithof Internet-Draft Unix-AG Universitaet Hannover Expires: June 29, 2005 December 29, 2004 Spam reducing protocol draft-kruithof-spam-reducing-01.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 June 29, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Accepted emails do the sender not cost money, not accepted do. The system, in which encryption naturally appears, can be used transparently aside of the existing email systems. A central server for initiating the connection is needed. There exists an implementation in which overtaking of the server only affects the communication channels which are made after the overtaking. Kruithof Expires June 29, 2005 [Page 1] Internet-Draft Spam reducing protocol December 2004 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and overview . . . . . . . . . . . . . . . . . . 4 3. Overview of the protocol . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Kruithof Expires June 29, 2005 [Page 2] Internet-Draft Spam reducing protocol December 2004 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 June 29, 2005 [Page 3] Internet-Draft Spam reducing protocol December 2004 2. Introduction and overview Spam is nowadays handled by using white/blacklists and spam filters. It can be expected that the spam problem will not satisfactory be solved by these solutions. Neither is guaranteed that receivers will not get spam, neither that sent emails always come through the anti-spam solutions. This document proposes such a protocol that in the equilibrium state a minimum of spam will be sent. The second advantage is that there always exists a way for a sender to be sure that a certain email is received and read or not by the receiver. 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 the message the money is booked back to the sender, if not, the money is booked to the central server company. 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 June 29, 2005 [Page 4] Internet-Draft Spam reducing protocol December 2004 3. Overview of the protocol Alice wants to send an email to Bob, whose email address she knows. She can send directly an email, but she wants to be sure that it will not disappear in the spam folder, and thats why will be read to late or not. For successful communicating 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's server for each email address SHALL be seen how many it cost to send a mail 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 is set by Bob for downloading from the server the public key of Bob. Alice 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 if Bob accepts her email, and which is deleted if he dis-accepts 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. If Alice sends her email to Bob, this MUST be encrypted with the public key of Bob for which she paid. Bob's email client receives the email, and this MUST check whether the mail is encrypted, if so, his clients MUST connect to the server to get the public key, with which the mail 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 save communication. If the email is not encrypted, it SHALL be lead further in the 'normal' mail processing (spam filters etc), which expresses the transparency of the new protocol aside of the normal mail protocol. Now Bob knows which private key he has to use to decrypt the email message. If not, the mail can be lead further in the normal system, it could be a normal encrypted message if no matching email address is found in the database. If the receiver doesn't explicitly reject the email, the cost MUST be booked back. OPTIONAL is accepting email from Alice mail 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 the company's account. Kruithof Expires June 29, 2005 [Page 5] Internet-Draft Spam reducing protocol December 2004 For each new connection (new person or new email address) a new public-key/private key pair SHOULD be generated, in case a public key of Bob will be known to people for whom Bob does not want that they know this email address. As soon a connection is made, the used private key with each email address SHOULD be saved by client software, so that in future the server is not needed for further communication. In case of a 'one-time' key pair, the public key SHOULD be deleted from the server by the client. Bob can reject the mail, and that is why spam will not be send in the situation, that the sender cannot make benefit out of the extra cost anymore. This will be reached of course in the equilibrium situation, Bob wants his 'to pay' to stay as low as possible, but not to low to get spam mail from company's which think they can earn that cost back. In practice, Bob MAY setup an email address for which he will exclusively use the new protocol. Each mail 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 June 29, 2005 [Page 6] Internet-Draft Spam reducing protocol December 2004 4. Security Considerations This section handles the case a server has been compromised and why various SHOULD's 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 SHOULD's 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 party's, MUST thrown away. The weakness which is left is the book keeping data server. In case of compromising this part, money can be lost. 5 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 June 29, 2005 [Page 7] Internet-Draft Spam reducing protocol December 2004 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 (2004). 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 June 29, 2005 [Page 8]