INTERNET DRAFT Mark Delany, Editor Title: draft-delany-domainkeys-base-03.txt Yahoo! Inc Expires: 28 March 2006 29 September 2005 Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys) Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract "DomainKeys" creates a domain-level authentication framework for email by using public-key technology and the DNS to prove the provenance and contents of an email. This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of "spam" and "phishing". Delany Expires March, 2006 [Page 1] Internet-Draft DomainKeys September 2005 Purpose of Submission The DomainKeys specification was a primary source from which the DomainKeys Identified Mail [DKIM] specification has been derived. The purpose in submitting this draft is as an historical reference for deployed implementations while the DKIM draft evolves. When DKIM has stabilized, this draft should be submitted as an historical or informational RFC. Delany Expires March, 2006 [Page 2] Internet-Draft DomainKeys September 2005 Table of Contents 1. Introduction 1.1 Lack of authentication is damaging Internet email 1.2 Digitally signed email creates credible domain authentication 1.3 Public-keys in the DNS 1.4 Initial deployment is likely at the border MTA 1.5 Conveying verification results to UAs 1.6 Technical minutiae are not completely covered 1.7 Motivation 1.8 Benefits of DomainKeys 1.9 Definitions 1.10 Requirements Notation 2. DomainKeys overview 3. DomainKeys detailed view 3.1 Determining the sending address of an email 3.2 Retrieving the public-key given the sending domain 3.2.1 Introducing "selectors" 3.2.2 Public-key signing and verification algorithm 3.2.3 Public-key representation in the DNS 3.2.4 Key sizes 3.3 Storing the signature in the email header 3.4 Preparation of email for transit and signing 3.4.1 Preparation for transit 3.4.2 Canonicalization for signing 3.4.2.1 The "simple" canonicalization algorithm 3.4.2.2 The "nofws" canonicalization algorithm 3.5 The signing process 3.5.1 Identifying the sending domain 3.5.2 Determining if an email should be signed 3.5.3 Selecting a private-key and corresponding selector information 3.5.4 Calculating the signature value 3.5.5 Prepending the "DomainKey-Signature:" header 3.6 Policy statement of sending domain 3.6.1 Domain policy is nascent 3.6.2 Interim sending domain policy 3.7 The verification process 3.7.1 Presumption that headers are not re-ordered 3.7.2 Verification should render a binary result 3.7.3 Selecting the most appropriate "DomainKey-Signature:" header 3.7.4 Retrieve the public-key based on the signature information 3.7.5 Verify the signature 3.7.6 Retrieving sending domain policy 3.7.7 Applying local policy 3.8 Conveying verification results to UAs 4. Example of use 4.1 The user composes an email Delany Expires March, 2006 [Page 3] Internet-Draft DomainKeys September 2005 4.2 The email is signed 4.3 The email signature is verified 5. Association with a Certificate Authority 5.1 The "DomainKey-X509:" header 6. Topics for discussion 6.1 The benefits of selectors 6.2 Canonicalization of email 6.3 Mailing lists 6.4 Roving users 7. Security Considerations 7.1 DNS 7.1.1 The DNS is not currently secure 7.1.2 DomainKeys creates additional DNS load 7.2 Key Management 7.3 Implementation risks 7.4 Privacy assumptions with forwarding addresses 7.5 Cryptographic processing is computationally intensive 8. The trial 8.1 Goals 8.2 Constraints on participation 9. Notes to Implementors 9.1 TXT records 10. References 10.1 Normative References 10.2 Informative References Appendix A - Syntax rules for the tag=value format Acknowledgments Change History Editor's Address Copyright Notice Delany Expires March, 2006 [Page 4] Internet-Draft DomainKeys September 2005 1. Introduction This document proposes an authentication framework for email that stores public-keys in the DNS and digitally signs email on a domain basis. Separate documents discuss how this framework can be extended to validate the delivery path of email as well as facilitate per-user authentication. 1.1 Lack of authentication is damaging Internet email Authentication of email is not currently widespread. Not only is it difficult to prove your own identity, it is impossible to prevent others from abusing your identity. While most email exchanges do not intrinsically need authentication beyond context, it is the rampant abuse of identity by "spammers", "phishers", and their criminal ilk that makes proof necessary. In other words, authentication is as much about protection as proof. Importantly, the inability to authenticate email effectively delegates much of the control of the disposition of inbound email to the sender, since senders can trivially assume any email address. Creating email authentication is the first step to returning dispositional control of email to the recipient. For the purposes of this document, authentication is seen from a user perspective, and is intended to answer the question "who sent this email?" where "who" is the email address the recipient sees and "this email" is the content that the recipient sees. 1.2 Digitally signing email creates credible domain authentication DomainKeys combines public-key cryptography and the DNS to provide credible domain-level authentication for email. When an email claims to originate from a certain domain, DomainKeys provides a mechanism by which the recipient system can credibly determine that the email did in fact originate from a person or system authorized to send email for that domain. The authentication provided by DomainKeys works in a number of scenarios in which other authentication systems fail or create complex operational requirements. These include: o forwarded email o distributed sending systems Delany Expires March, 2006 [Page 5] Internet-Draft DomainKeys September 2005 o authorized third-party sending This base definition of DomainKeys is intended to primarily enable domain-level authenticity; whether a given message is really sent by the purported user within the domain is outside the scope of the base definition. Having said that, this specification includes the possibility that some domains may wish to delegate fine-grained authentication to individual users. 1.3 Public-keys in the DNS DomainKeys differs from traditional hierarchical public-key systems in that it leverages the DNS for public-key management, placing complete and direct control of key generation and management with the owner of the domain. That is, if you have control over the DNS for a given domain, you have control over your DomainKeys for that domain. The DNS is proposed as the initial mechanism for publishing public-keys. DomainKeys is specifically designed to be extensible to other key fetching services as they become available. 1.4 Initial deployment is likely at the border MTA For practical reasons, it is expected that initial implementations of DomainKeys will be deployed on MTAs that accept or relay email across administrative or organizational boundaries. There are numerous advantages to deployment at the border MTA, including: o a reduction in the number of MTAs that have to be changed to support an implementation of DomainKeys o a reduction in the number of MTAs involved in transmitting the email between a signing system and a verifying system, thus reducing the number of places that can make accidental changes to the contents o removing the need to implement DomainKeys within an internal email network. However there is no necessity to deploy DomainKeys at the border as signing and verifying can effectively occur anywhere from the border MTA right back to the UA. In particular the best place to sign an email for many domains is likely to be at the point of SUBMISSION where the sender is often authenticated through SMTP AUTH or other identifying mechanisms. 1.5 Conveying verification results to UAs Delany Expires March, 2006 [Page 6] Internet-Draft DomainKeys September 2005 It follows that testing the authenticity of an email results in some action based on the results of the test. Oftentimes the action is to notify the UA in some way - typically via a header line. As alluded to in previous versions of this draft, a standard header to communicate authentication results has been defined in [AUTH-HEADER]. Henceforth, all implementations of DomainKeys should use the "Authentication-Results:" header instead of the previously defined "Domainkey-Status:" header. 1.6 Technical minutiae are not completely covered The intent of this draft is to communicate the fundamental characteristics of DomainKeys for an implementor. However some aspects are derived from the functionality of the openssl command [OPENSSL] and, rather than duplicate that documentation, implementors are expected to understand the mechanics of the openssl command, sufficient to complete the implementation. 1.7 Motivation The motivation for DomainKeys is to define a simple, cheap, and "sufficiently effective" mechanism by which domain owners can control who has authority to send email using their domain. To this end, the designers of DomainKeys set out to build a framework which: o is transparent and compatible with the existing email infrastructure o requires no new infrastructure o can be implemented independently of clients in order to reduce deployment time o does not require the use of a central certificate authority which might impose fees for certificates or introduce delays to deployment o can be deployed incrementally While we believe that DomainKeys meets these criteria, it is by no means a perfect solution. The current Internet imposes considerable compromises on any similar scheme, and readers should be careful not to misinterpret the information provided in this document to imply that DomainKeys makes stronger credibility statements than it is able to do. 1.8 Benefits of DomainKeys Delany Expires March, 2006 [Page 7] Internet-Draft DomainKeys September 2005 As the reader will discover, DomainKeys is solely an authentication system. It is not a magic bullet for spam, nor is it an authorization system, a reputation system, a certification system, or a trust system. However, a strong authentication system such as DomainKeys creates an unimpeachable framework within which comprehensive authorization systems, reputations systems and their ilk can be developed. 1.9 Definitions With reference to the following sample email: Line Data Number Bytes Content ---- --- -------------------------------------------- 01 46 From: "Joe SixPack" 02 40 To: "Suzie Q" 03 25 Subject: Is dinner ready? 04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 05 40 Comment: This comment has a continuation 06 51 because this line begins with folding white space 07 60 Message-ID: <20030712040037.46341@football.example.com> 08 00 09 03 Hi. 10 00 11 37 We lost the game. Are you hungry yet? 12 00 13 04 Joe. 14 00 15 00 Line 01 is the first line of the email and the first line of the headers. Line 05 and 06 constitute the "Comment:" header. Line 06 is a continuation header line. Line 07 is the last line of the headers. Line 08 is the empty line that separates the header from the body. Line 09 is the first line of the body. Line 10, 12, 14 and 15 are empty lines. Line 13 is the last non-empty line of the email. Delany Expires March, 2006 [Page 8] Internet-Draft DomainKeys September 2005 Line 15 is the last line of the body and the last line of the email. Line 01 to 15 constitute the complete email. Line 01 is earlier than line 02 and line 02 is later than line 01. 1.10 Requirements notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119]. 2. DomainKeys overview Under DomainKeys, a domain owner generates one or more private/public key-pairs that will be used to sign messages originating from that domain. The domain owner places the public-key in his domain namespace (i.e., in a DNS record associated with that domain), and makes the private-key available to the outbound email system. When an email is submitted by an authorized user of that domain, the email system uses the private-key to digitally sign the email associated with the sending domain. The signature is added as a header to the email, and the message is transferred to its recipients in the usual way. When a message is received with a DomainKey signature header, the receiving system can verify the signature as follows: 1. Extract the signature and claimed sending domain from the email. 2. Fetch the public-key from the claimed sending domain namespace. 3. Use public-key to determine whether the signature of the email has been generated with the corresponding private-key, and thus whether the email was sent with the authority of the claimed sending domain. In the event that an email arrives without a signature or when the signature verification fails, the receiving system retrieves the policy of the claimed sending domain to ascertain the preferred disposition of such email. Armed with this information, the recipient system can apply local policy based on the results of the signature test. Delany Expires March, 2006 [Page 9] Internet-Draft DomainKeys September 2005 3. DomainKeys detailed view This section discusses the specifics of DomainKeys that are needed to create interoperable implementations. This section answers the following questions: Given an email, how is the sending domain determined? How is the public-key retrieved for a sending domain? As email transits the email system, it can potentially go through a number of changes. Which parts of the email are included in the signature and how are they protected from such transformations? How is the signature represented in the email? If a signature is not present, or a verification fails, how does the recipient determine the policy intent of the sending domain? Finally, on verifying the authenticity of an email, how is that result conveyed to participating UAs? While there are many alternative design choices, most lead to comparable functionality. The overriding selection criteria used to choose amongst the alternatives are: o use deployed technology whenever possible o prefer ease of implementation o avoid trading risk for excessive flexibility or interoperability o include basic flexibility Adherence to these criteria implies that some existing email implementations will require changes to participate in DomainKeys. Ultimately some hard choices need to be made regarding which requirements are more important. 3.1 Determining the sending address of an email The goal of DomainKeys is to give the recipient confidence that the email originated from the claimed sender. As with much of Internet email, agreement over what constitutes the "sender" is no easy matter. Forwarding systems and mailing lists add serious complications to an overtly simple question. From the point of view of the recipient, the authenticity claim should be directed at the domain most visible to the recipient. In the first instance, the most visible address is clearly the RFC2822 Delany Expires March, 2006 [Page 10] Internet-Draft DomainKeys September 2005 "From:" address [RFC2822]. Therefore, a conforming email MUST contain a single "From:" header from which an email address with a domain name can be extracted. A conforming email MAY contain a single RFC2822 "Sender:" header from which an email address with a domain name can be extracted. If the email has a valid "From:" and a valid "Sender:" header, then the signer MUST use the sending address in the "Sender:" header. If the email has a valid "From:" and no "Sender:" header, then the signer MUST use the first sending address in the "From:" header. In all other cases, a signer MUST NOT sign the email. Implementors should note the an email with a "Sender:" header and no "From:" header MUST NOT be signed. The domain name in the sending address constitutes the "sending domain". 3.2 Retrieving the public-key given the sending domain To avoid namespace conflicts, it is proposed that the DNS namespace "_domainkey." be reserved within the sending domain for storing public-keys, e.g., if the sending domain is example.net, then the public-keys for that domain are stored in the _domainkey.example.net namespace. 3.2.1 Introducing "selectors" To support multiple concurrent public-keys per sending domain, the DNS namespace is further subdivided with "selectors". Selectors are arbitrary names below the "_domainkey." namespace. A selector value and length MUST be legal in the DNS namespace and in email headers with the additional provision that they cannot contain a semicolon. Examples of namespace using selectors are: "coolumbeach._domainkey.example.net" "healdsburg._domainkey.example.net" "reykjavik._domainkey.example.net" "default._domainkey.example.net" and "2005.pao._domainkey.example.net" "2005.sql._domainkey.example.net" "2005.rhv._domainkey.example.net" Delany Expires March, 2006 [Page 11] Internet-Draft DomainKeys September 2005 Periods are allowed in selectors and are to be treated as component separators. In the case of DNS queries that means the period defines sub-domain boundaries. The number of public-keys and corresponding selectors for each domain are determined by the domain owner. Many domain owners will be satisfied with just one selector whereas administratively distributed organizations may choose to manage disparate selectors and key pairs in different regions or on different email servers. Beyond administrative convenience, selectors make it possible to seamlessly replace public-keys on a routine basis. If a domain wishes to change from using a public-key associated with selector "2005" to a public-key associated with selector "2006", it merely makes sure that both public-keys are advertised in the DNS concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the "2006" private-key. At the end of the transition period, the "2005" public-key is removed from the DNS. While some domains may wish to make selector values well known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties. E.g., if per-user keys are issued, the domain owner will need to make the decision as to whether to make this selector associated directly with the user name, or make it some unassociated random value, such as the fingerprint of the public-key. 3.2.2 Public-key signing and verification algorithm The default signature is an RSA signed SHA1 digest of the complete email. For ease of explanation, the openssl command is used throughout this document to describe the mechanism by which keys and signatures are managed. One way to generate a 768 bit private-key suitable for DomainKeys, is to use openssl like this: $ openssl genrsa -out rsa.private 768 Which results in the file rsa.private containing the key information similar to this: -----BEGIN RSA PRIVATE KEY----- MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH Delany Expires March, 2006 [Page 12] Internet-Draft DomainKeys September 2005 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= -----END RSA PRIVATE KEY----- Once a private-key has been generated, the openssl command can be used to sign an appropriately prepared email, like this: $ openssl dgst -sign rsa.private -sha1 To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. 4.2 The email is signed This email is signed by the football.example.com outbound email server and now looks like this: DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR; Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] by submitserver.football.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: "Joe SixPack" To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Delany Expires March, 2006 [Page 29] Internet-Draft DomainKeys September 2005 The signing email server requires access to the private-key associated with the "brisbane" selector to generate this signature. Distribution and management of private-keys is outside the scope of this document. 4.3 The email signature is verified The signature is normally verified by an inbound SMTP server or possibly the final delivery agent. However, intervening MTAs can also perform this verification if they choose to do so. The verification process uses the domain "football.example.com" extracted from the "From:" header and the selector "brisbane" from the "DomainKey-Signature:" header to form the DNS TXT query for: brisbane._domainkey.football.example.com Since there is no "h" tag in the "DomainKey-Signature:" header, signature verification starts with the line following the "DomainKey-Signature:" line. The email is canonically prepared for verifying with the "simple" method. The result of the query and subsequent verification of the signature is stored in the "Authentication-Results:" header line. After successful verification, the email looks like this: Authentication-Results: auth-checker.example.com from=joe@football.example.com; domainkeys=pass Received: from mout23.brisbane.football.example.com (192.168.1.1) by shopping.example.net with SMTP; Fri, 11 Jul 2003 21:01:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR; Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] by submitserver.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: "Joe SixPack" To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Delany Expires March, 2006 [Page 30] Internet-Draft DomainKeys September 2005 5. Association with a Certificate Authority A fundamental aspect of DomainKeys is that public-keys are generated and advertised by each domain at no additional cost. This accessibility markedly differs from traditional Public Key Infrastructures where there is typically a Certificate Authority (CA) who validates an applicant and issues a signed certificate - containing their public-key - for a recurring fee. While CAs do impose costs, they also have the potential to provide additional value as part of their certification process. Consider financial institutions, public utilities, law enforcement agencies and the like. In many cases, such entities justifiably need to discriminate themselves above and beyond the authentication that DomainKeys offers. Creating a link between DomainKeys and CA issued certificates has the potential to access additional authentication mechanisms that are more authoritative than domain owner issued authentication. It is well beyond the scope of this specification to describe such authorities apart from defining how the linkage could be achieved with the "DomainKey-X509:" header. 5.1 The "DomainKey-X509:" header The "DomainKey-X509:" header provides a link between the public-key used to sign the email and the certificate issued by a CA. The exact content, syntax and semantics of this header are yet to be resolved. One possibility is that this header contains an encoding of the certificate issued by a CA. Another possibility is that this header contains a URL that points to a certificate issued by a CA. In either case, this header can only be consulted if the signature verifies and MUST be part of the content signed by the corresponding "DomainKey-Signature:" header. Furthermore, it is likely that MUAs rather than MTAs will confirm that the link to the CA issued certificate is valid. In part this is because many MUAs already have built-in capabilities as a consequence of S/MIME [RFC1847] and SSL [SSL] support. The proof of linkage is made by testing that the public-key in the certificate matches the public-key used to sign the email. An example of a email containing the "DomainKey-X509:" header is: DomainKey-Signature: a=rsa-sha1; s=statements; d=largebank.example.com; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ Delany Expires March, 2006 [Page 31] Internet-Draft DomainKeys September 2005 VoG4ZHRNiYzR; DomainKey-X509: https://ca.example.net/largebank.example.com From: "Large Bank" To: "Suzie Q" Subject: Statement for Account: 1234-5678 ... The format of the retrieved value from the URL is not yet defined, nor is the determination of valid CAs. The whole matter of linkage to CA issued certificates is one aspect of DomainKeys that needs to be resolved with relevant CA and certificate issuing entities. The primary point is that a link is possible to a higher authority. 6. Topics for discussion 6.1 The benefits of selectors Selectors are at the heart of the flexibility of DomainKeys. A domain administrator is free to use a single DomainKey for all outbound mail. Alternatively, they may use many DomainKeys differentiated by selector and assign each key to different servers. For example, a large outbound email farm might have a unique DomainKey for each server, and thus their DNS will advertise potentially hundreds of keys via their unique selectors. Another example is a corporate email administrator who might generate a separate DomainKey for each regional office email server. In essence, selectors allow a domain owner to distribute authority to send on behalf of that domain. Combined with the ability to revoke by removal or TTL expiration, a domain owner has coarse-grained control over the duration of the distributed authority. Selectors are particularly useful for domain owners who want to contract a third-party mailing system to send a particular set of mail. The domain owner can generate a special key pair and selector just for this mail-out. The domain owner has to provide the Private Key and selector to the third party for the life of the mail-out. However, as soon as the mail-out is completely delivered, the domain owner can revoke the public-key by the simple expedient of removing the entry from the DNS. 6.2 Canonicalization of email It is an unfortunate fact that some email software routinely (and Delany Expires March, 2006 [Page 32] Internet-Draft DomainKeys September 2005 often unnecessarily) transforms email as it transits through the network. Such transformations conflict with the fundamental purpose of cryptographic signatures - to detect modifications. While two canonicalization algorithms are defined in this specification, the primary goal of "nofws" is to provide a transition path to "simple". With a mixture of "simple" and "nofws" email, a receiver can determine which systems are modifying email in ways that cause the signature to fail and thus provide feedback to the modifying system. 6.3 Mailing lists Mailing list managers (MLMs) that modify email in a way that causes signatures to fail, MUST pre-pend a "Sender:" header and arrange for the email to be resigned as it is distributed to the list recipients. A participating SUBMISSION server can deduce the need to resign such an email by the presence of a "Sender:" header from an authorized submission. 6.4 Roving users One scenario that presents a particular problem with any form of email authentication, including DomainKeys, is the roving user. A user who is obliged to use a third-party SUBMISSION service when unable to connect to their own SUBMISSION service. The classic example cited is a traveling salesperson being redirected to a hotel email server to send email. As far as DomainKeys is concerned, email of this nature clearly originates from an email server that does not have authority to send on behalf of the domain of the salesperson and is therefore indistinguishable from a forgery. While DomainKeys does not prescribe any specific action for such email it is likely that over time, such email will be treated as second class email. The typical solution offered to roving users is to submit email via an authorized server for their domain - perhaps via a VPN or a web interface or even SMTP AUTH back to a SUBMISSION server. While these are perfectly acceptable solutions for many, they are not necessarily solutions that are available or possible for all such users. One possible way to address the needs of this contingent of potentially disenfranchised users, is for the domain to issue per-user DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag value in the corresponding DNS record. Delany Expires March, 2006 [Page 33] Internet-Draft DomainKeys September 2005 7. Security Considerations 7.1 DNS DomainKeys is primarily a security mechanism. Its core purpose is to make claims about email authentication in a credible way. However, DomainKeys, like virtually all Internet applications, relies on the DNS which has well-known security flaws [RFC3833]. 7.1.1 The DNS is not currently secure While the DNS is currently insecure, it is expected that the security problems should and will be solved by DNSSEC [DNSSEC], and all users of the DNS will reap the benefit of that work. Secondly, the types of DNS attacks relevant to DomainKeys are very costly and are far less rewarding than DNS attacks on other Internet applications. To systematically thwart the intent of DomainKeys, an attacker must conduct a very costly and very extensive attack on many parts of the DNS over an extended period. No one knows for sure how attackers will respond, however the cost/benefit of conducting prolonged DNS attacks of this nature is expected to be uneconomical. Finally, DomainKeys is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as GnuPG and S/MIME address those requirements. 7.1.2 DomainKeys creates additional DNS load A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching Selector-based data as well as fetching sending domain policy. Widespread deployment of DomainKeys will result in a significant increase in DNS queries to the claimed sending domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries. 7.2 Key Management All public-key systems require management of key pairs. Private-keys in particular need to be securely distributed to each signing mail server and protected on those servers. For those familiar with SSL, the key management issues are similar to those of managing SSL Delany Expires March, 2006 [Page 34] Internet-Draft DomainKeys September 2005 certificates. Poor key management may result in unauthorized access to private-keys, which in essence gives unauthorized access to your identity. 7.3 Implementation Risks It is well recognized in cryptographic circles that many security failures are caused by poor implementations rather than poor algorithms. For example, early SSL implementations were vulnerable because the implementors used predictable "random numbers". While some MTA software already supports various cryptographic techniques, such as TLS, many do not. This proposal introduces cryptographic requirements into MTA software which implies a much higher duty of care to manage the increased risk. There are numerous articles, books, courses, and consultants that help programming security applications. Potential implementors are strongly encouraged to avail themselves of all possible resources to ensure secure implementations. 7.4 Privacy assumptions with forwarding addresses Some people believe that they can achieve anonymity by using an email forwarding service. While this has never been particularly true as bounces, over-quota messages, vacation messages and web bugs all conspire to expose IP addresses and domain names associated with the delivery path, the DNS queries that are required to verify DomainKeys signature can provide additional information to the sender. In particular, as mail is forwarded through the mail network, the DNS queries for the selector will typically identify the DNS cache used by the forwarding and delivery MTAs. 7.5 Cryptographic processing is computationally intensive Verifying a signature is computationally significant. Early indications are that a typical mail server can expect to increase CPU demands by 8-15 percent. While this increased demand is modest compared to other common mail processing costs - such as Bayesian filtering - any increase in resource requirements can make a denial-of-service attack more effective against a mail system. A constraining factor of such attacks is that the net computational cost of verifying is bounded by the maximum key size allowed by this specification and is essentially linear to the rate at which mail is accepted by the verifying system. Consequently, the additional computational cost may augment a denial-of-service attack, but it does Delany Expires March, 2006 [Page 35] Internet-Draft DomainKeys September 2005 not add a non-linear component to such attacks. 8. The trial Since the publication of the last version of this specification, a considerable number of both small and large organizations have developed and deployed DomainKeys to authenticate email. Additionally, Open Source implementations are available at various places, particularly Source Forge [SOURCEFORGE] which has links to numerous implementations, both Open Source and commercial. Interested parties are encouraged to participate in this trial and help evolve this specification based on those experiences. 8.1 Goals The primary goals of the trial are to: o understand the operational implications of running a DNS-based public-key system for email o measure the effectiveness of the canonicalization algorithms o experiment with possible per-user key deployment models o fully define the semantics of the "DomainKey-X509:" header 8.2 Constraints on participation Participants should understand that this specification has evolved over the last year and will likely change again as requirements are further refined. While dramatic changes are not expected and every effort is being made to minimize gratuitous changes, participants should be prepared to adopt such changes as they arise. Since early DomainKey implementations may be less than perfect and that senders may be merely testing their implementations, recipient systems should be reticent about applying strict policy to unverified email. Particularly if the sending domain policy or the selector information has the testing mode set. 9. Notes to Implementors 9.1 TXT records The DNS is very flexible in that it is possible to have multiple TXT records for a single name and for those TXT records to contain Delany Expires March, 2006 [Page 36] Internet-Draft DomainKeys September 2005 multiple strings. In all cases, implementors of DomainKeys should expect a single TXT record for any particular name. If multiple TXT records are returned, the implementation is free to pick any single TXT record as the authoritative data. In other words, if a name server returns different TXT records for the same name, it can expect unpredictable results. Within a single TXT record, implementors should concatenate multiple strings in the order presented and ignore string boundaries. Note that a number of popular DNS command-line tools render multiple strings as separately quoted strings which can be misleading to a novice implementor. 10. References 10.1 Normative References [AUTH-HEADER] http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header [MIME] Borenstein, N., Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies ", RFC 2045, November, 1996. [OPENSSL] http://www.openssl.org [PEM] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421 February, 1993. 10.2 Informative References [DKIM] http://www.ietf.org/internet-drafts/draft-allman-dkim-base [DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html [RFC1847] Galvin, J., Murphy, S., Crocker, S., Freed, N., "Security Multiparts for MIME", RFC 1847, October, 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001. [RFC3833] Atkins, D., Austein, R., "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August, 2004. Delany Expires March, 2006 [Page 37] Internet-Draft DomainKeys September 2005 [SOURCEFORGE] http://domainkeys.sourceforge.net [SSL] http://wp.netscape.com/security/techbriefs/ssl.html Delany Expires March, 2006 [Page 38] Internet-Draft DomainKeys September 2005 Appendix A - Syntax rules for the tag=value format A simple tag=value syntax is used to encode data in the response values for DNS queries as well as headers embedded in emails. In a later draft, a formal grammar will be used to precisely define the rules, for now, this section summarized the most salient syntactic rules for this encoding: o A tag=value pair consists of three tokens, a "tag", the "=" character and the "value" o A tag MUST be one character long and MUST be a lower-case alphabetic character o Duplicate tags are not allowed o A value MUST only consist of characters that are valid in RFC2822 headers, DNS TXT records and are within the ASCII range of characters from SPACE (0x20) to TILDE (0x7E) inclusive. Values MUST NOT contain a semicolon but they may contain "=" characters. o A tag=value pair MUST be terminated by a semicolon or the end of the data o Values MUST be processed as case sensitive unless the specific tag description of semantics imply case insensitivity. o Values MAY be zero bytes long o Whitespace MAY surround any of the tokens, however whitespace within a value MUST be retained unless explicitly excluded by the specific tag description. Currently the only tags that specifically ignores embedded whitespace are the "b" and "h" tag in the "DomainKey-Signature:" header. o Tag=value pairs that represent the default value MAY be included to aid legibility. o Unrecognized tags MUST be ignored Delany Expires March, 2006 [Page 39] Internet-Draft DomainKeys September 2005 Acknowledgments The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki, Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy, Jutta Degener, Jim Fenton, Duncan Findlay, Phillip Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their valuable suggestions and constructive criticism. Change History This document is a revision of the previous version named draft-delany-domainkeys-base-02.txt. For the convenience of those familiar with the previous version, the major changes are summarized here: 1. Cleaned up typographical and grammatical errors 2. Clarify that d= and h= tag values are case insensitive Editor's Address Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA Email: domainkeys-feedbackbase03@yahoo.com Please send comments to the editor at the above address. This feedback email address will remain valid until this draft expires or is replaced with a subsequent revision. Delany Expires March, 2006 [Page 40] Internet-Draft DomainKeys September 2005 Copyright Notice 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. 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. RCS: $Id: draft-delany-domainkeys-base-03.txt,v 1.2 2005/09/26 20:12:55 markd Exp $ Delany Expires March, 2006 [Page 41]