Network Working Group J. Fenton Internet-Draft M. Thomas Expires: November 30, 2004 Cisco Systems, Inc. June 1, 2004 Identified Internet Mail draft-fenton-identified-mail-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 November 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes extensions to the format of electronic mail messages and a public-key infrastructure to permit verification of the source of messages by either mail transport agents (MTAs) or mail user agents (MUAs). This may be used to implement a policy which, for example, favors the delivery of identified messages over messages lacking signatures or having incorrect signatures. Mechanisms by which signing of messages and verification of signatures can be performed by a trusted MTA, in order to minimize impact on the user, are also presented. Fenton & Thomas Expires November 30, 2004 [Page 1] Internet-Draft Identified Internet Mail June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Identified Mail Tag Syntax . . . . . . . . . . . . . . . . 5 2.2 The Signature Header . . . . . . . . . . . . . . . . . . . 6 2.3 The Verification Header . . . . . . . . . . . . . . . . . 7 2.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 8 2.5 Use of From header . . . . . . . . . . . . . . . . . . . . 9 3. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Key Registration . . . . . . . . . . . . . . . . . . . . . 10 3.2 Key Verification . . . . . . . . . . . . . . . . . . . . . 11 3.3 Address ratings . . . . . . . . . . . . . . . . . . . . . 13 4. Policy Options . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.1 Potential Attacks . . . . . . . . . . . . . . . . . . . . 17 5.1.1 Key Registration Server DoS Attack . . . . . . . . . . 17 5.1.2 Key Registration Server Stall Tactic . . . . . . . . . 17 5.1.3 Misappropriated private key . . . . . . . . . . . . . 18 5.1.4 Message Replay Attack . . . . . . . . . . . . . . . . 18 5.2 Other Considerations . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 7.2 Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Fenton & Thomas Expires November 30, 2004 [Page 2] Internet-Draft Identified Internet Mail June 2004 1. Introduction Internet users have recently been subjected to a torrent of unwanted email messages. These generally take two forms: 1. Messages originated by "spammers" to send advertising or solicitation, or as part of a confidence scheme 2. Messages sent automatically by worms and other malware attempting to infect additional systems In both cases, a large proportion of the messages attempt to disguise their true source, to frustrate attempts to shut down the spammer, to disguise the identity of the infected system sending the message, or to support a social-engineering goal. Since SMTP permits senders to use any return address they wish, the addition of a signature to messages limits the opportunity of spammers or malware to forge return addresses, and thus provides some degree of accountability for the source of email messages. As currently used, message signatures such as those generated by PGP cover only the body of a message. It is therefore possible for anyone to forward a signed PGP message, although of course the identity in the signature remains that of the original signer. The intent here is somewhat different: we want to identify the actual sender of a message and associate the signature with the message itself. For that reason, the signature will be encapsulated in the message differently than in a signed PGP message. The public key used to sign the message will be included in the header, and its binding with the envelope-from address of the message will be verified. The email identification problem is characterized by extreme scalability requirements. There are currently on the order of 30 million domains and a much larger number of individual addresses. It is important to preserve the positive aspects of current email infrastructure, which include the ability for anyone to communicate with anyone else without introduction. This contrasts with PGP's use of trusted introducers to vouch for the authenticity of keys. Key management based on introducers would have difficulty scaling to the large number of addresses in use and retain the degree of connectivity that email provides. What is presented here is not a complete solution to the spam problem. The intent is to give tools to the user to allow the classification and prioritization of desired mail. Since much of the undesirable mail is characterized by forged return addresses, the identification of such messages is a major focus of this effort. Some degree of accountability for the source of email messages will also result, although spammers will still have the ability to operate Fenton & Thomas Expires November 30, 2004 [Page 3] Internet-Draft Identified Internet Mail June 2004 their own domains and key registration servers and create large numbers of bogus identities. It is hoped that through tools such as this that facilitate message classification, spam and malware-generated messages may eventually be marginalized to the point that they are irrelevant. Fenton & Thomas Expires November 30, 2004 [Page 4] Internet-Draft Identified Internet Mail June 2004 2. Message Format An identified internet mail message is in much the same format as a conventional mail message as defined in RFC 2822 [1]. Two new headers, referred to as the signature and the verification header, are defined. 2.1 Identified Mail Tag Syntax Identified Mail uses a common encoding for the signature header (X-IMAIL-SIG), the verification header (X-IMAIL-VERIFY), as well as the KRS response. A line is composed of a set of tags delimited by a ":" followed by a single value delimited by a ";". Tags may be any number of alphanumeric characters, but SHOULD be limited to a single character. A receiver decoding an unknown tag MUST silently discard the tag and value. Values are similar to C quoted strings in that each value starts and ends with a double quote. Special characters are escaped by preceding them with a single backslash followed by the encoded character. The following escaped characters are currently recognized: \n: an ascii newline (0x0A) \r: an ascii carriage return (0x0D) \f: an ascii form feed (0x0E) \v: an ascii vertical tab (0x0B) \\: the backslash character itself \": the double quote character itself A backslash followed by a character which doesn't have significance above MUST be interpreted as that character as if the preceding backslash was not present. Encoders MUST translate all special characters into their escaped form. Decoders MUST reject strings which span line breaks as the meaning is ambiguous given the way that mail header continuation lines are formed. In addition, each value MAY be split into multiple lines by as series of quoted strings. Decoders MUST interpret multiple quoted strings in a value as if they were all part of a single quoted line. Values may be any value with the exception of ':', ';' and '"'. Any value which cannot be represented in this way MUST be quoted and escaped in the normal C string convention. Lines SHOULD be broken apart for legibility and MUST NOT exceed the line length limits specified in RFC 2822, section 2.1.1. Fenton & Thomas Expires November 30, 2004 [Page 5] Internet-Draft Identified Internet Mail June 2004 2.2 The Signature Header The Signature header MUST be included in a message in order for it to be considered an identified mail message. It has the syntax: signature = "X-IMAIL-SIG:" signature-text CRLF The signature-text contains a number of fields which represent the signature itself, a public key used to create the signature, and related information. An example of a signature is as follows: X-IMAIL-SIG: v:"1"; h:"thomasm-u1"; d:"cisco.com"; t:"1080771772.862325"; x:"1081203772"; a:"rsa-sha1"; e:"Iw=="; n:"pZORwkeEetQnTVC7tw5MIE+31ROt/sGv5q+dxuwUIIqu5XKSva4P1/anPgIiz" "7K8V0MaRDwDjKIuYYGaUO5IdDNfE7WEKe+/r8k3D0lrkNCa8qNPDSKljocN6y" "d7Wjmx/Hk+tquACcpwhhDyVxzIBcj/A5aCApbeFeRkVvfFH70="; s:"T3iRhynnuKx8+UNBuxMnDCIFet8RTM+VAs+STKM4P9ZqiEaUmG1rXmeXq3T+8" "0oHhWtztZob/2twTxiqzgMD5MnFOTaqujJUBOmkIf1VR+ELzKq/vPZ+GmWs+h" "mtSg3sH7jWrnvYHQpT6yey9TumnJVAdWepPl4budT9GFdpRuw="; c:"Subject: new tags" All tags and their values in the X-IMAIL-SIG line are included into the cryptographic hash with the sole exception of the s: (signature) tag and its value. The tags and their values are simply concatenated to each other when forming the cryptograhic hash in the order they are present in the X-IMAIL-SIG line. That is: "v1hthomasm-u1dcisco.com[...]" Syntactic markers are NOT included and the value used in the hash is before encoding/after decoding. The final hash algorithm is as follows: TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12) where SIGTAGVALS is the encoding described above for the header tags/ values and BODY is the SHA-1 hash of the body of the email itself. Note that SHA-1 value of the body uses the full 16 bytes of the hash (i.e., not truncated). The tags used in the signature are as follows: a: Algorithm. One-way hash and public key algorithm. Currently this MUST be rsa-sha1. c: Copied header. A copied header is a header which the sender would like to cryptographically sign. Note that IMail does not include any other headers into the cryptograhic hash. The headers which are copied into the signature line are purely at the discretion and local policy of the signer but SHOULD include the Subject, From, and Date headers. Receiving MTAs and/or MUAs MAY choose to replace the unsigned headers with headers which have been signed so as to present untampered with headers to the user, Fenton & Thomas Expires November 30, 2004 [Page 6] Internet-Draft Identified Internet Mail June 2004 typically the headers copied from the originating domain. If such a replacement is performed, the unsigned headers SHOULD be preserved in the message (e.g., X-UNSIGNED-HEADER). Note: For the hash calculation, the value MUST be encoded as the copied header followed by a colon (":"), followed by a single space, followed by the rest of value of the copied header. That is, for hash calculation it looks like: Subject: Hello World! d: Domain of signer. This tag denotes the signing domain. It is used to inform the receiver of the appropriate level of address that is considered the authoritative domain in this context. For example, if a message is received from jdoe@eng.example.com, the d: tag might indicate that the domain is example.com or eng.example.com. If this tag does not correspond to either the hostname of the envelope-from address or a higher-level domain, the signature MUST be ignored. e: The RSA public exponent of the supplied signing key, base 64 encoded. h: Signing host. This is purely informational and is not used by IMail. n: The RSA public modulus of the supplied signing key, base 64 encoded. Note that the key length is implicit with the number of decoded bits in the modulus. Signers MUST support 1024 bits and SHOULD support 768 and 1536 bits. Receivers MUST support 768, 1024 and 1536 bits. s: The RSA signature over the computed one-way hash, base 64 encoded. t: Timestamp. The time that this signature was created. The format is the standard Unix seconds-since-1970 followed by a fractional number which MUST be guaranteed to be unique for this signing key. The intent of the fraction is to the guarantee the uniqueness of any given signature at any particular instance. The value is expressed as an unsigned integer. x: Signature expiration in seconds-since-1970 format. Signatures MUST NOT be considered valid if the current time at the receiver is past the expiration date. The value is expressed as an unsigned integer. v: Version of these tags. This MUST be set to "1". The value is expressed as an unsigned integer. 2.3 The Verification Header The verification header is an optional header which is used to convey the verification of a message from an MTA to an MUA or another MTA within the same trust domain. If used, it is applied by an MTA that is close to the point where an MTA or the recipient's MUA applies Fenton & Thomas Expires November 30, 2004 [Page 7] Internet-Draft Identified Internet Mail June 2004 policy based on the verification status of the message. The verification header indicates whether an MTA was able to successfully verify the message according to whatever policies it decides to use. A recipient MUA or MTA MAY decide to rely on the presence of a verification header in applying policy to the message (e.g., moving an unverified message to a lower-priority folder), or it may do such verification locally. The verification header is not cryptographically protected, in order to avoid the need to manage keys for MTAs. The verification header SHOULD be deleted from the header when the message is sent via SMTP outside the trust domain of the sender, and it MUST be discarded if it received from an SMTP peer that is not trusted by the recipient (normally one that is within the recipient's administrative control). There MUST be at most one verification header in a message; MTAs which perform message verification MUST ensure that they either agree with the contents of an existing verification header, or replace it with a new one. An example of a verification header is as follows: X-IMAIL-VERIFY: s:"y"; v:"y"; r:"68"; h:"imail.cisco.com" The tags and values used by the verification header are as follows: s: Signature. The value is "y" if there is a signature line from the sending domain (ie, the domain suffix in the envelope from). Otherwise the value is "n". v: Verify. The value is "y" if the home domain's signature is both present and the public key operation verifies correctly. r: Rating. The value here is between -127 and 127 with negative values expressing an adverse rating, zero being neutral and positive values indicating a favorable rating. The rating value is completely at the discretion of the entity supplying the X-IMAIL-VERIFY header and MAY take into account many different factors including the rating supplied by the home domain's KRS, local and third party ratings, and any other factors the verifying entity considers relevant. h: Host. This is the fully qualified domain name of the MTA that performed the verification. It should be noted that since the X-IMAIL-VERIFY header is not cryptographically protected, users or subsequent MTAs which make use of the X-IMAIL-VERIFY header must independently ensure that it is not subject to tampering. 2.4 Canonicalization In order to minimize the possibility of signature breakage due to message or header rewriting while passing through the mail system, Fenton & Thomas Expires November 30, 2004 [Page 8] Internet-Draft Identified Internet Mail June 2004 mail agents which apply an Identified Mail signature MUST take steps to ensure that the message is in a canonical form prior to signing the message. Messages containing only 7-bit characters and lines of 78 characters or less MAY be sent without conversion. Messages which do not meet both of these requirements MUST be converted to MIME format, and the resulting MIME body is constrained to 7 bits -- that is, the use of material requiring either 8bit or binary transfer-encoding is NOT allowed. Such 8bit or binary material MUST be encoded using either the quoted-printable or base64 encodings. 2.5 Use of From header Identified Mail associates the key in the message with the Envelope-from address of the message. This is done to allow mailing lists which re-originate messages with their own envelope-from address (but retain the original sender's address) to sign the re-originated messages. However, it is the From address that is most commonly seen by the recipient, and it is important that it not be inconsistent with the Envelope-From address. In order to retain the current semantics and visibility of the From header, verifying mail agents SHOULD rewrite the From header if the From address is not the same as the Envelope-from address, by appending "via" and the Envelope-from address to the From header. For example: From: fenton@cisco.com via asrg-admin@ietf.org This sort of address inconsistency is expected for mailing lists, but might be otherwise used to mislead the recipient, for example if a message supposedly from administration@your-bank.com had an envelope-from address of fraud@badguy.com. In order to prevent this rewriting of the From address from interfering with subsequent reverification of the message if the From header is signed, verifying MTAs MUST consider a From address which differs from the signature header by the addition of "via" and the envelope-from address to be valid. Fenton & Thomas Expires November 30, 2004 [Page 9] Internet-Draft Identified Internet Mail June 2004 3. Key Management In order for these signatures to be meaningful, a trusted database of public keys needs to be available to verify message signatures. The PGP approach to this issue of trust is through the use of trusted introducers, where individual keys are signed by others that may be trusted by the user of the public key. Due to the large amount of connectivity required in email and the (perhaps) lower standard of trust required to accept an email message rather than, for example, process a financial transaction, we present an alternative model here. 3.1 Key Registration In order to receive email messages, domains typically use one or more MX (mail exchanger) resource records to indicate to where mail for that domain should be directed. Similarly, DNS resource records can be used to locate one or more hosts, referred to as Key Registration Servers (KRSes), which may be considered authoritative to verify the association of a key with an email addresses in the domain. To locate the KRS, the verifying MTA/MUA queries DNS with the hostname part of the envelope-from email address (e.g., eng.example.com for tom@eng.example.com). The zone file for a given domain might contain records such as the following: example.com. IN MX 10 mail.example.com. example.com. IN MX 10 mail2.example.com. _krs._tcp.example.com. IN SRV 10 10 378 krs.example.com. _krs._tcp.example.com. IN SRV 10 10 378 krs2.example.com. Key registration servers confirm (or deny) the binding between the envelope-from email address used by the message and the key used to sign the message. It does so by receiving a query containing the key fingerprint and the envelope-from email address. It returns a numerical value based on the policy of the sending domain as to whether the key is authorized to be used in sending a message from the specified address. One such policy might be as follows: +127: Key is recognized and acceptable for the given address 0: Key is unrecognized -127: Key is known to have been compromised; do not accept it The outgoing MTA for a domain is most likely to perform rewriting, if any, of the envelope-from address of the message (for example, to remove an unnecessary subdomain). Since the KRS and the outgoing MTA are usually under common administration, the KRS can be configured to respond appropriately to expected rewritings of the envelope-from Fenton & Thomas Expires November 30, 2004 [Page 10] Internet-Draft Identified Internet Mail June 2004 address. The following are some excerpts from a hypothetical KRS database: #Rating TTL Address Key Fingerprint 100 86400 tom@eng.example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC # Tom's usual address 100 86400 tom@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC # Rewriting of Tom's address 100 86400 dick@example.com 91881749E520D8F53B0B91BBD8963D0D # Dick's PC 100 86400 dick@example.com 549D8949351DDA4E7C961E0F58727795 # Dick's PDA -100 864000 harry@example.com 8C8252070CA9ED401DD2EE2A7B31A8CF # Harry's stolen PC 100 86400 harry@example.com 17E64AC44DD5F8891560919D3FC6EA52 # Harry's new PC 100 86400 harry@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC # Tom is Harry's adminstrative # assistant, so Harry allows Tom # to originate mail for him. 100 604800 *@example.com 27985A61447CC8B514A82BFA4597174A # Outgoing MTA key. MTA keys are # less likely to require rapid # revocation, hence the longer TTL. 100 86400 nobody@example.com * # Any key will work for this address # NOT RECOMMENDED! The ability to configure multiple key registration servers for a given domain is intended to provide a degree of fault-tolerance and distribution of the key-verification load. The availability requirement for key registration servers is somewhat higher than for mail exchangers (and probably more comparable to that of domain name servers) because real-time access to the key registration servers is often required at the time an email message is received or relayed. Accordingly, each domain defining key registration servers SHOULD define at least two, and they SHOULD be located on different networks. The key registration servers for a domain need to be kept in as close synchronization as possible. In particular, any key revocations that take place MUST be reflected immediately in all key registration servers for the domain. 3.2 Key Verification Verification of public keys from key registration servers is Fenton & Thomas Expires November 30, 2004 [Page 11] Internet-Draft Identified Internet Mail June 2004 accomplished via a properly-formatted HTTP request. A sample request might be formatted as follows: http://krs2.example.com:378?domain=example.com &name="john@example.com" &keyfp="27985A61447CC8B514A82BFA4597174A" &service="SMTP" The fields in the query are as follows: name: The envelope_from of the incoming mail. keyfp: The public key fingerprint that was supplied in the X-IMAIL-SIG line. The fingerprint is created as follows: create the binary representation of the RSA exponent and modulus and concatenate them as e|n. Run this value through SHA1 over the full length and convert the first 12 bytes of the output of the SHA1 operation to base 64. That is: base64 (TRUNC (SHA1 ((e|n)), 12) domain: The domain corresponding to the query to be performed. This is used primarily to allow a single KRS to support multiple domains, with each domain database being independently maintained. This value corresponds to the d: value in the signature being checked; it MUST be the same as or a superdomain of the envelope-from address of the message. service: The service for which the query is requested. Currently the only valid service is "SMTP", though this may be expanded in the future. The KRS response is the IMAIL standard tag/value syntax with the following tags/values defined: s: status. Follows the general convention of SMTP/HTTP status values (eg, 200, 300, 400, 500 semantics) with the following values defined: 200: the lookup succeeded. 201: the lookup succeeded, but the keyfp/name combination was not found 500: any permanent failure. t: Time to live. Responses SHOULD be cached on the receiver so as to reduce the query/response load back to the KRS. Time to live is expressed in seconds from when the query was sent. r: Rating: like rating in the X-IMAIL-VERIFY, an integer between -127 and 127 which as the sole discretion of the entity producing the rating. Normally, revoked keys from the home KRS would be given a (very) negative rating. m: Matches. Some key fingerprints may in fact sign for more than the single address that is present in the query. In order cut Fenton & Thomas Expires November 30, 2004 [Page 12] Internet-Draft Identified Internet Mail June 2004 down trips to the KRS, the Matches field describes with normal Unix wildcard syntax what envelope_from patterns match this key fingerprint. For example: m:"*@example.com" would inform the cache logic of the requestor that future queries from example.com with this key fingerprint be given the same rating and time to live. Note that while the syntax of the matching pattern uses normal unix wildcard syntax, the semantics of the wildcarding are actually constrained to be a "longest prefix match" algorithm where the prefix components are allowed to be either the left hand side of the envelope_from, or the successive subdomain components. In all cases, a matches value MUST NOT exceed the prefix of the envelope from. That is, an entity from example.com cannot say that it matches *@*.com since it is not authorized to sign for the entire .com domain. c: Comment. This is a free form string intended to convey a human readable comment about the operation. This is typically used to send diagnostic information for failed operations, etc. v: Version of the responses. Currently this MUST be set to "1". The value is expressed as an unsigned integer. The key registration servers must use a mechanism that ensures that only authorized users are able to deposit key fingerprints on the server and revoke them. This may involve a mechanism such as an authenticated HTTP exchange that requires the user's password in order to register a public key fingerprint for that user on the server. It is implicit in this key management approach that only legitimate key-to-address bindings may be registered on the key registration servers. In order to prevent harvesting of email addresses, KRSes MUST NOT respond with any email address other than that presented in the query or a more general address (for example, when the key fingerprint corresponds to a domain MTA). 3.3 Address ratings It is helpful, but probably not sufficient to confirm that a message was signed using a key authorized for the stated address. This fact alone says nothing about the security of the originating domain's key registration servers, the method used to identify message senders prior to MTA message signing, and the overall character of the domain. Senders of spam are free to register domains and set up key Fenton & Thomas Expires November 30, 2004 [Page 13] Internet-Draft Identified Internet Mail June 2004 registration servers for those domains. Domains might also be set up with explicitly open key registration policies, to permit anonymous exchange of signed messages among groups of people. In either case, mail from such domains might be less valued than from domains known to be reliable. The address rating service fulfills the need to distinguish domains with differing registration policies and/or user behavior. The rating service is envisioned as a third-party service, somewhat analogous to a credit bureau, which the verifier of an identified mail message MAY use to obtain a relative evaluation of the sending address based on criteria established by the rating bureau. Ratings will normally be granular to the domain of the sending address, but may also give information on individual addresses. A hypothetical ratings database might look something like this: 90 responsible-isp.com /* ISP with good security and policies */ 40 flaky-isp.com /* ISP that isn't very responsive */ 80 tom@flaky-isp.com /* Known good user at flaky ISP */ 0 spam-marketing.com /* Known source of UCE */ Entries in the ratings database should be returned on the basis of longest-match. In the example above, the address "tom@flaky-isp.com" should return a rating of 80, not the value of 40 used for all other addresses in the domain. Fenton & Thomas Expires November 30, 2004 [Page 14] Internet-Draft Identified Internet Mail June 2004 4. Policy Options Identified Mail by itself introduces no new policy with respect to handling email. However, the benefit of using Identified Mail lies with the widespread deployment of policy which encourages the signing of email and eventually marginalizes unsigned messages. One place where policy can be implemented is at the receiving user. The user can verify the signatures of messages as they are received, and place unsigned messages in a "bulk mail" or similar folder to be read (if at all) on a lower-priority basis. This would typically be done through an enhancement to the mail user agent, probably at the time messages are downloaded via a protocol such as POP. Since the user must contact the key registration servers for all keys not in the user's key cache, this could lengthen message downloading times, and may present a problem for transitory users such as those on dial-up lines. The service provider (or enterprise) has the option of adding a verification header to incoming messages. This considerably simplifies things for the user, who can now use an existing mail user agent. Most MUAs have the ability to filter messages based on message headers or content; these filters would be used to implement whatever policy the user wishes with respect to unsigned mail. The service provider itself can implement a policy with respect to unsigned mail, provided that the mail transfer agents have the ability to verify signatures (regardless of whether or not they apply the verification header to signed messages). Separate policies may be defined for unsigned messages, messages with incorrect signatures, and in cases where the signature cannot be verified, for example if all the key registration servers are unreachable. In the course of receiving a message, the service provider can retrieve the public key of the sender from one of the designated keyservers or from a local cache, and check the signature on the message. If policy dictates, the service provider might reject the message with an error such as: 5yx Unsigned messages not accepted 5uv Message signature incorrect If the key registration server is not available, a temporary failure message could be generated, such as: 4yx Unable to verify signature - key registration server unavailable Policies of this sort naturally assume the widespread use of message Fenton & Thomas Expires November 30, 2004 [Page 15] Internet-Draft Identified Internet Mail June 2004 signatures. Fenton & Thomas Expires November 30, 2004 [Page 16] Internet-Draft Identified Internet Mail June 2004 5. Security Considerations Fundamentally, the addition of signatures to email messages is all about security, although not in the usual way of ensuring the secrecy of data. 5.1 Potential Attacks It has been observed that any mechanism that is introduced which attempts to stem the flow of spam is subject to intensive attack. Identified mail needs to be carefully scrutinized to identify potential attack vectors and the vulnerability to each. Some of the attacks that have been considered are described in the following sections. 5.1.1 Key Registration Server DoS Attack Since the key registration servers are distributed (potentially separate for each domain), the number of servers that would need to be attacked to defeat this mechanism on an Internet-wide basis is very large. Nevertheless, key registration servers for individual domains could be attacked, impeding the verification of messages from that domain. This is not significantly different from the ability of an attacker to deny service to the mail exchangers for a given domain, although it affects outgoing, not incoming, mail. A variation on this attack is that if a very large amount of mail were to be sent using spoofed addresses from a given domain, the key registration servers for that domain could be overwhelmed with requests. However, given the low overhead of HTTP requests to the KRSes relative to handling of the email message itself, such an attack would be difficult to mount. 5.1.2 Key Registration Server Stall Tactic An attacker trying to "jam" the signature mechanism might set up a key registration server for a domain they control that responds very slowly or perhaps not at all. They then send a large number of messages from that domain, in an attempt to bring the signature verification mechanism to a crawl and get domains to turn it off. This could be mitigated by the use of appropriate timeouts on key lookups and possibly by adapting these timeouts to message load. Note that it is considerably easier to mitigate this attack when the signature check is done by the terminating MTA than the MUA because of the MTA's ability to return a temporary failure when the key can't be retrieved. Fenton & Thomas Expires November 30, 2004 [Page 17] Internet-Draft Identified Internet Mail June 2004 5.1.3 Misappropriated private key If the private key for a user is resident on their computer and is not protected by an appropriately secure passphrase, it is possible for malware to send mail as that user. The malware would, however, not be able to spoof other senders' addresses, which would aid in identification of the infected user and would limit the possibilities for certain types of attacks involving socially-engineered messages. For example, the malware would not be able to pose as the Microsoft Windows Update distribution center. A larger problem occurs if malware on many users' computers obtains the private keys for those users and transmits them via a covert channel to a site where they may be shared. The compromised users would likely not know of the misappropriation until they receive "bounce" messages from messages they are supposed to have sent. Many users may not understand the significance of these bounce messages and would not take action. One countermeasure is to use a passphrase, although users tend to choose weak passphrases. Nevertheless, the decoded private key might be briefly available to compromise by malware when it is entered, or might be discovered via keystroke logging. The added complexity of entering a passphrase each time one sends a message would also tend to discourage the use of a secure passphrase. A somewhat more effective countermeasure is to send messages through an outgoing MTA that can authenticate the sender and will sign the message using its key which is normally authorized for all addresses in the domain. Such an MTA can also apply controls on the volume of outgoing mail each user is permitted to originate in order to further limit the ability of malware to generate bulk email. 5.1.4 Message Replay Attack In this attack, a spammer sends a message to be spammed to an accomplice, which results in the message being signed by the originating MTA (presuming that the sender doesn't have a valid individual key for the domain). The accomplice resends the message, including the original signature, to a large number of recipients, possibly by sending the message to many compromised machines that act as MTAs. The messages, not having been modified by the accomplice, have valid signatures. Several techniques for dealing with this type of attack have been considered. One is to include in the request to the KRS not only the fingerprint of the signing key but also a fingerprint of the signature which would allow the KRS to detect, and flag as Fenton & Thomas Expires November 30, 2004 [Page 18] Internet-Draft Identified Internet Mail June 2004 unauthorized, the use of the same signature a very large number of times. This would require the KRS to maintain a cache of signature fingerprints, and would make caching of key registration data by verifying MTAs and MUAs impossible. Both of these factors are very undesirable from a performance standpoint. In addition, some checking of message date/time fields would need to be introduced in order to allow aging of the signature cache, where currently there is no assumption that the sender have a valid real-time clock. A similar approach is for verifying MTAs and MUAs to cache the signatures themselves and detect duplications. However, only large recipient MTAs are likely to process enough of the spam messages in order to detect the duplications. Furthermore, there are legitimate use cases involving mail forwarding where the same message might take different paths to the same MTA, so this can only be applied in cases where unexpectedly large numbers of duplicate signatures are received. Other partial solutions to this problem involve the use of rating services to convey the fact that the specific envelope-from address is being used for spam, and that messages from that sender are likely to be spam. This requires a real-time detection mechanism (such as detection by the KRS as described above) in order to react quickly enough. However, such measures might be prone to abuse, if for example an attacker resent a large number of messages received from a victim in order to make them appear to be a spammer. 5.2 Other Considerations At present, a message can be forwarded giving the sender no indication as to the recipient's actual location (IP address, domain, or eventual email address) on the Internet. A sender monitoring queries to its KRS might be able to infer some of this when the recipient's MTA, or even the actual recipient, checks the identification of incoming messages. In cases where this may be sensitive, trusted proxies SHOULD be employed by the recipient and/or their domain. Fenton & Thomas Expires November 30, 2004 [Page 19] Internet-Draft Identified Internet Mail June 2004 6. Acknowledgements Dave Rossetti provided much of the original motivation to address this problem. In addition, thanks to Fred Baker, Mark Baugher, Patrik Faltstrom, Don Johnsen, Dave Oran, and Dan Wing for their suggestions and much helpful discussion around this issue. Fenton & Thomas Expires November 30, 2004 [Page 20] Internet-Draft Identified Internet Mail June 2004 7. References 7.1 Normative References [1] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 7.2 Informative References Authors' Addresses Jim Fenton Cisco Systems, Inc. MS SJ-24/2 170 W. Tasman Drive San Jose, CA 95134-1706 US Phone: +1 408 526 5914 EMail: fenton@cisco.com Michael Thomas Cisco Systems, Inc. MS SJ-21/3 170 W. Tasman Drive San Jose, CA 95134-1706 US Phone: +1 408 525 5386 EMail: mat@cisco.com Fenton & Thomas Expires November 30, 2004 [Page 21] Internet-Draft Identified Internet Mail June 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. Fenton & Thomas Expires November 30, 2004 [Page 22]