Network Working Group N. Möller Internet-Draft September 2004 Expires: March 2, 2005 Hash cash draft-nisse-hash-cash.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Möller Expires March 2, 2005 [Page 1] Internet-Draft Hash cash September 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 [1]. Möller Expires March 2, 2005 [Page 2] Internet-Draft Hash cash September 2004 2. Overview Hash cash is an attempt to make unsolicited mass email more costly, to make spam less profitable. Since a working digital cash standard is unlikely in the foreseeable future, the price is paid by spending cpu cycles to solve a problem. This document specifies three different mechanisms that work together. o An SMTP extension for hash cash o A way to bypass the hash cash using a secret key shared between sender and receiver. o Management of the secret keys. In this document, we consider Internet SMTP mail between two MTA:s belonging to two organizations, with no intermediate MTA:s. "Internet SMTP Mail" means that the receiving mail server accepts connections from untrusted hosts on the Internet. Mail traffic within each organization, and authentication of users within an organization, is out of scope for this document. Möller Expires March 2, 2005 [Page 3] Internet-Draft Hash cash September 2004 3. Special scenarios Some special scenarios that must be taken into consideration, and which must not be broken, are: o Solicited mass email, e.g. large mailing lists. This should be possible, without unbearable costs for the sending mail server. o Mail forward and relay. It should be possible to forward email. It should be possible to send mail via a relay host. FIXME: The current automatic key management fails when email paths are asymmetic, for example if mail for a home user is sent via a relay host operated by his or her ISP, and received via a mail server for some unrelated domain. o Bounce messages generated by the mail system. Möller Expires March 2, 2005 [Page 4] Internet-Draft Hash cash September 2004 4. MTA identification and state An MTA may consist of more than one machine, if the MTA uses a server cluster, or if in- and outgoing are handfled by different machines. An MTA is identified by a domain name. FIXME: There are lots of questions here: o Exacly which domain name? The domain the MTA presents in it's initial 220 response? Or the domain name that was used to find the MX or A record when contacting the MTA? o If several domain have MX-pointers to the same server, should they be considered separate MTA:s? o Is a primary mailserver and the secondaries considered the same MTA? o Is it confusing to use the word "MTA" to refer to the collective of servers handling mail for a domain? Then we need a better word for that concept. To support this SMTP protocol extension, each MTA needs to maintain several "databases". These databases are shared between all machines involved in the MTA service. o Key database, containing records . The records are essentially symmetric, a client and server sharing a key have equivalent records. o User database. This database contains information about which MTA:s or individual keys that each user is trusting not to send spam. It can be implemented as a per key default, combined with per user whitelists and blacklists. o Outstanding challenges. Keeps track of information about issued challenges, that some client wanted to solve off-line. Möller Expires March 2, 2005 [Page 5] Internet-Draft Hash cash September 2004 5. SMTP hash cash extension A hash cash transaction is initiated by the client. It sends a command saying what kind of hash cash it can offer. The SMTP server responds with a challenge, that includes a difficulty parameter. The client will normally respond with a correct response to the challenge, but it can also decline. One challenge type is defined: sha1 collision string. Here, the server gives the client a difficulty k (1 < k < 160) and a random nonce. A challenge message is constructed as challenge = from | NUL | to | NUL | nonce, where from and to denote the envelope addresses, | denotes concatenation, and NUL is the NUL byte. The client is expected to respond with an octet string response, of length at most 20, such that the first k bits of hmac-sha1(response, challenge) are all zero. Rationale for the construction of the challenge: It must depend on a unique nonce, to avoid replay attacks. It must depend on the envelope, to avoid interleaving attacks. Using hmac, rather than just a hash of the concatenation of challenge and response, should reduce the possibility of shortcuts in determining the response. Computing the response is structurally similar to a key recovery attack on truncated hmac. FIXME: Can we make this argument stricter? I suspect that a key recovery attack on truncated hmac using a single message is meaningless, due to a unicity distance argument. Möller Expires March 2, 2005 [Page 6] Internet-Draft Hash cash September 2004 6. Authentication using secret keys Since use of hash cash could make the computational cost of operating a list server for a large mailing list very large, we need some way to distinguish between solicited mass email and spam, and let the solicited email bypass the hash cash requirements. We introduce one general mechanism that can be used for both mailing lists and for other solicited email. We associate (unordered) pairs of MTA:s to secret keys, using the database described earlier. Management of the keys is described below. When the sending and receiving MTA share a key, it can be used for authentication. One method is defined, "hmac-sha1", which works as follows: The server gives the client a key id, corresponding to a shared key K to use, and a random nonce. A challenge message is formed in the same way as for hash cash: challenge = from | NUL | to | NUL | nonce. The client responds with hmac-sha1(K, challenge), which provides a proof of knowledge of K. Successful authentication is no guarantee that the message is accepted. Depending on server policy, and on the receiver's preferences (looked up in the user database), the server may require that the client MTA provides hash cash in addition to the authentication. Möller Expires March 2, 2005 [Page 7] Internet-Draft Hash cash September 2004 7. Setting up keys Key management is fairly simple. If no key for the sender/receiver pair exists when sending an email, a new record is added to the database with a new randomly chosen key. The SMTP transaction will probably require some hash cash. If the message is accepted, the key is passed (in the clear) to the receiving MTA, which will add it to its database. The key is marked as trusted at least by the sender of the initial message. When receiving such a key, it is marked as untrusted by all users. Authetnication using the new key is not sufficient to get past hash cash requirements. But the key is used when sending email. If/when a mail is sent successfully using that key, the user database is updated to mark the key as trusted by the sender, and further messages to this user can use authentication with the new key to bypass hashcash requirements. It is important to make sure that this mechanism works out of the box for mailing lists, for both traditional mailing lists with a -request address, and web-based subscriptions, where the key exchange should happen with the exchange of confirmation email. The policies for updating and applying user preferences is not specified, and can be arbitrarily complex. One example, which extends the above procedure is as follows: New keys are marked as untrusted for all users. Whenever a user is involved in sending a mesage using this key, the key is makred as trusted by that user. When the key has been marked as trusted by more than ten users, it can be marked as trusted by all users. Möller Expires March 2, 2005 [Page 8] Internet-Draft Hash cash September 2004 8. SMTP extension The SMTP extension definied by this specification is identified as "XHASHCASH" in the EHLO response (to be replaced by something different if/when this extension is advanced to standardstrack or as an IESG-approved experimental RFC). It defines five new verbs: o "XHASHCASHADVISE", asks the server what kind of authentication and/or hash cash it expects. o "XHASHCASHCHALLENGE", asks for a new challenge o "XHASHCASHRESPONSE", provides a response to the challenge o "XHASHCASHAUTH", used to bypass hash cash requirements. o "XHASHCASHNEWKEY", provides a new key. These are used after MAIL and before RCPT. Rationale: The messages depend on both envelope addresses, but for backwards compatibility we want the reply code to RCPT to say definitely if mail for the recipient is acceptable. When these commands are used, both server and client must know each other's names. FIXME: How these MTA names are related to the hello messages, envelope addresses, and other information, is not yet clear. 8.1 XHASHCASHADVISE The client needs to know what kind of authentication the server expects. Syntax: "XHASHCASHADVISE" SP Forward-path CRLF The server replies to XHASHCASHADVISE with the following codes: 300 No hash cash or authentication expected 301-No hash cash expected, authentication encouraged 301 310 Expecting hash cash 311-Expecting hash cash or authentication with key 311 330 Requiring hash cash 331-Requiring hash cash or authentication with key 331 Möller Expires March 2, 2005 [Page 9] Internet-Draft Hash cash September 2004 The 30x and 31x codes are suggestions to the client, while the 33x codes means the the server will refuse to accept the mail for delivery unless hash cash or authentication is provided. Possible keyid:s are listed one per line, in brackets. FIXME: Is this a sane use of reply codes? 8.2 XHASHCASHCHALLENGE Syntax: "XHASHCASHCHALLENGE" SP Forward-path SP methods CRLF methods = method / (methods "," method) method = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") The comma-separated list of methods are the methods the client is willing to use, in preferred order. If the server supports any of the methods, it sends a response 250 method SP id SP difficulty SP lifetime SP text CRLF The interpretation of the difficulty parameter, which should be an integer, depends on the method. If the client chooses to solve the challenge offline, it is expected to return with the respons after at most lifetime seconds. The text depends on the method, and depending on the method, several lines may be allowed. The id (also an integer) is chosen by the server and identifies this particular challenge. If none of the methods are supported, the server replies with code 504. This specification defines one method, "hmac-sha1", and for this method the text gives the server's random salt, as a quoted string, followed by optional additional text. Note that the salt is an ascii string, it is not an encoded octet string. FIXME: Is the reply syntax sane? Are quotes the right delimiters, or should we use angle brackets or something else? Is the syntax of Quoted-string defined properly elsewhere? After issuing this command, the client may terminate the current mail transaction (by the QUIT, RSET or EHLO command), in this case, the issued challenge must be stored for its advertised lifetime, and allow the client to come back later. 8.3 XHASHCASHRESPONSE After a successfull XHASHCASHCHALLENGE, the client computes a response Möller Expires March 2, 2005 [Page 10] Internet-Draft Hash cash September 2004 Syntax: "XHASHCASHRESPONSE" SP Forward-path SP method SP id SP text CRLF The method, forward path and envelope sender must match the given challenge, and the text depends on the method. Server responds with 250 if the response is correct, otherwise 554. FIXME: Is this a proper error code? Does it imply that the transaction initiated with MAIL FROM is aborted? And we should use different error codes for an unknown challenge-id:s, and for an incorrect response to a valid challenge. 8.4 XHASHCASHAUTH This command is used to bypass hash cash requirements. "XHASHCASHAUTH" SP Forward-path SP method SP keyid SP text CRLF keyid = 1*HEXDIG The structure of the keyid and text depends on the method. Typically, the keyid is the hash of a key, and the text is a MAC or a digital signature formed over some parts of the SMTP envelope. FIXME: Server must provide salt, perhaps we can reuse or revamp XHASHCASHCHALLENGE to provide salt also for this? The method is somewhat redundant, as it must match the key identified by keyid. One method is defined by this specification: "hmac-sha1". The server responds with 554 if it doesn't recognize the keyid, or 250 if it is ok. FIXME: And what error code should be used if the keyid is ok, but the MAC is wrong? 8.5 XHASHCASHNEWKEY Used to establish new keys for XHASHCASHAUTH. "XHASHCASHNEWKEY" SP auth-method SP kex-method SP text CRLF auth-method = method kex-method = method auth-method identifies the method used for authentication with the key, e.g. hmac-sha1. kex-method identifies the method used for exchanging the key. The simplest key-exchange method is "clear", which means that the text is the actual key to be used, in hexadecimal. Other possibilities include a diffie-hellman key exchange, and exchange of two public RSA keys in spki format, but no such exchanges are yet defined. The server responds with Möller Expires March 2, 2005 [Page 11] Internet-Draft Hash cash September 2004 250 SP text if the new key is recognized. The text depends on the kex-method (but not on auth-method). FIXME: There's no way to query the server which kex-methods and auth-methods it supports. FIXME: Since we only use per-MTA-keys, as opposed to user keys, it might make sense to move this out of the mail transaction. Möller Expires March 2, 2005 [Page 12] Internet-Draft Hash cash September 2004 9. MUA issues There are several things that a user must be able to control via his or her MUA, including: o Hash cash difficulty for mails to be received. FIXME: One might want to use a smaller cost for ordinary email transactions, and a higher cost for accepting a new key. o Amount of hash cash to offer when sending mail (this is a recommendation to the sending MTA; it should also have a system level or per-user level on the amount of cpu-resources to use for sending mail). o White- and black-listing of keys, or of MTA:s. Additionally, it may be be possible to mark correspondents to always require hash cash, or to make white list entries that expire automatically. It's desirable that communication between a MUA and its border-MTA is in the form of email, rather than a direct connection using SMTP or some other specialized protocol. Commands from MUA to MTA may be sent as email to a special email address. Authentication is out of the scope for this document, but three examples are: o Signing these messages using pgp, and a key registered with the MTA on account creation. o Consider all local users to be trusted, and let the MTA identify local connections by ip-address. o Accept un authenticated control messages, but reply with a confirmation request to the user's mailbox, containing a random confirmation code. The user must reply to this message for changes to take effect. For communication the other way, the MTA needs to insert a header line saying what kind of authentication was provided when the mail was accepted. This is not yet specified, but something along the lines of X-MTA-Hashcash: noauth X-MTA-Hashcash: auth X-MTA-Hashcash: challenge-response The keyid is important, for key revocation/black-listing. This line should be placed above the Received:-line, to provide some level of authentication. The work of the asrg filtering group, http://millenix.zemos.net/asrg-filtering/draft-irtf-asrg-filtering-he ader.html, is also relevant for the design. FIXME: Have to figure out how references work in xml2rfc. Möller Expires March 2, 2005 [Page 13] Internet-Draft Hash cash September 2004 10. Security Considerations 10.1 Damage from cracked machine What damage will a cracked machine inside an organization be able to do? It can spam freely inside the organization (unless some methods out of scope of this specification prevents that). It can spam people that the organization regularly exchanges mail with. These two groups will likely include most people found in address books within the organization. And it will be able to spam the rest of the world, limited only by the amount of cpu resources it can use to respond to hash cash challenges. 10.2 Semantics records in the key database When a key is set up using the XHASHCASHNEWKEY mechanism, and is associated with a peer MTA, not much is known. Essentially, all we know is that there is some person or entity other than ourselves that know the key. A key identifies the fuzzy group of entities who have access to the key. Proving knowledge of a key proves only that you are a member of that group. The more interesting information about a key and its key holder(s) is in the user database, which records if our users sends mail to the key holders MTA, as well as any explicit white- or black-lists. When the key is marked as "trusted" by one of our users, that means that the corresponding MTA is believed to send legitimate mail. Either that MTA initiated the contact, and our user replied (and we never reply to spammers), or our user initiated the contact, and then a reply is legitimate, almost by definition. 11 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Möller Möller Expires March 2, 2005 [Page 14] Internet-Draft Hash cash September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Möller Expires March 2, 2005 [Page 15] Internet-Draft Hash cash September 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Möller Expires March 2, 2005 [Page 16]