DomainKeys Identified Mail T. Hansen Internet-Draft AT&T Laboratories Expires: December 27, 2006 D. Crocker Brandenburg InternetWorking P. Hallam-Baker VeriSign Inc. June 25, 2006 DomainKeys Identified Mail (DKIM) Service Overview draft-ietf-dkim-overview-01.txt 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 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract DomainKeys Identified Mail (DKIM) associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and Hansen, et al. Expires December 27, 2006 [Page 1] Internet-Draft DKIM Service Overview June 2006 contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting message sender identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Proof and protection of email identity, including repudiation and non-repudiation, may assist in the global control of "spam" and "phishing". This document provides an overview of DomainKeys Identified Mail and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlines potential DKIM applications and future extensions. Note This document is being discussed on the DKIM mailing list, ietf-dkim@mipassoc.org. Hansen, et al. Expires December 27, 2006 [Page 2] Internet-Draft DKIM Service Overview June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. About This Document . . . . . . . . . . . . . . . . . . . 4 1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 4 1.3. Outline Potential DKIM Applications . . . . . . . . . . . 7 2. DKIM Within Existing Internet Email . . . . . . . . . . . . . 7 2.1. Review of Internet Mail Service Architecture . . . . . . . 7 2.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 10 2.3. Impact on Email Activities . . . . . . . . . . . . . . . . 11 2.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 12 2.5. { Misc Text -- Should go elsewhere, if used at all } . . . 13 3. DKIM Within Existing Internet Email . . . . . . . . . . . . . 14 3.1. Review of Internet Mail Service Architecture . . . . . . . 14 3.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 17 3.3. Impact on Email Activities . . . . . . . . . . . . . . . . 17 3.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18 3.5. { Misc Text -- Should go elsewhere, if used at all } . . . 19 4. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 21 5. Relationship to previous Message Signature Technologies . . . 23 5.1. Transparent Signature . . . . . . . . . . . . . . . . . . 23 5.2. Treat verification failure as if unsigned. . . . . . . . . 24 5.3. Legacy Client Semantics . . . . . . . . . . . . . . . . . 25 5.4. Key Centric PKI . . . . . . . . . . . . . . . . . . . . . 25 5.5. Domain Level Assurance . . . . . . . . . . . . . . . . . . 27 5.6. Security Policy . . . . . . . . . . . . . . . . . . . . . 27 6. Implementation Considerations . . . . . . . . . . . . . . . . 28 6.1. Development . . . . . . . . . . . . . . . . . . . . . . . 28 6.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Outline Future Extensions . . . . . . . . . . . . . . . . . . 30 7.1. Introducing a new signing algorithm . . . . . . . . . . . 31 7.2. Possible future signature algorithm choices . . . . . . . 31 7.3. Transition strategy . . . . . . . . . . . . . . . . . . . 32 7.4. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33 7.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 34 7.6. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35 7.7. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.8. Verification in the Client . . . . . . . . . . . . . . . . 36 7.9. Per user signature . . . . . . . . . . . . . . . . . . . . 37 7.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 37 7.11. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38 7.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 38 8. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 39 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 10. Informative References . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 42 Hansen, et al. Expires December 27, 2006 [Page 3] Internet-Draft DKIM Service Overview June 2006 1. Introduction 1.1. About This Document This document provides an overview of DomainKeys Identified Mail (DKIM). It provides information for: those who are adopting DKIM; those who are developing DKIM; those who are deploying DKIM; and those who are considering extending DKIM, either into other areas or to provide additional features. This document does not provide information on threats to DKIM or email, or details on the implementation. Such information can be found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim- threats] Nor does this document describe how to solve the world's problems with spam, phish, virii, worms, joe jobs, etc. [ NOTE: a number of sections in this document are just placeholders for now ] 1.2. A Quick Overview of DKIM 1.2.1. Axiom: Ubiquitous Authentication is Good DKIM builds on previous work in the form of Domain Keys, Identified Internet Mail, Authenticated Sender, Meta-Mail, etc. The starting point for all of these technologies, and now DKIM, is the belief that authenticating email is a good thing to do in and of itself. It has been pointed out that it is unlikely that RFC 822 [RFC0822] would pass today without some form of strong authentication mechanism. DKIM provides such a strong authentication mechanism. The ultimate goal of DKIM is to achieve a situation where email authentication is ubiquitous and the unsigned email becomes the exception the rule, as is the case today. Only when the majority of Internet email is authenticated is it possible to make interesting conclusions about the lack of authentication. It follows then that a new message signature scheme is required to meet the goal of ubiquitous authentication. In each of the above- mentioned proposals, several design elements are shared: o The signature is carried in the message header and does not affect the message body. o The signature may include certain headers. o There is a policy mechanism, either explicit or implicit, that tells receivers when to expect a signature. Hansen, et al. Expires December 27, 2006 [Page 4] Internet-Draft DKIM Service Overview June 2006 o Keys are self-created (it is not necessary to buy a certificate). o Keys are stored in the DNS (it is not necessary to deploy a separate key server). The remarkable similarity of these architectural proposals strongly suggests that this architecture should be the basis for ubiquitous authentication. DKIM was produced by merging the two previous proposals of DomainKeys and Identified Internet Mail. Significant enhancements were then made from that base. The approach taken by DKIM differs from previous approaches to message signing in that: o the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software are confused by signature-related content appearing in the message body, o there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities, o there is no dependency on the deployment of any new Internet protocols or services for public key distribution or revocation, o it makes no attempt to include encryption as part of the mechanism. 1.2.2. What is the purpose of DKIM? DKIM lets an organization take responsibility for a message. The organization taking responsibility is a handler of the message, either as its originator or as an intermediary. Their reputation 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. This means that their reputation is at stake. By design, DKIM purposely: o is compatible with the existing email infrastructure and transparent to the fullest extent possible o requires minimal new infrastructure o can be implemented independently of clients in order to reduce deployment time Hansen, et al. Expires December 27, 2006 [Page 5] Internet-Draft DKIM Service Overview June 2006 o does not require the use of trusted third parties (e.g., certificate authorities) which might impose significant costs or introduce delays to deployment o can be deployed incrementally o allows delegation of signing to third parties o is not intended be used for archival purposes DKIM authentication provides one link in a chain of responsibility, hopefully leading to better accountability by the senders. 1.2.3. What does DKIM do? DKIM defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. The responsible organization adds a digital signature to the message, associating it with a domain name of that organization. Typically, signing will be done by an service agent within the authority of the message originator's Administrative Management Domain (ADMD). (Signing might be performed by any of the functional components in that environment, including a Mail User Agent (MUA), a Mail Submission Agent (MSA), or an Internet Boundary MTA. DKIM also permits signing to be performed by authorized third-parties.) 1.2.4. Who validates the signature? After a message has been signed, any agent in the message transit path can choose to validate the signature. 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, validation will be done by an agent in the ADMD of the message recipient. Again, this may be done by any functional component within that environment. (Notably this means that the signature can be used by the recipient ADMD's filtering software, rather than requiring the recipient end-user to make an assessment.) 1.2.5. What does DKIM *not* do? DKIM does not: o offer any assertions about the behaviors of the identity doing the signing. Hansen, et al. Expires December 27, 2006 [Page 6] Internet-Draft DKIM Service Overview June 2006 o prescribe any specific actions for receivers to take upon successful (or unsuccessful) signature validation. o provide protection after message delivery. o protect against re-sending (replay of) a message that already has a valid signature; therefore a transit intermediary or a recipient can re-post the message in such a way that the signature would remain valid, although the new recipient(s) would not have been specified by the originator. 1.3. Outline Potential DKIM Applications TBD 2. DKIM Within Existing Internet Email 2.1. Review of Internet Mail Service Architecture 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 others, 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) Hansen, et al. Expires December 27, 2006 [Page 7] Internet-Draft DKIM Service Overview June 2006 +--------+ +---------------->| User | | +--------+ | ^ +--------+ | +--------+ . | User +--+--------->| User | . +--------+ | +--------+ . . | ^ . . | +--------+ . . . +-->| User | . . . +--------+ . . . ^ . . . . . . V . . . +---+----------------+------+------+---+ | | | | | | | +--------------->+ | | | | | | | | | +---------------------->+ | | | | | | | +----------------------------->+ | | | | Mail Handling Service (MHS) | +--------------------------------------+ Figure 1: Basic Internet Mail Service Model 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. 2.1.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). Examples include an end- user operating their desktop client, a department operating a local Relay, an IT department operating an enterprise Relay and an ISP operating a public shared email service. These can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 2 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. Hansen, et al. Expires December 27, 2006 [Page 8] Internet-Draft DKIM Service Overview June 2006 Basic components of ADMD distinction include: Edge: Independent transfer services, in networks at the edge of the Internet Mail service. User: End-user services. This might be subsumed under the 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. 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 2: 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: Operating an organization's internal data and/or mail services. Hansen, et al. Expires December 27, 2006 [Page 9] Internet-Draft DKIM Service Overview June 2006 Internet Service Providers: Operating 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: Operating email services, such as for end-users, or mailing lists. 2.1.2. Field Referencing Convention 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 and is the address in the SMTP "Mail From" command. DKIM associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate. Deciding which ADMD shall perform signing or verifying, which identity to assign and which functional components to use for DKIM processing depend upon the nature of the trust/reputation that is of interest and the most convenient or efficient way to use it. 2.2. Where to Place DKIM Functions Messages may be signed or verified by any functional component within an ADMD, as that domain wishes to arrange, such as: Outbound: MUA, MSA or boundary MTA. Inbound: Boundary MTA, MDA or MUA. By having an MUA do the signing or verifying, there is no dependence upon implementation by an email service infrastructure. By having an MHS component do signing or verifying, there is no dependence upon user training or the upgrade of potentially large numbers of user applications. Perhaps the most obvious choices within the MHS are the MSA or MDA, and the outbound or inbound (boundary) MTA. By signing or verifying at the outermost portion of the MHS, true end-to-end service is provided, requiring the smallest amount of trust on the rest of the infrastructure. By signing or verifying at a boundary, the smallest number of systems need modifying and the signature is subject to the Hansen, et al. Expires December 27, 2006 [Page 10] Internet-Draft DKIM Service Overview June 2006 smallest amount of handling that can break the signature. The choice of identity to use might not be obvious. Examples include: Author The domain associated with the RFC2822.From field provides basic authorization for the author to generate mail. Because the organization controlling that domain is closest to the author, they well might be in the best position to offer their reputation as a basis for asserting that the content is "safe". Operator Email reputation services have long-used the IP Address of a client SMTP server as the basis for assessing whether to permit relay or delivery of a message. These Addresses identify the operator of an email service, rather than necessarily indicating the author of messages being sent by that service. Use of an operator's domain name is a natural extension of this model. Third-party An independent service might wish to certify an author, a message or an operator, by providing its own signature to a message. Hence, evaluation of the message will be based upon the identity of that third-party, rather than any of the identities involved in creation or transfer of the message. Indeed, this model is already emerging among a number of reputation-vetting services and is similar to the way a credit card permits a customer to make purchases, based upon the reputation of the credit card company -- and its willingness to issue the card. Ultimately, the choice of component for signing will depend upon both the identity being used and the tradeoff between flexibility of uses, versus administrative and operational control. The choice of component for verification will depend upon the intended use and similar concerns about flexibility and control. A typical choice for reputation-related verification will be to place the signature verification function "close" to the message-filtering engine. 2.3. Impact on Email Activities 2.3.1. Resources Although the cryptographic authentication are considered to be computationally expensive, the real impact of a mechanism, like DKIM, is remarkably small. Direct impact on CPU-load has been measured to be 10-15%. Usually, email is i/o-intensive, with unused computational capacity. So, it is likely that no new hardware will be required. Hansen, et al. Expires December 27, 2006 [Page 11] Internet-Draft DKIM Service Overview June 2006 2.3.2. Operations Administrative cost to deploy, versus expected reduction in the cost of administration for problem email. Challenge of mobile users. Server-resident folders -- web or imap -- no problem. Laptop-resident folders, requires remote MSA access or per-user keying and mobile-author awareness. Key creation and replacement. Update DNS and signing component 2.3.3. Users Challenge of mobile users. Server-resident folders -- web or imap -- no problem. Laptop-resident folders, requires remote MSA access or per-user keying and mobile-author awareness. Challenge of mailing lists. Different list styles warrant different signature policies. Can be hidden from end-user; used by filter engine. Method and benefits for displaying to users unknown. 2.4. Migrating from DomainKeys 2.4.1. Signing 2.4.1.1. DNS Records DKIM is upward compatible with existing DomainKeys (DK) DNS records, so that a DKIM module does not automatically require additional DNS administration! DKIM has enhanced the DK DNS key record, to permit the addition of several parameters. 2.4.1.2. Signing Module DKIM uses a different RFC2822 [RFC2822] header field for storing the signature, in order to distinguish it from DK. DKIM includes language to make it clear which particular header field is signed, if there is more than one header field of a given name in the message. DKIM allows some values that were scalars in DomainKeys to be colon- separated arrays. For example, the list of query methods used to find a key and the "t=" tags (originally testing, now flags). DKIM permits copying the original version of headers fields and their Hansen, et al. Expires December 27, 2006 [Page 12] Internet-Draft DKIM Service Overview June 2006 values, to aid in diagnosing signatures that do not survive transit. DKIM has the ability to limit keys to hash algorithms specified in a list, in the DNS record. DKIM allows body length limits, to permit signatures, to survive transit through some intermediaries, such as some mailing list agents that add text to the end of the message. 2.4.1.3. Boundary MTA Enforce signature policies and practises 2.4.2. Verifying 2.4.2.1. DNS Client 2.4.2.2. Verifying module See "Signing Module". 2.4.2.3. Boundary MTA Strip "local" signatures that are not local? 2.5. { Misc Text -- Should go elsewhere, if used at all } DKIM permits the signing identity to be different from the identities used for the author or the initial posting agent. This is essential, for example, to enable support of signing by authorized third- parties, and to permit signatures by email providers who are otherwise independent of the domain name of the message author. 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. This is an improvement because it requires the signer to use the more conservative (likely to verify correctly) mechanism and makes it considerably more robust against the handling of intermediary MTAs. DKIM self-signs the DKIM-Signature header field, to protect against its being modified. In order to survive the vagaries of different email transfer systems, Hansen, et al. Expires December 27, 2006 [Page 13] Internet-Draft DKIM Service Overview June 2006 mechanisms like DKIM must evaluate the message data in some canonical form, such as treating a string of spaces as tabs as if they were a single space. DKIM has added the "relaxed" canonicalization in place of "nofws". 3. DKIM Within Existing Internet Email 3.1. Review of Internet Mail Service Architecture 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 others, 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) +--------+ +---------------->| User | | +--------+ | ^ +--------+ | +--------+ . | User +--+--------->| User | . +--------+ | +--------+ . . | ^ . . | +--------+ . . . +-->| User | . . . +--------+ . . . ^ . . . . . . V . . . +---+----------------+------+------+---+ | | | | | | | +--------------->+ | | | | | | | | | +---------------------->+ | | | | | | | +----------------------------->+ | | | | Mail Handling Service (MHS) | +--------------------------------------+ Figure 3: Basic Internet Mail Service Model Modern Internet Mail service is marked by many independent operators, many different components for providing users with service and many Hansen, et al. Expires December 27, 2006 [Page 14] Internet-Draft DKIM Service Overview June 2006 other components for performing message transfer. Consequently, it is necessary to distinguish administrative boundaries that surround sets of functional components. 3.1.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). Examples include an end- user operating their desktop client, a department operating a local Relay, an IT department operating an enterprise Relay and an ISP operating a public shared email service. These can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 2 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 27, 2006 [Page 15] Internet-Draft DKIM Service Overview June 2006 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 4: 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: Operating an organization's internal data and/or mail services. Internet Service Providers: Operating 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: Operating email services, such as for end-users, or mailing lists. Hansen, et al. Expires December 27, 2006 [Page 16] Internet-Draft DKIM Service Overview June 2006 3.1.2. Field Referencing Convention 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 and is the address in the SMTP "Mail From" command. DKIM associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate. The choices of what ADMD to have perform signing or verifying, which identity to assign and which functional components to use for DKIM processing depend upon the nature of the trust/reputation that is of interest and the most convenient or efficient way to use it. 3.2. Where to Place DKIM Functions Messages may be signed or verified by any functional component within an ADMD, as that domain wishes to arrange, such as: Outbound: MUA, MSA or boundary MTA. Inbound: Boundary MTA, MDA or MUA. By having an MUA do the signing or verifying, there is no dependence upon implementation by an email service infrastructure. By having and MHS component do signing or verifying, there is no dependence upon user training or the upgrade of potentially large numbers of user applications. Perhaps the most obvious choices within the MHS are the MSA or MDA, and the outbound or inbound (boundary) MTA. By signing or verifying at the outermost portion of the MHS, true end-to-end service is provided, requiring the smallest amount of trust on the rest of the infrastructure. By signing or verifying at a boundary, the smallest number of systems need modifying and the signature is subject to the smallest amount of handling that can break the signature. Ultimately, deciding where to sign a message is likely to depend upon a combination of the identity being used, and tradeoffs between flexibility, control, and administrative ease. 3.3. Impact on Email Activities 3.3.1. Resources Although the cryptographic authentication are considered to be Hansen, et al. Expires December 27, 2006 [Page 17] Internet-Draft DKIM Service Overview June 2006 computationally expensive, the real impact of a mechanism, like DKIM, is remarkably small. Direct impact on CPU-load has been measured to be 10-15%. Usually, email is i/o-intensive, with unused computational capacity. So, it is likely that no new hardware will be required. 3.3.2. Operations Administrative cost to deploy, versus expected reduction in the cost of administration for problem email. Challenge of mobile users. Server-resident folders -- web or imap -- no problem. Laptop-resident folders, requires remote MSA access or per-user keying and mobile-author awareness. Key creation and replacement. Update DNS and signing component 3.3.3. Users Challenge of mobile users. Server-resident folders -- web or imap -- no problem. Laptop-resident folders, requires remote MSA access or per-user keying and mobile-author awareness. Challenge of mailing lists. Different list styles warrant different signature policies. Can be hidden from end-user; used by filter engine. Method and benefits for displaying to users unknown. 3.4. Migrating from DomainKeys 3.4.1. Signing 3.4.1.1. DNS Records DKIM is upward compatible with existing DomainKeys (DK) DNS records, so that a DKIM module does not automatically require additional DNS administration! DKIM has enhanced the DK DNS key record, to permit the addition of several parameters. 3.4.1.2. Signing Module DKIM uses a different RFC2822 [RFC2822] header field for storing the signature, in order to distinguish it from DK. DKIM includes language to make it clear which particular header field is signed, if there is more than one header field of a given name in the message. Hansen, et al. Expires December 27, 2006 [Page 18] Internet-Draft DKIM Service Overview June 2006 DKIM allows some values that were scalars in DomainKeys to be colon- separated arrays. For example, the list of query methods used to find a key and the "t=" tags (originally testing, now flags). DKIM permits copying the original version of headers fields and their values, to aid in diagnosing signatures that do not survive transit. DKIM has the ability to limit keys to hash algorithms specified in a list, in the DNS record. DKIM allows body length limits, to permit signatures, to survive transit through some intermediaries, such as some mailing list agents that add text to the end of the message. 3.4.1.3. Boundary MTA Enforce signature policies and practises 3.4.2. Verifying 3.4.2.1. DNS Client 3.4.2.2. Verifying module See "Signing Module". 3.4.2.3. Boundary MTA Strip "local" signatures that are not local? 3.5. { Misc Text -- Should go elsewhere, if used at all } DKIM permits the signing identity to be different from the identities used for the author or the initial posting agent. This is essential, for example, to enable support of signing by authorized third- parties, and to permit signatures by email providers who are otherwise independent of the domain name of the message author. 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. This is an improvement because it requires the signer to use the more conservative (likely to verify correctly) mechanism and makes it considerably more robust against the handling of intermediary MTAs. Hansen, et al. Expires December 27, 2006 [Page 19] Internet-Draft DKIM Service Overview June 2006 DKIM self-signs the DKIM-Signature header field, to protect against its being modified. In order to survive the vagaries of different email transfer systems, mechanisms like DKIM must evaluate the message data in some canonical form, such as treating a string of spaces as tabs as if they were a single space. DKIM has added the "relaxed" canonicalization in place of "nofws". Hansen, et al. Expires December 27, 2006 [Page 20] Internet-Draft DKIM Service Overview June 2006 4. DKIM Service Architecture DKIM provides an end-to-end service for signing and verifying messages that are in transit. It is divided into components that can be performed using different, external services, such as for key retrieval, although the basic DKIM operation provides an initial set. Hansen, et al. Expires December 27, 2006 [Page 21] Internet-Draft DKIM Service Overview June 2006 | | - RFC2822 Message V +---------------------------------------------+ +-----------+ | ORIGINATING OR RELAYING ADMD | | | | ============================ | | Signer | | | | Practises +......>| SIGN MESSAGE | | | | ...> ADD A SIGNATURE HEADER FIELD | +-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) | . . | ... COMPUTE SIGNATURE | . V +----------------+----------------------------+ . +-------+ | - Message . | | | 1*(Domain, Selector, . | Key | | Sig) . | Store | [Internet] . | | | . +---+---+ V . . +---------------------------------------------+ . . | RELAYING OR DELIVERING ADMD | . . | =========================== | . . | | . . | VERIFY MESSAGE (Verifier Practises) | . . | ...> VERIFY A SIGNATURE HEADER FIELD | . . | . GET A SIGNATURE | . .....>| . LOOKUP PUB-KEY (Domain, Selector) | . | . VERIFY SIGNATURE VALUE | . | ... EVALUATE SIGNATURE CONSTRAINTS | . +-------------------+-------------------------+ . | - Verified Domain(s) . V - [Report] . +---------------------------------------------+ . | | . | MESSAGE DISPOSITION | .............>| SIGNER PRACTICES | .............>| REPUTATION | . | | +-----+------+ +---------------------------------------------+ | | | Reputation | | | +------------+> Figure 5: DKIM Service Architecture Basic message process divides between signing the message, validating the signature, and the performing further decision-making based upon the validated signature. The component doing the signing applies Hansen, et al. Expires December 27, 2006 [Page 22] Internet-Draft DKIM Service Overview June 2006 whatever signing policies are in force, including ones that determine what private key to use. Validation may be performed by any functional component along the relay and delivery path. The public key is retrieved, based upon the parameters strored in the message. The example shows use of the validated identity for assessing an associated reputation. However it could be applied for other tasks, such as management tracking of mail. 5. Relationship to previous Message Signature Technologies DKIM is the fifth IETF proposal for an email signature scheme. The first RFC describing Privacy Enhanced Mail (PEM) was published in 1987 [RFC0989]. The PEM scheme went through a number of revisions and eventually transformed into MIME Object Security Services in 1995 [RFC1848]. Neither PEM nor MOSS ever achieved significant deployment. PEM relied on the prior deployment of an extensive PKI predicated on a rigid hierarchy of Certificate Authorities. By the time it was understood that this infrastructure assumption was unrealistic the opportunity to deploy PEM had closed. Pretty Good Privacy (PGP) was developed by Phil Zimmerman and released in 1991 and quickly established a significant support base within the security community. This support base was driven by two principal factors: superior ease of deployment and an aggressive marketing campaign assisted by the U.S. government. A working group was formed within the IETF to continue development of the PGP protocol as OpenPGP beginning with publication of the original protocol as an informational RFC in 1996 [RFC1991]. At the same time RSA Security, the holder of the patent rights to the principle public key cryptography algorithm independently developed Secure MIME (S/MIME) which employed the recently developed MIME format to transport a PKCS #7 data object. S/MIME was particularly attractive for software developers who had already implemented SSL as much of the code required to support could be reused. Development of S/MIME and OpenPGP has continued in the IETF since. While both have achieved a significant user base neither has achieved ubiquity. In particular it is notable that only a small percentage of messages on the IETF mailing lists concerned with security are signed. 5.1. Transparent Signature The core goals of DKIM require that use of message signatures becomes Hansen, et al. Expires December 27, 2006 [Page 23] Internet-Draft DKIM Service Overview June 2006 ubiquitous. For this to be possible it must be possible to apply a signature to any message in any circumstance with a negligible chance of causing a negative user experience for any recipient regardless of the legacy email client used. Experiences from S/MIME and PGP deployment strongly indicate that this usability goal can only be met if the addition of the signature leaves the message body unchanged. S/MIME and PGP are both designed to achieve the highest level of security possible. The sender of a message is assured that the confidentiality and/or integrity of the message are protected from the originating end point machine to the destination end point. Achieving this level of security naturally places requirements on both the sender and the receiver. Support for both signature and encryption causes a subtle but important architectural assumption to be introduced. Although signature and encryption are complimentary from a cryptographic point of view their effect is entirely different from a messaging protocol point of view. A digital signature is meta-data providing information about the message contents. Encryption is a transformation of the message content (and possibly related meta-data). The recipient of an encrypted email message must as a matter of course have a specially adapted email client capable of decrypting the message. Adding a signature to the message does not in principle create a requirement for the recipient to have a specially adapted client provided the signature is added in a manner that is ignored by legacy clients. In the case of an S/MIME signature the recipient is at a minimum expected to have a client capable of decoding the MIME multipart/ security format. In practice this means that the recipient must support S/MIME. OpenPGP allows the use of a signature encapsulation that is not MIME based. This has the advantage that the message can be read using a standard email client. The disadvantage with this approach is that the application of the signature is visible to the user and thus intrusive. 5.2. Treat verification failure as if unsigned. PGP and S/MIME were both designed to meet a high standard of cryptographic excellence. At the time the protocols were designed it was generally considered that the correct thing for an application to do in the case of a signature verification failure was to warn the user that the message was unsigned. In a small number of cases the application went even further 'warning' the user whenever a signed Hansen, et al. Expires December 27, 2006 [Page 24] Internet-Draft DKIM Service Overview June 2006 message was received. This type of user experience has since been severely deprecated. A user who is constantly bombarded with warning messages is much less likely to respond appropriately when an important warning message is received. While modern messaging infrastructure is considerably friendlier to the use of digital signatures than in the past even a residual failure rate of 1% results in unacceptably high support costs when signatures are used ubiquitously. It is now generally accepted that the correct semantics for an email signature verifier to adopt are to treat messages with signatures that fail as if they are unsigned. It is highly unlikely that an attacker is going to add a digital signature to a message unless doing so causes the message to be treated more favorably than an unsigned one. Any messages that carry signatures that fail verification are thus much more likely to be a genuine message that has been damaged in transit than an attempted forgery. It makes no sense to warn the recipient unless it is known that the sender always signs email messages and that there is a high probability that a forgery would be attempted. 5.3. Legacy Client Semantics The deployed base of S/MIME is both a benefit and a burden. While the S/MIME protocol is in principle capable of extension to support many of the features of DKIM, the same is not true of the deployed S/MIME base. While the S/MIME protocol can in principle support semantics such as domain level signatures or make use of keys stored in the DNS the legacy deployed base does not. The behavior of legacy clients receiving an S/MIME message dependent on the novel semantics is likely to result in a negative user experience in a significant number of cases. 5.4. Key Centric PKI Unlike all four previous IETF email security initiatives, DKIM employs a key centric, directory based PKI as opposed to a certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman (web of trust). While message syntax and PKI are orthogonal in principle, implementation practice means that most S/MIME clients only support Hansen, et al. Expires December 27, 2006 [Page 25] Internet-Draft DKIM Service Overview June 2006 use of keys contained in X.509/PKIX digital certificates. Although PGP is sometimes held up as an alternative to a certificate based PKI a PGP key signing is in essence a digital certificate by another name. There has since been considerable conversion as X.509 has adopted the web of trust principle under the term cross- certification. The chief distinction between the PGP and PKIX models is that in the PGP model every user is also (potentially) a trust provider. In PKIX trust providers are distinct from end-entities. The Kohnfelder architecture was originally designed to allow use of public key cryptography before the ubiquitous availability of networking. A particular benefit of the Kohnfelder architecture is that Alice can send an encrypted message to Bob when the only transport available is sending floppy disks through the postal system. Another benefit of the Kohnfelder architecture is that a signed message supported by a digital certificate is self supporting and may be verified years after the fact provided only that the CA signing key does not become compromised. The principle weakness in PKIs based on the Kohnfelder architecture is the difficulty of locating the correct digital key in the absence of a directory infrastructure. This led Brian LaMacchia, then at MIT to develop the MIT PGP key server, in effect returning to the original public key directory model proposed by Whitt Diffe and Marty Hellman. XML Key Management Service (XKMS) realizes the key centric PKI model as a SOAP based Web Service. In the XKMS model the PKI client makes a request of the form 'provide me with the signing key that Alice uses with the PGP protocol'. Although DKIM follows the same architectural model as XKMS, DNS is used as the transport layer in place of SOAP over HTTP. The use of DNS significantly reduces the infrastructure requirements for DKIM as existing DNS servers are used for key distribution. This approach also has significant performance advantages as DNS is layers on UDP and key retrieval is typically achieved in a single round trip. XKMS requires a TCP session to be established and the request and response messages are significantly larger. The principle disadvantage of using DNS over XKMS is that the DNS is a network administration resource designed to answer questions about current network configuration. While it is quite possible to re-use the DNS infrastructure to support queries about past and even future network configurations this is not the core objective of the infrastructure. The DNS is thus unsuited to supporting any use of Hansen, et al. Expires December 27, 2006 [Page 26] Internet-Draft DKIM Service Overview June 2006 digital signatures in which long term archival is desirable or the possibility of repudiation is undesirable. 5.5. Domain Level Assurance As previously mentioned PGP and S/MIME were designed in the heyday of the security end-to-end principle. It has since been realized that the end points with respect to trust are not the same as the end points with respect to the communication protocol. When Alice sends a personal message to Bob it is Alice the person, not the machine Alice happens to be using that is the true trust end point. When Alice sends a piece of business correspondence to Bob it is her employer. The objective of DKIM is to allow parties to accept responsibility for messages by signing them. While accepting responsibility at the personal level may be desirable in some circumstances the Internet now has a billion users. Attempting to achieve accountability in a population of a billion users is impractical, particularly when the owner of the domain example.com has the ability to create a practically unlimited number of accounts within that domain at will. The logical unit of accountability for DKIM is therefore the DNS domain name to which the signing key record is bound and not the individual email user. 5.6. Security Policy The innovation in DKIM that has no precedent in the previous email security standards is the publication of a security policy. The purpose of DKIM is to allow a party to accept responsibility for an email message by signing it. A message with a signature is treated as if it is unsigned. For a recipient to interpret an unsigned message it is necessary to know whether it should expect a message from that source to be signed and if so the signature characteristics to expect. The introduction of security policy allows unsigned messages and messages that fail signature validation to be subjected to a higher level of anti-spam filtering or rejected out of hand in circumstances where the owner of the purported originating domain suggests. For example a bank concerned at the possibility of phishing attack might publish a policy stating that all legitimate messages from the domain are signed. While the Sender-ID/SPF security policy format allows application to existing formats including PGP and S/MIME the advantages to Hansen, et al. Expires December 27, 2006 [Page 27] Internet-Draft DKIM Service Overview June 2006 developing the protocol and security policy in tandem are considerable. It is not practical to expect to be able to write a useful sender signing policy for S/MIME or PGP within the constraints of the 512 byte response message size imposed on the legacy DNS. 6. Implementation Considerations 6.1. Development What software has to change, to use DKIM? 6.1.1. Signer The signer needs to add code in the appropriate agent, to perform signing, and they need to modify their DNS administrative tools to permit creation of DKIM key records. 6.1.2. Validator A validator needs to add code to the appropriate agent and then feed the result into the portion of their system needing it, such as a filtering engine. The mere existence of a valid signature does not imply that the mail is acceptable, such as for delivery. Acceptability requires an assessment phase. Hence the result of signature validation must be fed into a vetting mechanism that is part of the validator's filter. 6.1.3. Outbound mail user agent TBD 6.1.4. Outbound mail transport agent TBD 6.1.5. DNS Server TBD 6.1.6. Mailing list manager TBD 6.1.7. Inbound mail transport agent TBD Hansen, et al. Expires December 27, 2006 [Page 28] Internet-Draft DKIM Service Overview June 2006 6.1.8. Inbound mail user agent TBD 6.1.9. Accreditation service TBD 6.2. Deployment 6.2.1. Signing 6.2.1.1. DNS Records add sig key info 6.2.1.2. Signing Module Delete old signs with same key; add new sig 6.2.1.3. Boundary MTA Enforce signature policies and practises 6.2.2. Verifying 6.2.2.1. DNS Client Ensure able to obtain DKIM key sig records 6.2.2.2. Verifying module Validate sig; channel info to filtering engine. Maybe provide user- visible info. 6.2.2.3. Boundary MTA Strip "local" signatures that are not local? 6.3. Operations 6.3.1. DNS Signature Record Deployment Considerations TBD 6.3.2. Thoughts on Expiring Signatures TBD Hansen, et al. Expires December 27, 2006 [Page 29] Internet-Draft DKIM Service Overview June 2006 6.3.3. DNS Policy Record Deployment Considerations TBD 6.3.4. Subdomain Considerations TBD 6.3.5. Third party Signature Delegations TBD 7. Outline Future Extensions The design of DKIM is unapologetically focused on overcoming the need for immediate deployment and achieving ubiquitous use in the near future. As such the original design discussions have generally taken the approach 'if in doubt leave it out'. The need to exclude consideration of these features in the near term is in no way intended to preclude their development at a later date. Nor is the lack of a specification describing the use of DKIM with a different PKI infrastructure intended to indicate an intention to develop similar capabilities within the DKIM framework at a future date. DKIM is an example of 'Design for Deployment'. The need to support rapid deployment is the overriding priority. It has traditionally been asserted that deployment of a flawed cryptographic protocol is an almost unacceptable risk, that bad security is worse than no security. Experience demonstrates otherwise. Informing users that email is insecure does not cause them to modify their behavior to avoid dependence thereupon. Deployment of flawed cryptographic security systems such as SSL and WEP has been rectified far more quickly than deployment of protocols such as IPSEC or DNSSEC where caution has prevailed. One possible future for DKIM is that it becomes the starting point for a new cryptographic infrastructure that eventually replaces legacy systems including S/MIME and PGP. While this future is certainly preferable to never achieving ubiquitous deployment of strong cryptographic security in the Internet it would certainly take a long time to re-invent this particular wheel. Moreover the deployment of the proposed DKIM enhancements would face political opposition from the adherents to existing formats to be rendered historical. A likely outcome of such a strategy is that the existing two way standards stalemate between S/MIME and PGP would become a Hansen, et al. Expires December 27, 2006 [Page 30] Internet-Draft DKIM Service Overview June 2006 three way stalemate. Another possible future is that DKIM provides the 'bootstrap' that enables ubiquitous use of legacy infrastructure including the deployed base of PGP and S/MIME capable email clients and the existing business infrastructure of commercial Certificate Authorities. Such a strategy would make use of DKIM in conjunction with existing PKI standards such as PKIX and XKMS and leverage features of PGP and S/MIME where appropriate. 7.1. Introducing a new signing algorithm Regardless of whether extension of the DKIM feature set is desirable the need to replace the signature algorithm is practically a certainty. The RSA signature algorithm at best provides equivalent security to an 80 bit symmetric cipher when used with a 1024 bit key [cite]. Extending the key size to 2048 bits improves the cipher strength to only 112 bit equivalence. Achieving 128 bit security requires a minimum of 3072 bits. Achieving equivalent cipher strength to a 192 bit symmetric algorithm requires a prohibitive key size. The choice of cryptographic algorithm affects the DKIM algorithm in two important ways. First there is the difficulty of storing keys in the DNS. Secondly there is the problem of handling larger signatures. The default DNS response packet limit of 512 bytes places an effective upper bound of 4096 bits on a DKIM key. In practice the need for packaging, meta-data and the desirability of using DNSSEC to sign the record reduces the upper bound to no more than 2048 bits. The size of the DKIM signature itself is a weaker constraint. Even so, while 1024 and even 2048 bit signatures are likely to be acceptable in most implementations larger signature sizes may become prohibitive, particularly as the signature must be Base 64 encoded. 7.2. Possible future signature algorithm choices ECC cryptography offers a means of implementing public key cryptography using a key size and signature size that are each only twice the size of the equivalent symmetric key algorithm. While ECC offers clear technical advantages over algorithms based on the difficulty on solving the discrete log problem in a finite field it is not possible at this point to be confident that a means of applying ECC that is consistent with the position on intellectual property adopted by the DKIM working group has been found. Hansen, et al. Expires December 27, 2006 [Page 31] Internet-Draft DKIM Service Overview June 2006 The DSA signature algorithm based on the discrete log problem faces the same key size limitations as RSA. Importantly for the design of DKIM and DNSSEC however the signature size is much smaller, the same size as for ECC algorithms. It is likely that DSA would have received greater attention during the design of DSA if key sizes greater than 512 bits and use of hash functions stronger than SHA-1 had been supported at the time. In March 2006 a proposed revision of the DSA signature algorithm answered these objections permitting larger key sizes and specifying use of stronger hash functions including SHA-256 and SHA 512. While the advantages offered by DSA are not sufficient to warrant an immediate transition to the new algorithm at this late stage it is highly probably that the algorithm will be employed by DNSSEC when finally deployed. 7.3. 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. 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. 7.3.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 a new signing algorithm 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, first with algorithm A and algorithm B A. The signer tests new signing configuration B. Signer advertises that it signs with algorithm A and algorithm B Hansen, et al. Expires December 27, 2006 [Page 32] Internet-Draft DKIM Service Overview June 2006 3. Signer determines that support for Algorithm A is no longer necessary 4. Signer determines that support for algorithm A it 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 7.3.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 B to be withdrawn. The decisions of the verifier must make are therefore: 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. A verifier MAY chose to evaluate signature records in any order it chooses, including making use of the signature algorithm for this purpose. The verifier MAY make a determination that Algorithm A does not offer a useful level of security, that the cost of verifying the signature is less than the value of doing so. A. In this case the verifier ignores signatures created using the algorithm A and references to algorithm A in policy records are treated as if the algorithm is not implemented. The verifier MAY decide to add support for additional signature algorithms at any time. A. The verified MAY add support for algorithm B at any time. 7.4. Linkage to Other PKIs The principle limitations in DKIM are the lack of support for end- user keying, the lack of support for long term verification of signatures and the lack of support for trusted third party issued Hansen, et al. Expires December 27, 2006 [Page 33] Internet-Draft DKIM Service Overview June 2006 assertions. Each of these limitations is determined by the key distribution mechanism rather than the signature format. Although the DNS infrastructure could in principle be extended to support these features this approach would require substantial modifications that entirely negate the advantage of employing an existing infrastructure. The point of using DNS is to reuse the DNS infrastructure, not the DNS protocol. The preferred approach to addressing these limitations is to support use of a PKI infrastructure designed to support these requirements such as PKIX, PGP or XKMS. 7.5. Trusted Third Party Assertions 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 behavior of the domain name owner to be predicted may allow the probability that the message is abusive to be determined without the need for heuristic content analysis. Recipients of large volumes of email can generate reputation data for email senders internally. 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 sender which have established a prior history of sending messages. Another commonly used technique for evaluating email senders is accreditation. Most spam sent today is sent by criminals to further a scheme that is unambiguously illegal. Spam demonstrates an Internet equivalent of Gresham's law: the bad spam drives out the merely irritating, the outright criminal drives out the bad. A message is highly unlikely to be spam if the email sender that can demonstrate that it is a legitimate business and that it has provided a legitimate address where legal process can be served. In addition the accredited email sender may accept a legally binding undertaking not to send spam and possibly post a performance bond that is subject to forfeiture in case of default. As with reputation data a high volume email recipient may be in a position to establish bilateral agreements with high volume senders. Smaller recipients are not in a position to require accreditation, nor is it practical for each large sender to accredit every sender. Trusted Third Party accreditation services allow an email sender to obtain an accreditation that is recognized by every email recipient that recognizes the Trusted Third Party. Hansen, et al. Expires December 27, 2006 [Page 34] Internet-Draft DKIM Service Overview June 2006 [Need use of both systems] [Need means of advertising existence of positive reputation data] 7.6. Linkage to X.509 Certificates The industry standard for distribution of Trusted Third Party data tied to a public key is the X.509v3/PKIX standard. X.509 based PKI is designed to support requirements such as long term archiving of signatures, end entity signing and Trusted Third Party assertions. Combining the DKIM signature format with the PKIX PKI infrastructure provides an equivalent set of capabilities to S/MIME. Two approaches may be used to inform signature verifiers that an X.509 certificate has been issued that makes an assertion about the signing key for a DKIM signature: 1. By means of an attribute in the key record 2. By means of a signature header q= parameter Typical commercially issued digital certificates are considerably larger (1-2 kb) than the 512 byte message size that DNS servers are required to support as a minimum. Practical large scale PKI deployment requires support for certificate chains in addition to the end entity certificate. Publication of a URL for the certificate or certificate chain is therefore a more appropriate approach than storing the certificate data itself in the DNS. The ability to support multiple key distribution mechanisms for the same key is highly desirable. For example a signer may support DNS based key distribution for the convenience and efficiency of transport based DKIM signature verifiers and an X.509 certificate In other cases a signer may intentionally discourage transport verification by only providing an X.509 certificate. An X.509 application of particular interest is the use of DKIM as a signature format for Secure Internet Letterhead (Letterhead). Letterhead employs X.509 certificates containing a LOGOTYPE attribute extension [LOGOTYPE] to identify the certificate subject and/or issuer to the user by means of a brand image such as a corporate logo. [PHB-NIST] 7.7. XKMS XKMS is a key centric PKI that supports registration and location of keys. XKMS is layered as a Web service and the existence of XKMS Hansen, et al. Expires December 27, 2006 [Page 35] Internet-Draft DKIM Service Overview June 2006 service for a domain is typically advertised by means of a DNS SRV record. XKISS, the key location component of XKMS provides a superset of the capabilities of the DKIM DNS key distribution mechanism. As XKMS is layered on SOAP over HTTP over TCP/IP the overhead incurred in retrieving keys through XKMS is substantially higher than the single UDP request/response of DNS key distribution. Like X.509 XKMS is designed to key management over time periods of years and decades rather than days and supports the use of trusted third parties. XKMS is designed to allow complexity to be concentrated at the Web service as opposed to the client. A client interacts with an XKMS service using request of the form 'provide a key to verify signatures on messages sent by A using protocol B'. XKMS may also be used as a gateway to one or more PKIs including an X.509 based PKI that makes use of sophisticated features such as cross certification. The verifier may at its option rely on the XKMS service to provide a trusted key or request the complete certificate path allowing offline verification. A signer may notify signature verifiers that a key may be retrieved using XKMS by means of the q= attribute. The verifier may then discover the corresponding XKMS service using the SRV mechanism as set out in the XKMS specification. 7.8. Verification in the Client The DKIM specification is designed to support edge to edge authentication. The specification neither supports nor prohibits verification of DKIM signatures in the client. In particular the specification does not attempt to define client semantics for signatures or provide an exhaustive list of user interface security considerations. For client based verification to be practical it is likely the a client needs to be capable of determining that it is able to receive messages that do not get clobbered before coming to any conclusions with respect to unsigned messages. 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 does not result in a less satisfactory user experience than leaving the message unsigned. Hansen, et al. Expires December 27, 2006 [Page 36] Internet-Draft DKIM Service Overview June 2006 7.9. Per user signature Although DKIM is designed to support domain level signatures the DKIM core design neither supports nor prohibits use of per user signatures. A DKIM key record can specify restrictions on the email addresses it can be used to sign for. These restrictions are not intended to be exhaustive nor are detailed semantics or security considerations set out for interpreting per user signatures. The primary use this feature is intended to support is to allow a company to delegate signing authority for bulk marketing communications without the risk of effectively delegating the authority to sign contracts on behalf of the CEO. For per user signing keys to provide value beyond this limited use scenario it is likely that additional requirements are necessary such as the ability to perform long term validation of the key. Linkage to some form of PKI is likely to be necessary. In addition any scheme that involves maintenance of a significant number of public keys will require infrastructure to support that management. 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. As a minimum a key registration protocol must be defined. 7.10. Encryption DKIM is not designed to support encryption. A strong case can be made for applying the DKIM style of transparent security, key centric key management and domain level keying. It is not clear that re- using the DKIM signature architecture is the best way to achieve this goal. The DKIM signature format in particular is designed to allow meta- data to be attached to a message without modifying the content. Content encryption by its very nature requires modification of the message content. The message encryption formats of PGP and S/MIME both solve the problem of message encryption perfectly adequately and there is no reason to believe that a new effort in this space would improve matters. An architecture of this form would require development of an email receiver security policy that allows a recipient to state that encrypted email messages are acceptable and to specify key distribution infrastructure(s) by which the necessary encryption keys may be discovered. A policy infrastructure of this type is implicit in the XKMS Hansen, et al. Expires December 27, 2006 [Page 37] Internet-Draft DKIM Service Overview June 2006 standard. One drawback to this approach is that policy distribution an key distribution are conflated, an approach hat is satisfactory for message level encryption schemes such as PGP and S/MIME but less satisfactory for transport layer encryption such as SSL. 7.11. Reuse of Key Record A number of proposals have been made which attempt to reuse the DKIM key record. Architects considering this approach should be aware of the advantages and limitations. As a minimum each of the security considerations listed in the DKIM specification should be considered and its possible relevance to the proposed field of use carefully evaluated. Application of a security mechanism outside the context in which it was originally designed for is a principle cause of security failures. DKIM is designed to meet the security needs of an application where the cost of individual failures is insignificant or small. A single spam in an email inbox is not a disaster, indeed it is no longer even an irritation. For the long time spam sufferer who has seen their inbox filled with hundreds or even thousands of spams an occasional failure may even be cause for satisfaction, a reminder of a successfully vanquished foe. One of the chief limitations of using DNS based key records is that maintenance of DNS records is typically a network operations concern. If the entity to which the public key corresponds is a network object (e.g. a mail server) the use of DNS based key management is likely to be satisfactory. If the entity is not a network related object (e.g. an end user) a significant degree of pushback from network administrators should be anticipated. The design of DKIM is designed for rapid deployment in response to an immediate need. As such many of the design decisions are not the decisions that would be taken if the choice was unconstrained by the limitations of the current legacy DNS. In particular the use of Base 64 encoded public keys distributed through TXT records is not ideal. Applications that do not face the same constraints as DKIM should carefully evaluate the feasibility of using the binary key record. In particular an application predicated on the use of DNSSEC to authenticate keys should assume support for DKIM binary key records. 7.12. Use of Policy Record DKIM demonstrates the power of using the DNS to distribute security policy information. It is not possible to achieve robust security Hansen, et al. Expires December 27, 2006 [Page 38] Internet-Draft DKIM Service Overview June 2006 unless the parties to a conversation know the security capabilities and expectations of the other. Any party proposing re-use of the DKIM policy record should carefully consider whether their needs would be better met by proposing a flexible security policy architecture in the DKIM style rather than proposing ad-hoc extensions and variations. At a minimum any proposal for new security policy formats that make use of the TXT record should employ a new policy prefix and ensure that mislabeled and wild-carded policy records are not accidentally misinterpreted. 8. What Needs To Be Moved Here From the Base Doc? MUA considerations key delegation/ 3rd party 9. Acknowledgements TBD 10. Informative References [I-D.ietf-dkim-base] Allman, E., "DomainKeys Identified Mail Signatures (DKIM)", draft-ietf-dkim-base-02 (work in progress), May 2006. [I-D.ietf-dkim-threats] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work in progress), May 2006. [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [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. [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME Hansen, et al. Expires December 27, 2006 [Page 39] Internet-Draft DKIM Service Overview June 2006 Object Security Services", RFC 1848, October 1995. [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Hansen, et al. Expires December 27, 2006 [Page 40] Internet-Draft DKIM Service Overview June 2006 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 Phillip Hallam-Baker VeriSign Inc. USA Email: pbaker@verisign.com Hansen, et al. Expires December 27, 2006 [Page 41] Internet-Draft DKIM Service Overview June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hansen, et al. Expires December 27, 2006 [Page 42]