DomainKeys Identified Mail T. Hansen Internet-Draft AT&T Laboratories Intended status: Informational D. Crocker Expires: December 13, 2007 Brandenburg InternetWorking P. Hallam-Baker VeriSign Inc. June 11, 2007 DomainKeys Identified Mail (DKIM) Overview draft-ietf-dkim-overview-05 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. 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 December 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract DomainKeys Identified Mail (DKIM) associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate. [RFC4871] DKIM defines a domain-level authentication framework for email using public-key cryptography and key server technology. This permits verifying the source or intermediary for a Hansen, et al. Expires December 13, 2007 [Page 1] Internet-Draft DKIM Service Overview June 2007 message, as well as the contents of messages. The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting the identity associated with the message and the integrity of the messages itself, while retaining the functionality of Internet email as it is known today. Such protection of email identity may assist in the global control of "spam" and "phishing". This document provides an overview of DKIM, describes how it can fit into a messaging service, describes how it relates to other IETF message signature technologies, and includes implementation and migration considerations. Table of Contents 1. DKIM Framework . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Function . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Service Architecture . . . . . . . . . . . . . . . . . . . 13 2. Deployment and Operation of DKIM Base . . . . . . . . . . . . 15 2.1. Development . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. Email Infrastructure Agents . . . . . . . . . . . . . . . 16 2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6. On-going Operations . . . . . . . . . . . . . . . . . . . 24 2.7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 27 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 4. Informative References . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Hansen, et al. Expires December 13, 2007 [Page 2] Internet-Draft DKIM Service Overview June 2007 1. DKIM Framework 1.1. Introduction DomainKeys Identified Mail (DKIM) associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate. [RFC4871] DKIM accomplishes this by defining a domain-level authentication framework for email using public-key cryptography and key server technology. This permits verifying the source or intermediary for a message, as well as the contents of messages. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments of unsigned messages. The ultimate goal of this framework is to permit a domain to assert responsibility for a message, thus proving and protecting the identity associated with the message and the integrity of the messages itself, while retaining the functionality of Internet email as it is known today. Such protection of email identity, may assist in the global control of "spam" and "phishing". This document provides a description of DKIM's architecture, functionality, deployment and use. It is intended for those who are adopting, developing, or deploying DKIM. It also will be helpful for those who are considering extending DKIM, either into other areas of use or to support additional features. This Overview does not provide information on threats to DKIM or email, or details on the protocol specifics, which can be found in [RFC4871] and [RFC4686], respectively. The document assumes a background in basic network security technology and services. It must be stressed that neither this document nor DKIM attempt to provide solutions to the world's problems with spam, phish, virii, worms, joe jobs, etc. DKIM provides one basic tool, in what needs to be a large arsenal, for improving the safety of Internet mail. However, by itself, DKIM is not sufficient to that task and this overview does not pursue the issues of integrating DKIM into these larger efforts. Rather, it is a basic introduction to the technology and its deployment. 1.1.1. The DKIM Value Proposition The nature and origins of a message are often falsely stated. As a foundation for distinguishing legitimate mail, DKIM provides a means of associating a verifiable identity with a message. Given the presence of that identity, a receiver can make decisions about further handling of the message, based upon assessments of that Hansen, et al. Expires December 13, 2007 [Page 3] Internet-Draft DKIM Service Overview June 2007 identity. Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behavior. DKIM does not, itself, prescribe any specific actions by the recipient; rather it is an enabling technology for services that do. These services will typically: 1. Verify an identity 2. Determine whether the identity is known or unknown 3. Determine whether a known identity is trusted An attack is made against an organization or against customers of an organization. The name of the organization is linked to particular Internet domain names. One point of leverage used by attackers is either to spoof a legitimate domain name, or to use a "cousin" name that is similar to one that is legitimate, but is not controlled by the target organization. A DKIM-based accreditation service can enforce a basic separation between domains used by such known organizations and domains used by others. DKIM signatures can be created by a direct handler of a message, either as its originator or as an intermediary. It can also be created by an independent service, providing assistance to a handler of the message. Whoever does the signing chooses the domain name to be used as the basis for later assessments. Hence, reputation associated with that domain name is the basis for evaluating whether to trust the message for delivery. The owner of the domain name being used for a DKIM signature is declaring that they are accountable for the message. DKIM is intended to be a value-added feature for email. Mail that is not signed by email is handled in the same way as it now is; it continues to be evaluated by established analysis and filtering techniques. Over time, widespread DKIM adoption could permit degraded handling of messages that are not signed. However early benefits do not require this more-stringent enforcement. It is important to be clear about the narrow scope of DKIM's capabilities. It is an enabling technology, intended for use in the larger context of determining message legitimacy. This larger context is complex, so that it is easy to assume that a component like DKIM, which actually provides only a limited service, instead satisfies the broader set of requirements. A DKIM signature : Hansen, et al. Expires December 13, 2007 [Page 4] Internet-Draft DKIM Service Overview June 2007 o Does not offer any assertions about the behaviors of the identity doing the signing. o Does not prescribe any specific actions for receivers to take upon successful (or unsuccessful) signature verification. o Does not provide protection after signature verification. o Does not protect against re-sending (replay of) a message that already has a verified signature; therefore a transit intermediary or a recipient can re-post the message in such a way that the signature would remain verifiable, although the new recipient(s) would not have been specified by the originator. 1.1.2. Prior Work Historical email assessment based on identity has been based on the IP Address of a system that sent the message. The Address is obtained via underlying Internet information mechanisms and is therefore trusted to be accurate. Besides having some known security weaknesses, the use of Addresses present a number of functional and operational problems. Consequently there is an industry desire to use a more stable value that has had better correspondence with organizational boundaries. Domain Names are viewed as satisfying this need. There have been four previous efforts at standardizing an Internet email signature scheme: o Privacy Enhanced Mail (PEM) was first published in 1987. [RFC0989] o PEM eventually transformed into MIME Object Security Services in 1995. [RFC1848] Today, these two are only of historical interest. o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first released in 1991. [RFC1991] A later version was standardized as OpenPGP. [RFC2440] [RFC3156] [I-D.ietf-openpgp-rfc2440bis] o RSA Security independently developed Secure MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851] Development of S/MIME and OpenPGP have continued. While both have achieved a significant user base, neither have achieved ubiquity in deployment or use, and their goals differ from those of DKIM. To the extent that other message-signing services might have been Hansen, et al. Expires December 13, 2007 [Page 5] Internet-Draft DKIM Service Overview June 2007 adapted to do the job that DKIM is designed to perform, it was felt that re-purposing any of those would be more problematic than creating a separate service. That said, DKIM uses security algorithm components that have a long history, including use within some of those other messaging security services. DKIM has a distinctive approach for distributing and vouching for keys. It uses a key-centric Public Key Infrastructure (PKI) rather than the more typical approaches based on a certificate in the styles of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the owner of a key asserts its validity, rather than relying on the key having a broader semantic implication of the assertion, such as a quality assessment of the key's owner. DKIM treats quality assessment as an independent, value-added service, beyond the initial work of deploying a verifying signature service. Further, DKIM's PKI is supported by adding additional information records to the existing Domain Name Service (DNS) [RFC1034], rather than requiring deployment of a new query infrastructure. This approach has significant operational advantages. First, it avoids the considerable barrier of creating a new infrastructure; hence it leverages a global base of administrative experience and highly reliable distributed operation. Second, the technical aspect of the DNS is already known to be efficient. Any new service would have to undergo a period of gradual maturation, with potentially problematic early-stage behaviors. By (re-)using the DNS, DKIM avoids these growing pains. 1.1.3. Internet Mail Background Internet Mail has a simple split between the user world, in the form of Mail User Agents (MUA), and the transmission world, in the form of the Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is responsible for accepting a message from one User and delivering it to one or more other users, creating a virtual MUA- to-MUA exchange environment. The first MTA is called the Mail Submission Agent (MSA) and the final MTA is called the Mail Delivery Agent (MDA). Modern Internet Mail service is marked by many independent operators, many different components for providing users with service and many other components for performing message transfer. Consequently, it is necessary to distinguish administrative boundaries that surround sets of functional components. Hansen, et al. Expires December 13, 2007 [Page 6] Internet-Draft DKIM Service Overview June 2007 1.1.3.1. Administrative Actors Operation of Internet Mail services is apportioned to different providers (or operators). Each can be composed of an independent ADministrative Management Domain (ADMD). An ADMD operates with an independent set of policies and interacts with other ADMDs according to differing types and amounts of trust. Examples include: an end- user operating their desktop client that connects to an independent email service, a department operating a submission agent or a local Relay, an organization's IT group that operates enterprise Relays, and an ISP operating a public shared email service. Each of these can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 1 depicts the relationships among ADMDs. Perhaps the most salient aspect of an ADMD is the differential trust that determines its policies for activities within the ADMD, versus those involving interactions with other ADMDs. Basic components of ADMD distinction include: Edge: Independent transfer services, in networks at the edge of the Internet Mail service. User: End-user services. These might be subsumed under an Edge service, such as is common for web-based email access. Transit: These are Mail Service Providers (MSP) offering value- added capabilities for Edge ADMDs, such as aggregation and filtering. Hansen, et al. Expires December 13, 2007 [Page 7] Internet-Draft DKIM Service Overview June 2007 Note that Transit services are quite different from packet-level transit operation. Whereas end-to-end packet transfers usually go through intermediate routers, email exchange across the open Internet is often directly between the Edge ADMDs, at the email level. +-------+ +-------+ +-------+ | ADMD1 | | ADMD3 | | ADMD4 | | ----- | | ----- | | ----- | | | +---------------------->| | | | | User | | |-Edge--+--->|-User | | | | | +--->| | | | | V | | | +-------+ +-------+ | Edge--+---+ | | | | +---------+ | +-------+ | | ADMD2 | | | | ----- | | | | | | +--->|-Transit-+---+ | | +---------+ Figure 1: ADministrative Management Domains (ADMD) Example The distinction between Transit network and Edge network transfer services is primarily significant because it highlights the need for concern over interaction and protection between independent administrations. The interactions between functional components within an ADMD are subject to the policies of that domain. Common ADMD examples are: Enterprise Service Providers: Operators of an organization's internal data and/or mail services. Internet Service Providers: Operators of underlying data communication services that, in turn, are used by one or more Relays and Users. It is not necessarily their job to perform email functions, but they can, instead, provide an environment in which those functions can be performed. Mail Service Providers: Operators of email services, such as for end-users, or mailing lists. Hansen, et al. Expires December 13, 2007 [Page 8] Internet-Draft DKIM Service Overview June 2007 1.1.4. Conventions In this document, references to structured fields of a message use a two-part dotted notation. The first part cites the document that contains the specification for the field and the second is the name of the field. Hence is the From field in an email content header [RFC2822] and is the address in the SMTP "Mail From" command. [RFC2821] This document is being discussed on the DKIM mailing list, ietf-dkim@mipassoc.org. 1.2. Goals DKIM seeks to add authentication to the existing email transfer infrastructure. This motivates functional goals about authentication and operational goals about integration with the existing email service. 1.2.1. Functional Use Domain-level granularity for assurance. OpenPGP and S/MIME apply the end-to-end principle in terms of individual originators and recipients, notably using full email addresses. DKIM seeks accountability at the more coarse grain of an organization or, perhaps, a department. A deployed construct that enables this granularity is the domain name, to which the signing key record is bound. Further DKIM signing and/or validating may be implemented anywhere along the transit path, rather than only in the end systems. Allow delegation of signing to independent parties. Different parties have different roles in the process of email exchange. Some of these parties are easily visible to end users and others are primarily visible to operators of the service. DKIM needs to support signing by any of these different parties and needs to permit them to sign with any domain name that they deem appropriate. As an example an organization that creates email content often delegates portions of its processing or transmission to an outsourced group. DKIM must support this mode of activity, in a manner that is not visible to end users. Distinguish the core authentication mechanism from its derivative uses. An authenticated identity may be subject to a variety of processing policies, either ad hoc or standardized. The only semantics inherent to a DKIM signature is that the signer is asserting (some) responsibility for the message. All other mechanisms and meanings are independent of this core service. One Hansen, et al. Expires December 13, 2007 [Page 9] Internet-Draft DKIM Service Overview June 2007 such mechanism might assert a relationship between the signing identity and the author () domain identity. Another might specify how to treat an unsigned message with that domain. Retain ability to have anonymous email. The ability to send a message that does not identify its author is considered to be a valuable quality of the current email system that needs to be retained. DKIM is compatible with this goal since it permits an email system operator to be authenticated, rather than the content author. Knowing that a mail definitely came from example.com does not threaten the anonymity of the user, if it is still possible to obtain effectively anonymous accounts at example.com and other mail providers. 1.2.2. Operational Make signature transparent to non-supporting recipients. S/MIME and OpenPGP both modify the message body. Hence, their presence is potentially visible to email recipients and their user software must be able to process the associated constructs. In order to facilitate incremental adoption, DKIM is designed to be transparent to recipients that do not support it. Treat verification failure the same as no signature unsigned. OpenPGP and S/MIME were both designed for strong cryptographic protection. This included treating verification failure as message failure. As a sub-goal to the requirement for transparency, a DKIM signature verifier is to treat messages with signatures that fail as if they were unsigned. Hence the message will revert to normal handling, through the receiver's existing filtering mechanisms. Permit incremental adoption for incremental benefit. DKIM can immediately provide benefits between any two organizations that exchange email and implement DKIM. In the usual manner of "network effects", the benefits of DKIM increase dramatically as its adoption increases. Although it is envisioned that this mechanism will call upon independent services to aid in the assessment of DKIM results, they are not essential in order to obtain an initial benefit. For example DKIM allows (possibly large) pair-wise sets of email providers and spam filtering companies to distinguish mail that is associated with a known organization, from mail that might deceptively purport to have the affiliation. This in turn allows the development of 'whitelist' schemes whereby authenticated mail from a known source with good reputation is allowed to bypass some Hansen, et al. Expires December 13, 2007 [Page 10] Internet-Draft DKIM Service Overview June 2007 spam filters. In effect the email receiver is using their set of known relationships to generate their own accreditation/reputation data. This works particularly well for traffic between large sending providers and large receiving providers. However it also works well for any operator, public or private, that has mail traffic dominated by exchanges among a stable set of organizations. Minimize the amount of required infrastructure. A new service, or an enhancement to an existing service, requires adoption by some number of systems, before it can be useful. The greater the number of required adopters, the higher the adoption barrier. This becomes particularly serious when adoption is required by intermediary -- that is, infrastructure -- service providers. In order to allow early adopters to gain early benefit, DKIM seeks to make no changes to the core Internet Mail service and, instead, to allow a useful benefit for any signer/verifier pair of participants exchanging mail. Similarly, DKIM's reliance on the Domain Name Service greatly reduces the amount of new administrative infrastructure that must be deployed over the open Internet. Permit wide range of deployment choices. It should be possible to implement DKIM at a variety of places within an organization's email service. This permits the organization to choose how much or how little they want DKIM to be part of their service, rather than part of a more localized operation. 1.3. Function DKIM has a very constrained set of capabilities, primarily targeting email while it is in transit, from an originator to a set of recipients. It creates the ability to associate verifiable information with a message, especially a responsible identity. When a message is not signed, DKIM permits the identity of the sender to be used for obtaining information about their signing practices. 1.3.1. The Basic Signing Service With the DKIM signature mechanism, a signer associates a domain name with an address, performs digital signing on the message, and records signature information in a DKIM header field. A verifier obtains the domain name from the DKIM header field, queries for a public key associated with the name, and verifies the signature. DKIM permits any domain name to be use for signing, and supports extensible choices for various algorithms. As is typical for Hansen, et al. Expires December 13, 2007 [Page 11] Internet-Draft DKIM Service Overview June 2007 Internet standards, there is a core set of algorithms required to be supported by all implementations. This ensures an initial ability to interoperate. DKIM permits restricting the use of a signature key to particular types of services, such as only for email. This is helpful when delegating signing authority, such as to a particular department or to a third-party outsourcing service. With DKIM the signer MUST explicitly list the headers that are signed. By choosing the minimal set of headers needed the signature is likely to be considerably more robust against the handling vagaries of intermediary MTAs. 1.3.2. Characteristics of a DKIM signature A DKIM signature covers the message body and selected header fields. The signer computes a hash of the selected header fields and another hash of the body. The signer then uses a private key to cryptographically encode this information, along with other signing parameters. Signature information is placed into a new [RFC2822] header field of the message. 1.3.3. The Selector construct A signature is associated with a domain name, as specified in the "d=" DKIM parameter. That domain name is the complete identity used for making assessments about the signer. However this name is not sufficient for making a query to obtain the key needed to verify the signature. A single domain can use multiple signing keys and/or multiple signers. To support this, DKIM identifies a particular signature as a combination of the domain name and an added field, called the "selector". Both of these are coded into the DKIM-Signature header field. It must be stressed that the selector is not part of the domain name that is used for making assessments. Rather, the selector is strictly reserved for use in administering keys that are associated with the domain name. If the selector becomes part of a name assessment mechanism, then there is no remaining mechanism for making a transition from an old, or compromised, key to a new one. Signers do have the need for supporting multiple assessments about their organization, such as to distinguish one type of message from another, or one portion of the organization from another. To permit assessments that are independent, an organization should use Hansen, et al. Expires December 13, 2007 [Page 12] Internet-Draft DKIM Service Overview June 2007 different sub-domains in the "d=" parameter, such as "transaction.example.com" versus "newsletter.example.com", or productA.example.com versus productB.example.com. 1.3.4. Verification After a message has been signed, any agent in the message transit path can choose to verify the signature, to determine that the signing identity took responsibility for the message. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. Typically, verification will be done by an agent in the ADMD of the message recipient. 1.4. Service Architecture The DKIM service is divided into components that can be performed using different, external services, such as for key retrieval. However the basic DKIM signing specification defines an initial set of these services, in order to ensure a basic level of interoperability. Hansen, et al. Expires December 13, 2007 [Page 13] Internet-Draft DKIM Service Overview June 2007 | |- RFC2822 Message V +------------------------------+ | ORIGINATING OR RELAYING ADMD | | | +..>| Sign Message | . +--------------+---------------+ . | .private | +---+---+ | +-----------+ | Key | | | Sender | | Store | [Internet] | Practices | +---+---+ | +-----+-----+ .public | . . V . . +------------------------------+ . . | RELAYING OR DELIVERING ADMD | . . | | . . | Message Signed? | . . +-------+----------------+-----+ . . |yes |no . . V V . . +-----------+ +-----------+ . +.....>| Verify | +..>| Check |<..+ | Signature | | | Practices | +---+-----+-+ | +---+-------+ | | | | | +---+ | |pass fail | V | +--------+ | +.......>| Assess | | . | Signer | | . +---+----+ | . assessment| | . +------+ +------+ . | | +-+----------+ V V | Reputation | +-----------+ +-----+------+ | Message | | Filtering | | Engine | +-----------+> Figure 2: DKIM Service Architecture As shown in the Figure, basic message processing is divided between Hansen, et al. Expires December 13, 2007 [Page 14] Internet-Draft DKIM Service Overview June 2007 signing the message, verifying the signature or determining whether a signature was required, and then making further decisions based upon the results. Signing may be performed by a component of the ADMD that creates the message, and/or within any ADMD, along the relay path. The signer uses the appropriate private key. Verification may be performed by any functional component along the relay and delivery path. Verifiers retrieve the public key based upon the parameters stored in the message. The figure shows the verified identity as being used to assess an associated reputation, but it could be applied for other tasks, such as management tracking of mail. Note that a failed signature causes the message to be treated in the same manner as one that is unsigned. Unsigned messages prompt a query for any published "sender practices" information, as an aid in determining whether the sender information has been used without authorization. For signature verification and for the assessment of unsigned messages, the results of these processes are treated as additional input to the receiver's filtering engine. The engine determines message disposition, such as whether to deliver it. 2. Deployment and Operation of DKIM Base 2.1. Development 2.1.1. Coding Criteria for Cryptographic Applications Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications. In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers should pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of. Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes SHOULD be used when available. In particular, great care MUST be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes. Hansen, et al. Expires December 13, 2007 [Page 15] Internet-Draft DKIM Service Overview June 2007 On multiple processor and dual core architectures, certain implementations of public key algorithms such as RSA may be vulnerable to a timing analysis attack. Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys. Fortunately appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware. 2.1.2. Signer Signer implementations SHOULD provide a convenient means of generating DNS key records corresponding to the signer configuration. Support for automatic insertion of key records into the DNS is also highly desirable. If supported however, such mechanism(s) MUST be properly authenticated. A means of verifying that the signer configuration is compatible with the signature policy is also highly desirable. Disclosure of a private signature key component to a third party allows that third party to impersonate the sender. The protection of private signature key data is therefore a critical concern. Signers SHOULD support use of cryptographic hardware providing key management features. The import and export of private keys, and the ability to generate a Certificate Signing Request (CSR) for certificate registration are highly desirable. 2.2. Email Infrastructure Agents It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service, such as a department or a boundary MTA. Hansen, et al. Expires December 13, 2007 [Page 16] Internet-Draft DKIM Service Overview June 2007 Outbound: An MSA or Outbound MTA should allow for the automatic verification of the MTA configuration such that the MTA can generate an operator alert if it determines that it is (1) an edge MTA, and (2) configured to send email messages that do not comply with the published DKIM sending policy. An outbound MTA should be aware that users may employ MUAs that add their own signatures and be prepared to take steps necessary to ensure that the message sent is in compliance with the advertised email sending policy. Inbound: An inbound MTA or an MDA that does not support DKIM should avoid modifying messages in ways that prevent verification by other MTAs, or MUAs to which the message may be forwarded. An inbound MTA or an MDA may incorporate an indication of the verification results into the message, such as using an Authentication-Results header. [I-D.kucherawy-sender-auth-header] Intermediaries: An email intermediary is both an inbound and outbound MTA. Each of the requirements outlined in the sections relating to MTAs apply. If the intermediary modifies a message in a way that breaks the signature, the intermediary + SHOULD deploy abuse filtering measures on the inbound mail, and + MAY remove all signatures that will be broken In addition the intermediary MAY: + Verify the message signature prior to modification. + Incorporate an indication of the verification results into the message, such as using an Authentication-Results header. [I-D.kucherawy-sender-auth-header] + Sign the modified message including the verification results (e.g., the Authentication-Results header). 2.3. Filtering Developers of filtering schemes designed to accept DKIM authentication results as input should be aware that their implementations will be subject to counter-attack by email abusers. The efficacy of a filtering scheme cannot therefore be determined by Hansen, et al. Expires December 13, 2007 [Page 17] Internet-Draft DKIM Service Overview June 2007 reference to static test vectors alone; resistance to counter attack must also be considered. Naive learning algorithms that only consider the presence or absence of a verified DKIM signature, without considering more information about the message, are vulnerable to an attack in which a spammer or other malefactor signs all their mail, thus creating a large negative value for presence of a DKIM signature in the hope of discouraging widespread use. If heuristic algorithms are employed, they should be trained on feature sets that sufficiently reveal the internal structure of the DKIM responses. In particular the algorithm should consider the domains purporting to claim responsibility for the signature, rather than the existence of a signature or not. Unless a scheme can correlate the DKIM signature with accreditation or reputation data, the presence of a DKIM signature SHOULD be ignored. 2.4. DNS Server At a minimum, a DNS server that handles queries for DKIM key records must allow the server administrators to add free-form TXT records. It would, of course, be better for provide them with a structured form, to support the DKIM-specific fields. 2.5. Deployment This section describes the basic steps for introducing DKIM into an organization's email service operation. The considerations are divided between the generating DKIM signatures (Signing) and the processing of messages that contain a DKIM signature (Verifying). 2.5.1. Key Management Selectors Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for delegating of the right to authenticate a portion of the namespace to a trusted third party. Examples include: jun2005.eng._domainkey.example.com Hansen, et al. Expires December 13, 2007 [Page 18] Internet-Draft DKIM Service Overview June 2007 widget.promotion._domainkey.example.com NOTE: It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. This permits the selector to be used only for key administration, rather than having an effect on reputation assessment. 2.5.2. Signing Creating messages that have DKIM signatures requires a modification to only two portions of the email service: o Addition of relevant DNS information. o Addition of the signature by a trusted module within the organization's email handling service. The signing module uses the appropriate private key to create a signature. The means by which the signing module obtains the private key is not specified by DKIM. Given that DKIM is intended for use during email transit, rather than for long-term storage, it is expected that keys will be changed regularly. Clearly this means that key information should not be hard-coded into software. 2.5.2.1. DNS Records A receiver attempting to verify a DKIM signature must obtain the public key that is associated with the signature for that message. The DKIM-Signature header in the message will specify the basic domain name doing the signing and the selector to be used for the specific public key. Hence, the relevant ._domainkey. DNS record needs to contain a DKIM-related resource record (RR) that provides the public key information. The administrator of the zone containing the relevant domain name adds this information. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to add new types of DNS records. 2.5.2.2. Signing Module The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); common choices are expected to be department-level posting and delivering agents, as well as boundary MTAs to the open Internet. (Note that it is entirely acceptable for MUAs to perform signing and Hansen, et al. Expires December 13, 2007 [Page 19] Internet-Draft DKIM Service Overview June 2007 verification.) Hence the choice among the modules depends upon software development and administrative overhead tradeoffs. One perspective that helps resolve this choice is the difference between the flexibility of use by systems at (or close to) the MUA, versus the centralized control that is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA. 2.5.2.3. Signing Policies and Practices Every organization (ADMD) will have its own policies and practices for deciding when to sign messages and with what domain name and key (selector). Examples include signing all mail, signing mail from particular email addresses, or signing mail from particular sub- domains. Given this variability, and the likelihood that signing practices will change over time, it will be useful to have these decisions represented in some sort of configuration information, rather than being more deeply coded into the signing software. 2.5.3. Verifying 2.5.3.1. Verifier Verifiers SHOULD treat the result of the verification step as an input to the message evaluation process rather than as providing a final decision. The knowledge that a message is authentically sent by a domain does not say much about the legitimacy of the message, unless the characteristics of the domain claiming responsibility are known. In particular, verifiers SHOULD NOT automatically assume that an email message that does not contain a signature, or that contains a signature that does not verify, is forged. Verifiers should treat a signature that fails to verify the same as if no signature were present. Verification is performed within an ADMD that wishes to make assessments based upon the DKIM signature's domain name. Any component within the ADMD that handles messages, whether in transit or being delivered, can do the verifying and subsequent assessments. Verification and assessment might occur within the same software mechanism, such as a Boundary MTA, or an MDA. Or they may be separated, such as having verification performed by the Boundary MTA and assessment performed by the MDA. As with the signing process, choice of service venues for verification and assessment -- such as filtering or presentation to the recipient user -- depend on trade-offs for flexibility, control, Hansen, et al. Expires December 13, 2007 [Page 20] Internet-Draft DKIM Service Overview June 2007 and operational ease. An added concern is that the linkage between verification and assessment entails essential trust: the assessment module MUST have a strong basis for believing that the verification information is correct. 2.5.3.2. DNS Client The primary means of publishing DKIM key information, initially, is initially through DNS TXT records. Some DNS client software might have problems obtaining these records; as DNS client software improves this will not be a concern. 2.5.3.3. Boundary Enforcement In order for an assessment module to trust the information it receives about verification (e.g., Authentication-Results headers), it MUST eliminate verification information originating from outside the ADMD in which the assessment mechanism operates. As a matter of friendly practice, it is equally important to make sure that verification information generated within the ADMD not escape outside of it. In most environments, the easiest way to enforce this is to place modules in the receiving and sending Boundary MTA(s) that strip any existing verification information. 2.5.4. Mail User Agent DKIM is designed to support deployment and use in email components other than an MUA. However an MUA MAY also implement DKIM features directly. Outbound: If an MUA is configured to send email directly, rather than relayed through an outbound MSA, the MUA SHOULD be considered as if it were an outbound MTA for the purposes of DKIM. An MUA MAY support signing even if mail is to be relayed through an outbound MSA. In this case the signature applied by the MUA may be in addition to any MSA signature. Inbound: An MUA MAY rely on a report of a DKIM signature verification that took place at some point in the inbound MTA path (e.g., an Authentication-Results header), or an MUA MAY perform DKIM signature verification directly. A verifying MUA SHOULD allow for the case where mail is modified in the inbound MTA path. Hansen, et al. Expires December 13, 2007 [Page 21] Internet-Draft DKIM Service Overview June 2007 2.5.5. Transition strategy Deployment of a new signature algorithm without a 'flag day' requires a transition strategy such that signers and verifiers can phase in support for the new algorithm independently, and (if necessary) phase out support for the old algorithm independently. [Note: this section assumes that a security policy mechanism exists. It is subject to change.] DKIM achieves these requirements through two features: First a signed message may contain multiple signatures created by the same signer. Secondly the security policy layer allows the signing algorithms in use to be advertised, thus preventing a downgrade attack. 2.5.5.1. Signer transition strategy Let the old signing algorithm be A, the new signing algorithm be B. The sequence of events by which a Signer may introduce the new signing algorithm B, without disruption of service to legacy verifiers, is as follows: 1. Signer signs with algorithm A A. Signer advertises that it signs with algorithm A 2. Signer signs messages twice, with both algorithm A and algorithm B A. The signer tests new signing configuration B. Signer advertises that it signs with algorithm A and algorithm B 3. Signer determines that support for Algorithm A is no longer necessary 4. Signer determines that support for algorithm A is to be withdrawn A. Signer removes advertisement for Algorithm A B. Signer waits for cached copies of earlier signature policy to expire C. Signer stops signing with Algorithm A Hansen, et al. Expires December 13, 2007 [Page 22] Internet-Draft DKIM Service Overview June 2007 2.5.5.2. Verifier transition strategy The actions of the verifier are independent of the signer's actions and do not need to be performed in a particular sequence. The verifier may make a decision to cease accepting algorithm A without first deploying support for algorithm B. Similarly a verifier may be upgraded to support algorithm B without requiring algorithm A to be withdrawn. The decisions of the verifier must make are therefore: o The verifier MAY change the degree of confidence associated with any signature at any time, including determining that a given signature algorithm provides a limited assurance of authenticity at a given key strength. * A verifier MAY evaluate signature records in any order it chooses, including using the signature algorithm to choose the order. o The verifier MAY make a determination that Algorithm A does not offer a useful level of security, or that the cost of verifying the signature is less than the value of doing so. * In this case the verifier would ignore signatures created using algorithm A and references to algorithm A in policy records would be treated as if the algorithm were not implemented. o The verifier MAY decide to add support for additional signature algorithms at any time. * The verifier MAY add support for algorithm B at any time. 2.5.6. Migrating from DomainKeys 2.5.6.1. Signing DNS Records: DKIM is upwardly compatible with existing DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module does not automatically require additional DNS administration! However DKIM has enhanced the DomainKeys DNS key record format by adding several additional optional parameters. Boundary MTA: The principle use of DomainKeys is at Boundary MTAs. Because no operational transition is ever instantaneous, it is not adviseable for existing DomainKeys signers to switch to DKIM without continuing to perform DomainKeys signing. A signer should add a DKIM signature to a message that also has a Hansen, et al. Expires December 13, 2007 [Page 23] Internet-Draft DKIM Service Overview June 2007 DomainKeys signature, until such time as DomainKeys receive- side support is sufficiently reduced. With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way as DomainKeys signatures are already being used. 2.5.6.2. Verifying DNS Client: DNS queries for the DKIM key record, use the same Domain Name naming conventions as were used for DomainKeys, and the same basic record format. No changes to the DNS client should be required. Verifying module: See the section on Signing above. 2.6. On-going Operations This section describes the basic steps for operation of email systems that use DKIM, after the capability has initially been deployed. The primary considerations are: o the upkeep of the selector files, and o the security of the private keys. 2.6.1. DNS Signature Record Installation Considerations Even with use of the DNS, one challenge is that DNS record management is usually operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. The key point to remember is that the DNS DKIM selectors WILL and SHOULD be changed over time. Some reasons for changing DKIM selectors are well understood, while others are still theoretical. There are several schemes that may be used to determine the policies for changing DKIM selectors: o time based o associations with clusters of servers o the use of third party signers Hansen, et al. Expires December 13, 2007 [Page 24] Internet-Draft DKIM Service Overview June 2007 o security considerations 2.6.1.1. Time Basis and Security Considerations The reason for changing the selector periodically is usually related to the security exposure of a system. When the potential exposure of the private keys associated with the DKIM selector have reached sufficient levels, the selector should be changed. (It is unclear currently what kinds of metrics can be used to aid in deciding when the exposure has reached sufficient levels to warrant changing the selector.) For example, o Selectors should be changed more frequently on systems that are widely exposed, than on systems that are less widely exposed. For example, a gateway system that has numerous externally-accessible services running on it, is more widely exposed than one that ONLY runs a mail server. o Selectors should be changed more frequently on operating systems that are under wide attack. o While the use of DKIM information is transient, keys with sufficient exposure do become stale and should be changed. o Whenever you make a substantial system change, such as bringing up a new server, or making a major operating system change, you should consider changing the selector. o Whenever there is either suspicion or evidence of the compromise of the system or the private keys, you should change the selector. 2.6.1.2. Deploying New Selectors A primary consideration in changing the selector is remembering to change it. It needs to be a standard part of the operational staff Methods and Procedures for your systems. If they are separate, both the mail team and the DNS team will be involved in deploying new selectors. When deploying a new selector, it needs to be phased in: 1. Generate the new public / private key pair and create a new selector record with the public key in it. 2. Add the new selector record to your DNS. Hansen, et al. Expires December 13, 2007 [Page 25] Internet-Draft DKIM Service Overview June 2007 3. Verify that the new selector record can be used to verify signatures. 4. Turn on signing with the new private key. 5. Remove the old private key from your servers. 6. After a period of time, remove the old selector from your DNS. The time an unused selector should be kept in the DNS system is dependent on the reason it's being changed. If the private key has definitely been exposed, the corresponding selector should be removed immediately. Otherwise, longer periods are allowable. 2.6.1.3. Subdomain Considerations A Domain Name is the basis for making differential quality assessments about a DKIM-signed message. It is reasonable for a single organization to have a variety of very different activities, which warrant a variety of very different assessments. A convenient way to distinguish among such activities is to sign with different domain names. That is, the organization should sign with sub-domain names that are used for different organizational activities. 2.6.1.4. Third party Signature Delegations Allowing third parties to sign email from your domain opens your system security to include the security of the third party's systems. At a minimum, you should not allow the third parties to use the same selector and private key as your main mail system. It is recommended that each third party be given their own private key and selector. This limits the exposure for any given private key, and minimizes the impact if any given private key were exposed. 2.6.2. Private Key Management The permissions of private key files must be carefully managed. If key management hardware support is available, it should be used. Auditing software should be used to periodically verify that the permissions on the private key files remain secure. 2.6.3. Mailing list manager developers A mailing list often provides facilities to its administrator to manipulate parts of the mail messages that flow through the list. The desired goal is that messages flowing through the mailing list will be verifiable by the recipient as being from the list, or failing that, as being from the individual list members. Hansen, et al. Expires December 13, 2007 [Page 26] Internet-Draft DKIM Service Overview June 2007 In most cases, the list and/or its mail host SHOULD add its own DKIM signature to list mail. This could be done in the list management software, in an outgoing MSA or MTA, or both. List management software often makes modifications to messages that will break incoming signatures, such as adding subject tags, adding message headers or footers, and adding, deleting, or reordering MIME parts. By adding its own signature after these modifications, the list provides a verifiable, recognizable signature for list recipients. In some cases, the modifications made by the mailing list software are simple enough that signatures on incoming messages will still be verifiable after being remailed by the list. It is still preferable that the list sign its mail so that recipients can distinguish between mail sent through the list and mail sent directly to a list member. In the absence of a list signature, a recipient may still be able to recognize and use the original signatures of the list members. 2.7. Example Uses A DKIM signature tells the signature verifier that the owner of a particular domain name accepts responsibility for the message. Combining this information with information that allows the history of the domain name owner to be assessed may allow processing the message, based on the probability that the message is likely to be trustworthy, or not, without the need for heuristic content analysis. 2.7.1. Protection of Internal Mail One identity is particularly amenable to easy and accurate assessment: The organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization but does not contain a verifiable signature. Such mail can be presumed to be spurious. 2.7.2. Recipient-based Assessments Recipients of large volumes of email can internally generate reputation data for email senders. Recipients of smaller volumes of messages are likely to need to acquire reputation data from a third party. In either case the use of reputation data is intrinsically limited to email senders that have established a prior history of sending messages. Hansen, et al. Expires December 13, 2007 [Page 27] Internet-Draft DKIM Service Overview June 2007 In fact, an email receiving service may be in a position to establish bilateral agreements with particular senders, such as business partners or trusted bulk sending services. Although it is not practical for each recipient to accredit every sender, the definition of core networks of explicit trust can be quite useful. 2.7.2.1. Third-party Assessments For scaling efficiency, it is appealing to have Trusted Third Party assessment services, to allow an email sender to obtain a single assessment that is then recognized by every email recipient that recognizes the Trusted Third Party. 2.7.3. DKIM Support in the Client The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs. However there is nothing in DKIM that is specific to those venues. In particular, it should be possible to support signing and verifying in MUAs. However, it is common for components of an ADMD's email infrastructure to do violence to a message, such as to render a DKIM signature invalid. Hence, users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature. DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned. If verification in the client is to be acceptable to users, it is also essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. 2.7.4. Per user signatures Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer sub-domains and/or selectors in a way that supports per-user signing. NOTE: As stated earlier, it is important to distinguish between the use of selectors for differential administration of keys, versus the use of sub-domains for differential reputations. As a constraint on an authorized DKIM signing agent, their associated key record can specify restrictions on the email addresses permitted to be signed with that domain and key. A typical intent of this feature is to allow a company to delegate the signing authority for bulk marketing communications without the risk of effectively Hansen, et al. Expires December 13, 2007 [Page 28] Internet-Draft DKIM Service Overview June 2007 delegating the authority to sign messages purporting to come from the domain-owning organization's CEO. NOTE: Any scheme that involves maintenance of a significant number of public keys is likely to require infrastructure enhancements, to support that management. For example, a system in which the end user is required to generate a public key pair and transmit it to the DNS administrator out of band is not likely to meet acceptance criteria for either usability or security. 3. Acknowledgements TBD 4. Informative References [I-D.ietf-openpgp-rfc2440bis] Callas, J., "OpenPGP Message Format", draft-ietf-openpgp-rfc2440bis-22 (work in progress), April 2007. [I-D.kucherawy-sender-auth-header] Kucherawy, M., "Message Header for Indicating Sender Authentication Status", draft-kucherawy-sender-auth-header-04 (work in progress), February 2007. [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 989, February 1987. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME Object Security Services", RFC 1848, October 1995. [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. Hansen, et al. Expires December 13, 2007 [Page 29] Internet-Draft DKIM Service Overview June 2007 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. Authors' Addresses Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA Email: tony+dkimov@maillennium.att.com Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA Email: dcrocker@bbiw.net Hansen, et al. Expires December 13, 2007 [Page 30] Internet-Draft DKIM Service Overview June 2007 Phillip Hallam-Baker VeriSign Inc. Email: pbaker@verisign.com Hansen, et al. Expires December 13, 2007 [Page 31] Internet-Draft DKIM Service Overview June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hansen, et al. Expires December 13, 2007 [Page 32]