]>

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 .

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. An SMTP extension for hash-cash A way to bypass the hash-cash using a secret key shared between sender and receiver. 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.

Some special scenarios that must be taken into consideration, and which must not be broken, are: Solicited mass email, e.g. large mailing lists. This should be possible, without unbearable costs for the sending mail server. Mail forward. It should be possible to forward email. Bounce messages generated by the mail system.

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. The server can, at any time, inform the client that it expects hash cash. For example, in the response to SEND FROM or RCPT TO. One challenge type is defined: sha1 collision string. Here, the server gives the client a difficulty k (1 < k < 160), and a string c of k bits. The client is to respond with an octet string r of length at most 20, such that the first k bits of sha1(r) equals the challenge. (The challenge must be constructed so that it is bound to the transaction and to some random salt, in order to avoid interleaving attacks and dictionary attacks).

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 introduce a database that maps (unordered) pairs of identities to secret keys. The identities are SMTP envelope addresses. The database can be queried either by an MTA or an MUA, and it is used when sending and receiving mail. When sending email, the sender/receiver pair is looked up in the database. If a key is found, it is used to form a MAC on data consisting of sender and receiver id (in that order), selected headers, and the message body. The header lines included are From, To, Cc, Date, Content-type and Message-id. They are followed by an empty line, and then the message body, without transport encoding (to allow MTA's to change the transport encoding of messages in transit). The resulting MAC is provided to the receiver during the SMTP transaction. When receiving an SMTP message with a MAC, look up the sender/receiver pair in the database. If a key is found, verify the MAC. If the MAC turns out to be correct, the following steps are recommended: Bypass any hash cash requirements for the transaction. Add a header field, recording the result. If no MAC is provided, or the MAC is invalid, the server may require a hash cash transaction, and it should delete any possibly faked header in the incoming mail, that says the MAC was valid.

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. When receiving such a key, it is added to the database with the "tentative" flag set. The key is not yet used for receiving mail, but it is used when sending. If/when a mail is sent successfully using that key, the "tentative" flag is cleared, and the key is used also for receiving mail. Further messages, in either direction, can now use the shared secret key to bypass hash cash 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 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 four new verbs: "XHASHCASHCHALLENGE", asks for a new challenge "XHASHCASHRESPONSE", provides a response to the challenge "XHASHCASHAUTH", used to bypass hash cash requirements. "XHASHCASHNEWKEY", provides a new key. These are used after RCPT and before DATA. Additionally, it defines one parameter to the RCPT verb.

Syntax: challenge = "XHASHCASHCHALLENGE" 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

response = 250 method SP text CRLF The text depends on the method, and depending on the method, several lines may be allowed.

If none of the methods is supported, the server replies with code 504.

After a successfull XHASHCASHCHALLENGE, the client computes a response

Syntax: challenge = "XHASHCASHRESPONSE" SP method SP text CRLF The method 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?). FIXME: Should it be possible for the client to disconnect while solving the challenge, and coming back later?

This command is also used after RCPT, and it is used to bypass hash cash requirements.

auth = "XHASHCASHAUTH" 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 message and SMTP envelope.

The method is somewhat redundant, as it must match the key identified by keyid. The server responds with 554 if it doesn't recognize the keyid, or 250 if it is ok. Actual verification of the authentication can usually not be done until after the DATA. If authentication fails, the server replies to the DATA with code 554.

Used to establish new keys for XHASHCASHAUTH.

newkey = "XHASHCASHNEWKEY" SP auth-method SP kex-method SP text CRLF auth-method = methos 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. The server responds with

newkey-respons = 250 SP text

if the new key is recognized. The text depends on the kex-method (but not on auth-method).

The client needs to know what kind of authentication the server expects. Since this will depend on both sender and receiver, the server should have made up its mind by the time it responds to RCPT. But for backwards compatibility, it can not use any new responses to an old plain RCPT. The client requests an extended response by adding the keyword XHASHCASHADVISE to the RCPT command. When the XHASHCASHADVISE keyword is given by the client, the server can reply with the following additional codes:

310 Expecting hash cash 311-Expecting hash cash or authentication with key 311 <keyid> 330 Requiring hash cash 331-Requiring hash cash or authentication with key 331 <keyid> The 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 extension? Can the keyid:s be extracted reliably from the replies? Can this use of reply codes collide with other extensions?

There are several things that a user must be able to control via his or her MUA, including: Hash cash difficulty for mails to be received. One might want to use a smaller cost for ordinary email transactions, and a higher cost for accepting a new key. 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). Removal of keys from the database. Additionally, it may be be possible to mark correspondents to always require hash cash, or to mark keys to expire automatically (for example, when subscribing to "one time" or "yearly" newsletters. Communication between a MUA and its border-MTA may be in the form of control messages to a special email address. Authentication is out of the scope for this document, but two examples are: Signing these messages using pgp, and a key registered with the MTA on account creation. Consider all local users to be trusted, and let the MTA identify local connections by ip-address.

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 to. 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 to the amount of cpu resources it can use to respond to hash cash challenges.

When a key is setup using the XHASHCASHNEWKEY mechanism, and is associated with a mail address, the following properties hold: There is some person other than ourselves that know the key. This key owner is believed to send legitimate mail. Either she initiated the contact, and we replied (and we never reply to spammers), or we initiated the contact, and then a reply is legitimate, almost by definition. The MTA associated with the name claims that the name is valid and that it knows the key. The final point is the only one that is related to the name, and it is the most subtle one. It means that if "alice@victim.example.com" runs a properly configured mailserver, it is impossible for "eve@enemy.example.com", who has no control over victim.example.com's mailservers, to exchange a key with "bob@example.com" and get it associated with Alice's name. It provides for some authentication of the sender, significantly stronger then unauthenticated email, but weaker then proper digital signatures. It is subject to attacks during the key establichment, both MITM attacks, and in case the new key is sent in the clear, to passive eavesdropping. It is not clear how useful this will be for the end user, though, as the MUA will need to compare the From: address in the mail header to the SMTP envelope address, and check additional mail headers where the MTA stores the result of the authentication Furthermore, since the key is shared between MTA:s, not between end users, it will usually not prevent users with the same MTA from impersonating each other.

It may be desirable to be able to add additional aliases, for example for the various addresses used by a mailinglist. One could allow a key-owner to add arbitrary new names to a key, but that would violate the authentication property described above. To get the the authentication property back, some interaction with the MTA associated with the new name is needed. If the different names use distinct MTA's, this seems to requiring sharing keys between those MTA's, which seems impractical. For this reason, it makes some sense to support sharing of a key between several aliases, only when the two names have the same domain-part. A compromise may be to associate a list of name to keys, and for each name, use a flag to record whether the corresponding MTA is known to recognize the name and key pair. This can be seen as an extension of the tentative flag, described above.

For aliases on the same MTA, e.g. "foo@example.com" and "foo-request@example.com", one may realize that in effect, the MTA for "lists.example.com" is the natural authority for alias questions. After all, it has the responsibility sorting email to the right account, and it is responsible for user's forward files, and user aliases such as "kalle+foo@example.com" (it's not necessarily desirable to treat "kalle" and "kalle+foo" as aliases when it comes to hash-cash authentication, though). If we follow this idea, and don't bother about aliases between mailinglists, the entries in the key database will look like this:

db-entry = (key, local-name, local-aliases, remote-name) local-name = mailbox local-aliases = ( 1*Local-part ) remote-name = mailbox

For example, the MTA for "a.com" can have the entry (K, "adam@a.com", ("adrian", "andy"), "beata@b.com"). The MTA for "b.com" can have a corresponding record for the same key, (K, "beata@b.com", ("bertha", "beatrice"), "adam@a.com"). The local-name and remote-name are the canonical names associated with the key. Each side keeps a record of its aliases that should share keys with the the canonical name. When sending mail from an alias, the canonical name must be given as a parameter to MAIL FROM (as the receiving MTA is not expected to know about it). When the receiver is an alias, the receiving MTA must list the canonical name in the response.

An example, where adrian sends an email to beatrice: C: MAIL FROM <adrian@a.com> XHASHCASHNAME <adam@a.com> S: 250 OK C: RCPT TO <beatrice@b.com> XHASHCASHADVICE S: 311-Expecting hash cash or authentication for <beata@b.com> with key S: 311 <id for K>

Exactly how configuration of local aliases is managed is up to the implementation; it may use an explicit list in the database, as described above, or it can use wildcard rules to express local conventions, e.g that the suffixes "-request" and "-owner" always are to be removed in order to form a canonical name. It is even possible to use a single "canonical name" for all mailboxes on the server, in effect reducing the number of entries in the database to one per correspondent, rather than one for each pair of correspondents.

&rfc2119;