DomainKeys Identified Mail T. Hansen Internet-Draft AT&T Laboratories Intended status: Informational
P. Hallam-BakerE. Siegel Expires: May 7,August 13, 2009 Constant Contact, Inc. P. Hallam-Baker VeriSign Inc. D. Crocker Brandenburg InternetWorking E. Siegel Constant Contact, Inc. November 3, 2008February 9, 2009 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations draft-ietf-dkim-deployment-02draft-ietf-dkim-deployment-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and 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 May 7,August 13, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract DomainKeys Identified Mail (DKIM) allows an organization to takeclaim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. 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 about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing."phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 35 2. Key Generation, Storage, and ManagementUsing DKIM as Part of Trust Assessment . . . . . . . . . . . 3. 5 2.1. General Coding Criteria for Cryptographic ApplicationsA Systems View of Email Trust Assessment . . 3. . . . . . . 5 2.2. Key Generation and StorageChoosing a DKIM Tag for the Assessment Identifier . . . . 7 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . 4 2.3. DNS Signature Record Deployment and Maintenance Considerations. 9 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11 2.5. Filtering . . . . . . 5 3. Signing. . . . . . . . . . . . . . . . . . 12 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 814 3.1. Private Key Management: Deployment and Ongoing Operations . . . . . . . . . . . . . . . . . . . . . . . . 815 3.2. Mailing ListsStoring Public Keys: DNS Server Software Considerations . 16 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 3.4. Third Party Signer Key Management and Selector Administration . . . . . . . . . . . . 10 3.3. Signature Transition Strategy. . . . . . . . . . 17 3.5. Key Pair / Selector Lifecycle Management . . . . 12 4. Verifying. . . . . 18 4. Signing . . . . . . . . . . . . . . . . . . . . . 14 4.1. Verifier. . . . . . 19 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . 14 4.2. DNS Client. . . 19 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 1420 4.3. Boundary EnforcementSigning Policies and Practices . . . . . . . . . . . . . . 20 5. Verifying . . . . . 15 4.4. Filtering Software. . . . . . . . . . . . . . . . . . . . 15 5. DKIM Deployment Considerations for Email Agents. 21 6. Taxonomy of Signatures . . . . . . . . . . 15 5.1. Email Infrastructure Agents. . . . . . . . . . 21 6.1. Single Domain Signature . . . . . 15 5.2. Mail User Agent. . . . . . . . . . . . 21 6.2. Parent Domain Signature . . . . . . . . . . 17 6. Migrating from DomainKeys. . . . . . . 22 6.3. Third Party Signature . . . . . . . . . . . . 17 6.1.. . . . . . 23 6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 24 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 25 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 27 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 27 7.2. Author's Organization - Differentiated Types of Mail . . . 27 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 27 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 28 7.5. Delegated Signing . . . . . . . . . . . . 17 6.2. Verifying. . . . . . . . 28 7.6. Independent Third Party Service Providers . . . . . . . . 28 7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 29 7.8. Agent or Mediator Signatures . 18 7. Example Uses. . . . . . . . . . . . . . 29 8. Usage Considerations . . . . . . . . . . . 18 7.1.. . . . . . . . . . 30 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 30 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 18 7.2. Recipient-based Assessments31 8.3. Signature Granularity . . . . . . . . . . . . . . . 19 7.3. DKIM Support in the Client. . . 31 8.4. Email Infrastructure Agents . . . . . . . . . . . . . 19 7.4. Per user signatures. . 32 8.5. Mail User Agent . . . . . . . . . . . . . . . . . 19 8. Security. . . . 34 9. Other Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA. . 35 9.1. Security Considerations . . . . . . . . . . . . . . . . . 35 9.2. IANA Considerations . . . . . . 20. . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 2035 11. Informative References . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses35 Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 37 A.1. Signers . . . . . . . . . . 21 Intellectual Property and Copyright Statements. . . . . . . . . . 23 1. Introduction There are many areas to be considered when deploying. . . . . 37 A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. General Coding Criteria for Cryptographic Applications . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction DomainKeys Identified Mail (DKIM).(DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. This document provides practical tips for: those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys; and those who are responsible for the on-going operations of an email infrastructure that has deployed DKIM. The document is organized aorundaround the key concepts related to DKIM. Within each section, additional considerations specific to development, deployment, or ongoing operations are highlighted where appropriate. [[anchor2: MSK: maybe this is a good place to mention the possibility of collecting verification history for selectors domains as a means of observing over time behaviour of signers for the purpose of asserting local reputation]] 2. Key Generation, Storage, and ManagementUsing DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name serviceas its key server technology [RFC4871]. This section covers considerations around generating, deploying, and managing the public and private keys required for DKIM to function.Part of Trust Assessment 2.1. General Coding Criteria for Cryptographic Applications NOTE: This section could possibly be changed intoA Systems View of Email Trust Assessment DKIM participates in a referencetrust-oriented enhancement to something else,the Internet's email service, to facilitate message handling decisions, such as another rfc. Correct implementationfor delivery and for content display. Trust-oriented message handling has substantial differences from approaches that consider messages in terms of a cryptographic algorithmrisk and abuse. With trust, there is a necessary but notcollaborative exchange between a sufficient condition forwilling participant along the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications.sending path and a willing participant at the recipient site. In addition tocontrast, the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers should pay close attention to managementrisk model entails independent action by the recipient site, in the face of cryptographic private keys and session keys, ensuring that these are correctly initializeda potentially unknown, hostile and disposed of. Operating system mechanisms that permitdeceptive sender. This translates into a very basic technical difference: In the confidentialityface of private keys to be protected against other processes should be used when available. In particular, great careunilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms must be taken when releasing memory pages tobased on heuristics, that is, on guessing. Guessing produces statistical results with some false negatives and some false positives. For trust-based exchanges, the operating system to ensuregoal is the deterministic exchange of information. For DKIM, that private keyinformation is not disclosed to other processes. Certain implementations of public key algorithms such as RSA may be vulnerable tothe one identifier that represents 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 managementstream of private keys. Fortunately appropriately designed and coded cryptographic libraries are availablemail for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic librarieswhich an independent assessment is strongly encouraged. These have been extensively tested, reduce development time and supportsought (by the signer.) A trust-based service is built upon a wide rangevalidated Responsible Identifier that labels a stream of cryptographic hardware. 2.2. Key Generationmail and Storage 2.2.1. Assignment of Selectors Selectors Selectors are assigned according to the administrative needsis controlled by an identity (role, person or organization.) The identity is acknowledging some degree of the signing domain, such asresponsibility for rolling over tothe message stream. Given a new key orbasis for delegating ofbelieving that an identifier is being used in an authorized manner, the right to authenticate a portionrecipient site can make and use an assessment of the namespace to a trusted third party. Examples include: jun2005.eng._domainkey.example.com widget.promotion._domainkey.example.com NOTE: It is intended that assessments of DKIM identities be basedassociated identity. An identity can use different identifiers, on the domain name, and not includeassumption that the selector. This permitsdifferent streams might produce different assessments. For example, even the selectorbest-run marketing campaigns will tend to be used only for key administration, rather than having an effect on reputation assessment. [[anchor7: Theproduce some complaints that can affect the reputation of the associated identifier. Whereas a selector could become relevant if itstream of transactional messages is knownlikely to have "gone rogue" before the DNS owner has a chance to publisheda new zone update which containsmore pristine reputation. Determining that the identifier's use is valid is quite different from determining that the content of a revoked key.]] 2.2.2. Third Party Key Management ???????????????? [[anchor9: what are we trying to cover here?message is valid. The case where a 3rd party generates keys and provides the public key toformer means only that the domain owner to publish? Oridentifier for the case whereresponsible role, person or organization has been legitimately associated with a message. The latter means that the domain owner generates keys and providescontent of the private key tomessage can be believed and, typically, that the third party? Either way, I think we need some discussionclaimed author of 1st vs. 3rd party (preferably thatthe distinction has little relevance except incontent is correct. DKIM validates only the presence of ADSP, since otherwisethe reputationidentifier used to sign the message. Even when this identifier is validated, DKIM carries no implication that any of the signing domain and notmessage content, including the 1st or 3rd party nature of it is whatRFC5322.From field, is relevant.]] 3rd party generatesvalid. Surprisingly, this limit to the public / private key pair and sendssemantics of a DKIM signature applies even when the public key to be publishedvalidated signing identifier is the same domain name as is used in the DNS. 2.2.3. Storing Public Keys: DNS Server Software Considerations At a minimum, a DNS serverFrom: field! DKIM's only claim about message content is that handles queries for DKIM key records must allow the server administrators to add free-form TXT records. It would be better ifthe content cited in the DKIM records could be entered usingDKIM-Signature: field's h= tag have been delivered without modification. That is, it asserts message content integrity, not message content validity. As shown in Figure 1, this enhancement is a structured form, supportingcommunication between a responsible role, person or organization that signs the DKIM-specific fields. 2.2.4. Private Key Management: Deploymentmessage and Ongoing Operations 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 periodically to verifya recipient organization that assesses its trust in the permissions on the private key files remain secure. 2.3. DNS Signature Record Deploymentsigner and Maintenance Considerations Even with usethen makes handling decisions based on a collection of assessments, of which the DNS, one challenge is that DNS record management is usually operated by an administrative staff thatDKIM mechanism is different from those who operate an organization's email service.only a part. In order to ensure that DKIM DNS records are accurate,this imposesmodel, validation is an intermediary step, having the sole task of passing a requirement for careful coordination betweenvalidated Responsible Identifier to the two operations groups.Identity Assessor. The key point to remembercommunication is of a single Responsible Identifier that the DNS DKIM selectors WILLResponsible Identity wishes to have used by the Identity Assessor. The Identifier is the sole, formal input and should be changed over time. Some reasons for changingoutput value of DKIM selectors are well understood, while others are still theoretical. Theresigning. The Identity Assessor uses this single, provided Identifier for consulting whatever assessment data bases are several schemes that may be used to determinedeemed appropriate by the policies for changing DKIM selectors: o time based o associationsassessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter engine that considers a range of factors, along with clustersthis single output value; the range of servers ofactors can include ancillary information from the useDKIM validation. Identity Assessment covers a range of third party signers o security considerations A potential mistake in creatingpossible functions. It can be as simple as determining whether the DNS key recordidentifier is the erroneous use ofa backslash (\)member of some list, such as authorized operators or participants in the definition. Some implementations reading a zone file allowa backslash to be used anywhere, stripping any such occurrences. Other implementations only allow it togroup that might be used in frontof an quotation mark, storing the backslash in the record and causinginterest for recipient assessment. Equally, it can indicate a syntax errordegree of trust (reputation) that is to be generated by DKIM implementations readingafforded the record. 2.3.1. Time Basis and Security Considerationsactor using that identifier. The reason for changing the selector periodically is usually relatedextent to which the security exposureassessment affects handling of a system. Whenthe potential exposuremessage is, of course, determined later, by the private keys associated with theHandling Filter. +------+------+ +------+------+ | Author | | Recipient | +------+------+ +------+------+ | ^ | | | +------+------+ | -->| Handling |<-- | -->| Filter |<-- | +-------------+ | ^ V Responsible | +-------------+ Identifier +------+------+ | Responsible |. . . . . . . . . . .>| Identity | | Identity | . . | Assessor | +------+------+ . . +-------------+ | . . ^ ^ V . . | | +------------------.-------.--------------------+ | | | +------+------+ . . . . . +-------------+ | | | +-------------+ | | Identifier | | Identifier +--|--+ +--+ Assessment | | | Signer +------------->| Validator | | | Databases | | +-------------+ +-------------+ | +-------------+ | DKIM Service | +-----------------------------------------------+ Figure 1: Actors in a Trust Sequence using DKIM selector have reached sufficient levels,2.2. Choosing a DKIM Tag for the selector should be changed. (It is unclear currently what kindsAssessment Identifier The signer of metrics cana message needs to be usedable to aid in deciding when the exposure has reached sufficient levelsprovide precise data and know what that data will mean upon delivery to warrant changingthe selector.) For example, o Selectors shouldAssessor. If there is ambiguity in the choice that will be changed more frequentlymade on systemsthe receive side, then the sender cannot know what basis for assessment will be used. DKIM has three values that are widely exposed, than on systems that are less widely exposed. For example, a gateway system that has numerous externally-accessible services running onspecify identification information and it is more widely exposed thaneasy to confuse their use, although only one that ONLY runs a mail server. o Selectors should be changed more frequently on operating systems that are under wide attack. o Whiledefines the useformal input and output of DKIM information is transient, keysDKIM, with sufficient exposure do become stalethe other two being used for internal protocol functioning and should be changed. o Whenever you make a substantial system change,adjunct purposes, such as bringing up a new server, or making a major operating system change, you should consider changingauditing and debugging. The salient values include the selector. [[anchor14: above you refer to changings=, d= and i= parameters in the key, here you referDKIM- Signature: header field. In order to changingachieve the selector; they have not been explicitly declared as synonymous soend-to-end determinism needed for this could be confusing]] o Whenever there is either suspicion or evidence of the compromise of the system orcollaborative exchange from the private keys, you should changesigner to the selector. 2.3.2. Deploying New Selectors A primary consideration in changingassessor, the selector is remembering to change it. Itcore model needs to bespecify that the signer MUST provide the assessor with a standard part ofsingle, opaque value that the operational staff Methods and Proceduressigner wishes to have used for your systems. If they are separate, bothassessment. This value MUST be the mail team andbasis for DKIM-based assessment. The signer MAY provide the DNS team will be involved in deploying new selectors. When deployingassessor with a new selector, it needs tosecond, opaque value that MAY be phased in: 1. Generateused when reporting problems with the new public / private key pairend-to-end DKIM process and create a new selector record withMAY be used for additional analysis, such as by the public keyhigher-level Handling Filter. These values are opaque, in it. 2. Add the new selector record to your DNS. 3. Verifythat any internal semantics are known only to the new selector record cansigner and MUST NOT be used to verify signatures. 4. Turn on signing withassumed by the new private key. 5. RemoveAssessor, within the old private key from your servers. 6. After a periodconfines of time, remove the old selector from your DNS.DKIM's formal signing specification. Assessment MUST use a value as a single, complete and uninterpreted string. The time an unused selector should be kept in the DNS system is dependent on the reason it's being changed. Ifsingle, mandatory value that DKIM supplies as its output is: d= This specifies the private key has definitely been exposed,"domain of the corresponding selector should be removed immediately. Otherwise, longer periods are allowable. [[anchor16: interesting; should we have includedsigning entity." It is a "u=" ('until') tag on key records allowing an advertised "good until" timestamp?]] 2.3.3. Subdomain Considerations A Domain Namedomain name and is combined with the basis for making differential quality assessments aboutSelector to form a DKIM-signed message.DNS query. The adjunct values are: s= This tag specifies the Selector. 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 wayused to distinguishdiscriminate among such activities is to sign withdifferent domain names. That is, the organization should sign with sub-domain nameskeys that arecan be used for different organizational activities. 2.3.4. Delegating Signing Authority to a Third party Allowing third parties to sign email from your domain opens your system security to includethe securitysame d= domain name. As discussed in Section 4.3 of the third party's systems. At a minimum, you should not allow the third parties[I-D.ietf-dkim-overview]: "If verifiers were to useemploy the sameselector and private keyas your main mail system. It is recommended that each third partypart of a name assessment mechanism, then there would be given its own privateno remaining mechanism for making a transition from an old, or compromised, key and selector. This limitsto a new one." Consequently, the exposureSelector is not appropriate for any given private key, and minimizesuse as part or all of the impact if any given private key were exposed. 3. Signing 3.1. Deployment Creating messages that have DKIM signatures requires a modificationidentifier used to only two portions ofmake assessments. i= This tag is optional and provides the email service: o Addition of relevant DNS information. o Addition"[i]dentity of the signature byuser or agent (e.g., a trusted module withinmailing list manager) on behalf of which this message is signed." The identity can be in the organization'ssyntax of an entire email handling service.address or only a domain name. The signing module usesdomain name can be the appropriate private key to createsame as for d= or it can be a signature. The means by whichsub-name of the signing module obtainsd= name. NOTE: Although the private key is not specified by DKIM. Given that DKIM is intended for use duringi= identity has the syntax of an email transit, rather than for long-term storage,address, it is expected that keys will be changed regularly. Clearly this meansnot required to have that key information shouldsemantics. That is, "the identity of the user" need not be hard-coded into software. 3.1.1. DNS Records A receiver attempting to verify a DKIM signature must obtainthe public key that is associated withsame as the signature for that message. The DKIM-Signature header inuser's mailbox. For example the message will specifysigner might wish to use i= to encode user-related audit information, such as how they were accessing the basic domain name doingservice at the signing andtime of message posting. Therefore it is not possible to conclude anything from the selectori= string's (dis)similarity to be used foremail addresses elsewhere in the specific public key. Hence,header So, i= can have any of these properties: * Be a valid domain when it is the relevant <selector>._domainkey.<domain-name> DNS record needssame as d= * Appear to containbe a DKIM-related resource record (RR) that provides the public key information. The administratorsub-domain 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 typesd= but might not even exist * Look like a mailbox address but might have different semantics and therefore not function as a valid email address * Be unique for each message, such as indicating access details of DNS records. 3.1.2. Signing Module The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); common choices are expectedthe user for the specific posting This underscores why the tag needs to be department-level posting and delivering agents, as welltreated as boundary MTAsbeing opaque, since it can represent any semantics, known only to the open Internet. (Notesigner. Hence, i= serves well as a token that itis entirely acceptableusable like an Web cookie, for MUAsreturn to performthe signing ADMD -- such as for auditing and verification.) Hence the choice amongdebugging. Of course in some scenarios the modules depends upon software development and administrative overhead tradeoffs. [[anchor23: See earlier note about signing by MUAs beingi= string might provide a security concern]] One perspective that helps resolve this choice isuseful adjunct value for additional (heuristic) processing by the difference betweenHandling Filter. 2.3. Choosing the flexibilitySigning Domain Name A DKIM signing entity can serve different roles, such as author of content, versus operator of use by systems at (or close to)the MUA,mail service, versus operator of a reputation service. In these different roles, the centralized controlbasis for distinguishing among portions of email traffic can vary. For an entity creating DKIM signatures it is likely that different portions of their mail will warrant different levels of trust. For example: * Mail is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure,sent for different purposes, such as at its boundary MTA. 3.1.3. DKIM Signing Software Development Signer implementations should provide a convenient meansmarketing vs. transactional, and recipients demonstrate different patterns of generating DNS key records corresponding to the signer configuration. Support for automatic insertionacceptance between these. * For an operator of key records into the DNS is also highly desirable. If supported however, such mechanism(s) must be properly authenticated. A meansan email service, there often are distinct sub-populations of verifying that the signer configurationusers warranting different levels of trust or privilege, such as paid vs. free users, or users engaged in direct correspondence vs. users sending bulk mail. * Mail originating outside an operator's system, such as when it is compatibleredistributed by a mailing list service run by the operator, will warrant a different reputation from mail submitted by users authenticated with the signature policyoperator. It is also highly desirable. Disclosuretherefore likely to be useful for a signer to use different d= sub-domain names, for different message traffic streams, so that receivers can make differential assessments. However, too much differentiation -- that is, too fine a granularity of signing domains -- makes it difficult for the receiver to discern a private signature key componentsufficiently stable pattern of traffic for developing an accurate and reliable assessment. So the differentiation needs to achieve a third party allowsbalance. Generally in a trust system, legitimate signers have an incentive to pick a small stable set of identities, so that third partyrecipients and others can attribute reputations to impersonate the sender.them. The protectionset of private signature key datathese identities a receiver trusts is thereforelikely to be quite a critical concern. Signers should support use of cryptographic hardware providing key management features. 220.127.116.11. Signer Actions All Signers should: o Include any existing Sender header fieldbit smaller than the set it views as risky. The challenge in using additional layers of sub-domains is whether the signed header field list, ifextra granularity will be useful for the Sender header field exists. o ... Signers wishing to avoidassessor. In fact, potentially excessive levels invites ambiguity: if the useassessor does not take advantage of Third-Party Signatures should do everything listed above, and also: o Include the Sender header field name in the header field list ("h=" tag) under all circumstances, even if the Sender header field does not exist inthe header block. This prevents another entity from adding a Sender header field. o Publish Signing Practices that do not sanctionadded granularity, then what granularity will it use? That ambiguity would move the use of Third- Party Signatures. 3.1.4. Signing Policies and Practices Every organization (ADMD) will have its own policies and practices for deciding whenDKIM back 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, andthe likelihood that signing practices will change over time, it will be useful to have these decisions represented in some sortrealm of configuration information,heuristics, rather than being more deeply coded into the signing software. 3.2. Mailing Lists A mailing list often provides facilities to its administrator to manipulate parts ofthe mail messagesdeterministic processing that flow throughis its goal. Hence the list.challenge is to determine a useful scheme for labeling different traffic streams. The desired goalmost obvious choices are among different types of content and/or different types of authors. Although stability is essential, it is likely that messages flowing throughthe mailing listchoices will be verifiable by the recipient as being fromchange, over time, so the list, or failing that, as being fromscheme needs to be flexible. For those originating message content, the individual list members. There are several formsmost likely choice of mailing lists,sub- domain naming scheme will by based upon type of content, which interact with signing in different ways. o "Verbatim" mailing lists send messages without modification whatsoever. Theycan use content-oriented labels or service-oriented labels. For example: transaction.example.com newsletter.example.com bugreport.example.com support.example.com sales.example.com marketing.example.com where the choices are often implemented as MTA-based aliases. Sincebest dictated by whether they do not modifyprovide the message, signatures are unaffected and will continueIdentity Assessor with the ability to verify. It is not necessarydiscriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety. Again, the danger in providing too fine a granularity is that related message streams that are labeled separately will not benefit from an aggregate reputation. For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different sub-domain label for each customer. For example: widgetco.example.net moviestudio.example.net bigbank.example.net However it can also be appropriate to label by the forwarderclass of service or class of customer, such as: premier.example.net free.example.net certified.example.net Prior to re-signusing domain names for distinguishing among sources of data, IP Addresses have been the message; however, some may choosebasis for distinction. Service operators typically have done this by dedicating specific outbound IP Addresses to do so in orderspecific mail streams -- typically to certify thatspecific customers. For example, a university might want to distinguish mail from the message was sent throughAdministration, versus mail from the list. o "Digesting" mailing lists collect together one or more postings and then retransmit them, often onstudent dorms. In order to make adoption of a nightly basis,DKIM-based service easier, it can be reasonable to translate the subscription list. These are essentially entirely new messages which must be independently authored (that is, they will havesame partitioning of traffic, using domain names in place of the different IP Addresses. 2.4. Recipient-based Assessments DKIM gives the recipient site's Identity Assessor a "From" header field referringverifiable identifier to use for analysis. Although the list,mechanism does not make claims that the submitters) and signed by the Mailing List Manager itself, if they are signed at all. o "Resending" mailing lists receivesigner is a message, modifyGood Actor or a Bad Actor, it (oftendoes make it possible to add "unsubscribe" information or advertising), and immediately resendknow that message touse of the subscription list. They are problematic because they usuallyidentifier is valid. This is in marked contrast with schemes that do not changehave authentication. Without verification, it is not possible to know whether the "From" header field ofidentifier -- whether taken from the message, but they do invalidateRFC5322.From field, RFC5321.MailFrom command, or the signature inlike -- is being used by an authorized agent. DKIM solves this problem. Hence with DKIM, the process of modifyingAssessor can know that two messages with the message. In most cases, the list and/or its mail host should add its ownsame DKIM signature to list mail. This could be doned= identifier are, in fact, signed by the list management software,same person or organization. This permits a far more stable and accurate assessment of mail traffic using that identifier. DKIM is distinctive, in that it provides an outgoing MSA or MTA, or both. List management software often makes modificationsidentifier which is not necessarily related 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,any other identifier in the list providesmessage. Hence, the signer might be the author's ADMD, one of the operators along the transit path, or a verifiable, recognizable signature for list recipients.reputation service being used by one of those handling services. In some cases, the modifications madefact, a message can have multiple signatures, possibly by different of these actors. As discussed above, the mailing list software are simple enough that signatureschoice of identifiers needs to be based on incoming messagesdifferences that the signer thinks will stillbe verifiable after being remailed byuseful for the list. Itrecipient Assessor. Over time, industry practices establish norms for these choices. Absent such norms, it is still preferablebest for signers to distinguish among streams that have significant differences, while consuming the list sign its mail sosmallest number of identifiers possible. This will limit the burden on recipient Assessors. A common view about a DKIM signature is that recipients can distinguish between mail sent throughit carries a degree of assurance about some or all of the listmessage contents, and mail sent directlyin particular that the RFC5322.From field is likely to a list member.be valid. In fact, DKIM makes assurances only about the absenceintegrity of a list signature, a recipient may still be able to recognize and usethe original signaturesdata and not about its validity. Still, presumptions of the list members. The first two cases act in obvious ways and do not require further discussion. The remainder of this session applies onlyFrom: field validity remain a concern. Hence a signer using a domain name that is unrelated to the third case. 3.2.1. Mailing List Manager Actions Mailing List Managers should make every effortdomain name in the From: field can reasonably expect that the disparity will warrant some curiosity, at least until signing by independent operators has produced some established practice among recipient Assessors. 2.5. Filtering After assessing the signer of a message, each receiving site creates and tunes its own Handling Filter according to ensurecriteria specific for that messagessite. Still, there are commonalities across sites, and this section offers a discussion, rather than a specification, of some types of input to that process and how they relaycan be used. The discussion focuses on variations in Organizational Trust versus Message Risk. That is, the degree of positive assessment of a DKIM- signing organization, and which have Valid Signatures upon receipt also have Valid Signatures upon retransmission. In particular, Mailing List Managers that modifythe messagepotential danger present in ways that break existing signatures should: o Verify any existing DKIM Signatures. A DKIM-aware Mailing List Manager must NOT re-sign an improperly signedthe message in such a waystream signed by that would implyorganization. While it might seem that higher trust automatically means lower risk, the existing signature is acceptable. o Apply regular anti-spam policies. A Mailing List Manager should apply message content security policy justexperience with real-world operations provides examples of every combination of the two factors, as would be doneshown in Table 1. Only 3 levels of granularity are listed, in order to messages destinedkeep discussion manageable. This also ensures extensive flexibility for an individual user's mailbox. In fact,each site's detailed choices. +---+---------------------+--------------------+--------------------+ | | Low | Medium | High | | | | | | | | | | | | | | | | | | | | | | O | | | | | R | | | | | G | | | | | | | | | | T | | | | | R | | | | | U | | | | | S | | | | | T | | | | | | | | | | M | | | | +---+---------------------+--------------------+--------------------+ | * | Unknown org, | Registered org, | Good Org, | | L | Few msgs: | New Identifier: | Good msgs: | | o | _Mild filtering_ | _Medium filtering_ | _Avoid FP(!)_ | | w | | | | | * | Unknown org, | Registered org, | Good org, Bad msg | | M | New Identifier: | Mixed msgs: | burst: | | e | _Default filtering_ | _Medium filtering_ | _Accept & Contact_ | | d | | | | | i | | | | | u | | | | | * | Black-Listed org, | Registered org, | Good org, | | H | Bad msgs: | Bad msgs: | Compromised: | | i | _Avoid FN(!)_ | _Strong filtering_ | _Fully blocked_ | | g | | | | | h | | | | +---+---------------------+--------------------+--------------------+ Table 1: Organizational Trust vs. Message Risk The table indicates preferences for different handling of different combinations, such as tuning filtering to avoid False Positives (FP) or avoiding False Negatives (FN). Perhaps unexpectedly, it also lists a Mailing List Managercase in which the receiving site might apply a higher standard to messages destinedwish to a mailing listdeliver problematic mail, rather than would normally be applied to individual messages. NON-NORMATIVE RATIONALE: Since reputation will accrue to signers, Mailing List Managers should verifyredirecting it, but also of course contacting the source and contentsigning organization, seeking resolution of messages before they are willing to sign lest their reputation be sullied by nefarious parties. o Add a Sender header field using a valid address pointing back tothe Mailing List Administrator or an appropriate agent (such as an "owner-" orproblem. 3. DKIM Key Generation, Storage, and Management By itself, verification of a "-request" address). o Signdigital signature only allows the resulting messageverifier to conclude with a signaturevery high degree of certainty that is valid forthe Sender header field address. The Mailing List Manager should NOT sign messages for which they are unwilling to accept responsibility. Mailing List Managers MAY: o Reject messagessignature was created by a party with signaturesaccess to the corresponding private signing key. It follows that do not verify or are otherwise Suspicious. [[anchor29: Is "Suspicious" stilla formal term in DKIM?]] 3.3. Signature Transition Strategy [[anchor31: I'm not entirely clear what is meant by "algorithm" beyondverifier requires means to (1) obtain the combinationpublic key for the purpose of key, selector,verification and signing parameters included in(2) infer useful attributes of the DKIMSignature header. Unless I'm way off base, I think this section belongs either here under "Signing", or in section 1 under "Key Generation, Storage, and Management". Either way, we should be more clear about what is meant bykey holder. In a traditional Public Key Infrastructure (PKI), the term "signature algorithm".]] Deploymentfunctions of a new signature algorithm without a 'flag day' requires a transition strategy such that signerskey distribution and verifiers can phase in support forkey accreditation are separated. In DKIM, these functions are both performed through the new algorithm independently,DNS [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and (if necessary) phase out support forM. Thomas, "DomainKeys Identified Mail (DKIM) Signatures," May 2007.). In either case, the old algorithm independently. [Note: this section assumes thatability to infer semantics from a security policy mechanism exists. Itdigital signature depends on the assumption that the corresponding private key is subject to change.] [[anchor32: safeonly accessible to presume ADSP?]] DKIM achieves these requirements through two features: First,a signed message may contain multiple signatures created by the same signer. Second, the security policy layer allowsparty with a particular set of attributes. In traditional PKI a Trusted Third Party (TTP) vouches that the signing algorithms in usekey holder has been validated with respect to be advertised, thus preventinga downgrade attack. 3.3.1. Signer transition strategy Let the old signing algorithm be A and the new signing algorithm be B.specified set of attributes. The sequencerange of events by which a Signerattributes that may introducebe attested in such a scheme is thus limited only to the new signing algorithm B, without disruptiontype of service to legacy verifiers, is as follows: 1. Signer signs with algorithm A A. Signer advertisesattributes that it signs with algorithm A 2. Signer signs messages twice, with both algorithm Aa TTP can establish effective processes for validating. In DKIM, TTPs are not employed and algorithm B A. The signer tests new signing configuration B. Signer advertisesthe functions of key distribution and accreditation are combined. Consequently there are only two types of inference that it signsa signer may make from a key published in a DKIM Key Record: 1. That a party with either algorithm A or algorithm B 3. Signer determines that support for Algorithm A is no longer necessary 4. Signer determines that support for algorithm A isthe ability to be withdrawn A. Signer removes advertisement for Algorithm A B. Signer waitscontrol DNS records within a DNS zone intends to claim responsibility for cached copies of earliermessages signed using the corresponding private signature policykey. 2. That use of a specific key is restricted to expire C. Signer stops signing with Algorithm A 3.3.2. Verifier transition strategya particular subset of messages. The actionsability to draw any useful conclusion from verification of a digital signature relies on the verifier are independent ofassumption that the signer's actions and do not needcorresponding private key is only accessible to be performed ina party with 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 decisionsset of attributes. In the verifier must make are therefore: o The verifier MAY change the degreecase of confidence associated with any signature at any time, including determiningDKIM, this means that a given signature algorithm provides a limited assurance of authenticity at a giventhe party that created the corresponding DKIM key strength. * A verifier MAY evaluate signature recordsrecord in any order it chooses, including usingthe signature algorithmspecific zone intended to chooseclaim responsibility for the order. o The verifier MAY makesigned message. Ideally we would like to draw a determinationstronger conclusion, that Algorithm A does not offerif we obtain a useful level of security, orDKIM key record from the DNS zone example.com, that the costlegitimate holder of verifyingthe signature is less thanDNS zone example.com claims responsibility for the value of doing so. *signed message. In order for this case the verifier would ignore signatures created using algorithm A and referencesconclusion to algorithm A in policy records wouldbe treated as ifdrawn it is necessary for the algorithm were not implemented. o Theverifier MAY decideto add support for additional signature algorithms at any time. * The verifier MAY add support for algorithm B at any time. 4. Verifying 4.1. Verifier Verifiers should treatassume that the resultoperational security of the verification step as an inputDNS zone and corresponding private key are adequate. 3.1. Private Key Management: Deployment and Ongoing Operations Access to signing keys must be carefully managed to prevent use by unauthorized parties and to minimize the message evaluation process rather than as providingconsequences should a final decision. The knowledge thatcompromise occur. While a messageDKIM signing key is authentically sent by a domain does not say much about the legitimacyused to sign messages on behalf of many mail users, the message, unless the characteristicssigning key itself should be under direct control of as few key-holders as possible. Should a key-holder leave the domain claiming responsibilityorganization, all signing keys held by that key holder should be withdrawn from service and if appropriate, replaced. If key management hardware support is available, it should be used. If keys are known. In particular, verifiersstored in software, sppropriate file control protections must be employed and any location in which the private key is stored in plaintext form should be excluded from regular backup processes and should NOT automatically assume that an email message that doesnot contain a signature, orbe accessible through any form of network including private local area networks. Auditing software should be used periodically to verify that containsthe permissions on the private key files remain secure. Wherever possible a signature that does not verify, is forged. Verifierskey should treatexist in exactly one location and be erased when no longer used. Ideally a signature that failskey pair should be generated as close to verifythe samesigning point as if no signature were present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP Verificationpossible and only the public key component transferred to another party. If this is performed withinnot possible, the private key MUST be transported in an ADMDencrypted format that wishes to make assessments based uponprotects the DKIM signature's domain name. Any component withinconfidentiality of the ADMD that handles messages, whethersigning key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in transit or being delivered, can do the verifying and subsequent assessments. Verificationplaintext form. Key escrow schemes are not necessary and assessment might occur withinshould not be used. In the same software mechanism, such asunlikely event of a Boundary MTA, or an MDA. Or theysigning key becomming lost, a new signature key pair may be separated, suchgenerated 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 -- sucheasily as filtering or presentation to the recipient user -- depend on trade-offsrecovery from a key escrow scheme. Responsibility for flexibility, control, and operational ease. An added concern is that the linkage between verification and assessment entails essential trust:the assessment module must havesecurity of a strong basissigning key should ultimately vest in a single named individual. Where multiple parties are authorized to sign messages, each signer should use a different key to enable accountability and auditing. Best practices for believing that the verification information is correct. 4.2. DNS Client The primary meansmanagement of publishing DKIMcryptographic keying material require keying material to be refreshed at regular intervals, particular where key information, initially,management is achieved through DNS TXT records. Some DNS client software might have problems obtaining these records; as DNS client software improvessoftware. While this will not be a concern. 4.3. Boundary Enforcement In order for an assessment modulepractice is highly desirable it is of considerably less importance than the requirement to trustmaintain the information it receives about verification (e.g., Authentication-Results header fields), it must eliminate verification information originating from outsidesecrecy of the ADMDcorresponding private key. An operational practice in which the assessment mechanism operates. Asprivate key is stored in tamper proof hardware and changed once a matter of friendly practice, ityear is equally important to make sure that verification information generated within the ADMD not escape outside of it. In most environments,considerably more desirable than one in which the easiest way to enforce thissignature key is to place moduleschanged on an hourly basis but maintained in the receiving and sending Boundary MTA(s) that strip any existing verification information. 4.4. Filteringsoftware. 3.2. Storing Public Keys: DNS Server Software Developers of filtering schemes designedConsiderations In order to acceptuse DKIM authentication results as input should be aware that their implementations will be subjecta DNS domain holder requires (1) the ability to counter-attack by email abusers. The efficacycreate the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of a filtering scheme cannot therefore be determinedspurious DNS records by reference to static test vectors alone; resistancean attacker. 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 counter attack must also be considered. Naive learning algorithmsensure that only consider the presence or absence of a verifiedDKIM signature, without considering more information about the message,DNS records are vulnerable to an attack in which spammers or other malefactors sign all their mail, thus creatingaccurate, this imposes a large negative valuerequirement for presence of a DKIM signature incareful coordination between the hope of discouraging widespread use.two operations groups. If heuristic algorithmsthe best practices for private key management described above are employed, they shouldobserved, such deployment is not a one time event, DNS DKIM selectors will be trained on feature setschanged over time signing keys are terminated and replaced. At a minimum, a DNS server that sufficiently revealhandles queries for DKIM key records must allow the server administrators to add free-form TXT records. It would be better if the internal structure ofthe DKIM responses. In particularrecords could be entered using a structured form, supporting the algorithmDKIM-specific fields. Ideally DNSSEC  should considerbe employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the domains purportingcase that NSEC3 [RFC 5155] records are employed to claim responsibility forprevent insertion attack, the signature, rather thanOPT-OUT flag must be set clear. 3.2.1. Assignment of Selectors Selectors are assigned according to the existenceadministrative needs of the signing domain, such as for rolling over to a signaturenew key or not. Unless a scheme can correlate the DKIM signature with accreditation or reputation data,for delegating of the presenceright to authenticate a portion of the namespace to a DKIM signature should be ignored. 5. DKIM Deployment Considerations for Email Agents 5.1. Email Infrastructure Agentstrusted third party. Examples include: jun2005.eng._domainkey.example.com widget.promotion._domainkey.example.com It is expectedintended that the most common venue for aassessments of DKIM implementation willidentities be withinbased on the infrastructuredomain name, and not include the selector. While past practice of an organization's email service,a signer may permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a department orchange of signing softeware may cause such heuristics to fail at any time. 3.3. Per User Signing Key Management Issues While a boundary MTA. Outbound: An MSA or Outbound MTA should allowsigner may establish business rules, such as issue of individual signature keys for the automatic verificationeach end-user, DKIM makes no provision for communicating these to other parties. Out of band distribution of the MTA configurationsuch thatbusiness rules is outside the MTA can generate an operator alert if it determines that itscope of DKIM. Consequently there is (1) an edge MTA, and (2) configuredno means by which external parties may make use of such keys to send emailattribute messages that do not complywith the published DKIM sending policy. An outboundany greater granularity than a DNS domain. If per-user signing keys are assigned for internal purposes (e.g. authenticating messages sent to an MTA shouldfor distribution), the following issues need to be aware that users may employ MUAs that add their ownconsidered before using such signatures and be preparedas an alternative to take steps necessarytraditional edge signing at the outbound MTA: External verifiers will be unable to ensure thatmake use of the message sent is in compliance with the advertised email sending policy. [[anchor42: MUAs being able to sign is a security consideration; MUAs are more prone to vulnerabilities, so an MUA having directadditional signature granularity without access to signingadditional information passed out of band with respect to DKIM-base. If the number of user keys is a security concern; general MUA vulnerability came up duringlarge, the IETF Security Directorate reviewefficiency of draft-kucherawy-sender-auth-header]] Inbound: An inbound MTA or an MDA that does not support DKIM should avoid modifying messages in ways that prevent verificationlocal caching of key records by other MTAs, or MUAs to which the messageverifiers will be lower. A large number of end users may be forwarded. An inbound MTA orless likely to be able to manage private key data securely on their personal computer than an MDA may incorporateadministrator running an indicationedge MTA. 3.4. Third Party Signer Key Management and Selector Administration A DKIM key record only asserts that the holder of the verification results intocorresponding domain name makes a claim of responsibility for messages signed under the message,corresponding key. In some applications, such as using an Authentication-Results header field. [I-D.kucherawy-sender-auth-header] Intermediaries: An email intermediarybulk mail delivery it is both an inbound and outbound MTA. Each of the requirements outlined in the sections relatingdesirable to MTAs apply. Ifdelegate the intermediary modifies a message inability to make a way that breaks the signature,claim of responsibility to another party. In this case the intermediary + should deploy abuse filtering measures ontrust relationship is established between the inbound mail,domain holder and + MAY remove all signatures that will be broken In additionthe intermediary MAY: + Verifyverifier but the messageprivate signature prior to modification. + Incorporate an indication of the verification results into the message, such as using an Authentication-Results header field. [I-D.kucherawy-sender-auth-header] + Sign the modified message including the verification results (e.g., the Authentication-Results header field). 5.2. Mail User Agent DKIMkey is designed to support deploymentheld by a third party. Signature keys used by a third party signer should be kept entirely separate from those used by the domain holder and use in email componentsother than an MUA. However an MUA MAY also implement DKIM features directly. Outbound: If an MUA is configured to send email directly, rather than relay it through an outbound MSA,third party signers. As with any other private key, the MUAsignature key pair should be considered as if it were an outbound MTA forgenerated by the purposesthird party signer and the public component of DKIM. An MUA MAY support signing even if mail isthe key transmitted to be relayed through an outbound MSA. In this casethe signature applied bydomain holder rather than have the MUA may be in additiondomain holder generate the key pair and transmit the private component to any MSA signature. Inbound: An MUA MAY rely on a report ofthe third party signer. Domain holders should adopt a DKIM signature verification that took place at some point inleast privilege approach and grant third party signers the inbound MTA path (e.g., an Authentication-Results header field), or an MUA MAYminimum access necessary to perform DKIM signature verification directly. A verifying MUA should allow forthe case where mail is modified indesired function. Limiting the inbound MTA path. It is common for components of an ADMD's email infrastructure to do violenceaccess granted to a message, such asThird Party Signers serves to render a DKIM signature invalid. Hence, usersprotect the interests of MUAs that support DKIM signing and/or verifying need a basis for knowing thatboth parties. The domain holder minimizes their associated email infrastructure will not break a signature. 6. Migrating from DomainKeys 6.1. Signing DNS Records: DKIM is upwardly compatible with existing DomainKeys (DK) [RFC4870] DNS records, so thatsecurity risk and the Trusted Third Party Signer avoids unnecessary liability. In the most restrictive case a DKIM module does not automatically require additional DNS administration. However DKIM has enhanceddomain holder maintains full control over the DomainKeys DNScreation of key record format by adding several additional optional parameters. [[anchor46: Explicit "g=" has different meaning in DomainKeysrecords and DKIM,employ appropriate key record restrictions to enforce restrictions on the messages for which has been an interoperability issue inthe past (DomainKeys interprets that as "match any" while DKIM interprets it as "match none")]] Boundary MTA: The principal use of DomainKeys is at Boundary MTAs. Because no operational transition is ever instantaneous, itthird party signer is not adviseable for existing DomainKeys signers to switchable to DKIM without continuingsign. If such restrictions are impractical, the domain holder should delegate a DNS subzone for publishing key records to perform DomainKeys signing. A signerthe third party signer. The domain holder should addnot allow a DKIM signaturethird party signer unrestricted access to their DNS service for the purpose of publishing key records. 3.5. Key Pair / Selector Lifecycle Management Deployments should establish, document and observe processes for managing the entire lifecycle of a messagepublic key pair. 3.5.1. Example Key Deployment Process When it is determined that also hasa DomainKeys signature, until such time as DomainKeys receive- side supportnew key pair is sufficiently reduced. With respect torequired: 1. A Key Pair is generated by the signing policies, a reasonable, initial approachdevice 2. A proposed key selector record is generated and transmitted to use DKIM signatures inthe same way as DomainKeys signatures are already being used. 6.2. VerifyingDNS Client:administration infrasrtructure. 3. The DNS queries foradministration infrastructure verifies the authenticity of the DKIMkey selector registration request. If accepted 1. A key selector is assigned. 2. The corresponding key record usepublished in the same Domain Name naming conventions as were usedDNS. 3. Wait for DomainKeys, and the same basic record format. No changes to theDNS client should be required. Verifying module: Seeupdates to propagate (if necessary). 4. Report assigned key selector to signing device. 4. Signer verifies correct registration of the section on Signing above. 7. Example Uses A DKIM signature tellskey record. 5. Signer begins generating signatures using the signature verifiernew key pair. 6. Signer terminates any private keys that the ownerare no longer required due to issue of a particular domain name accepts responsibility for the message. Combining this information with informationreplacement. 3.5.2. Example Key Termination Process When it is determined that allowsa private signature key is no longer required: 1. Signer stops using the historyprivate key for signature operations. 2. Signer deletes all records of the domain name owner to be assessed may allow processingprivate key, including in- memory copies at the message, based onsigning device. 3. Signer notifies the probabilityDNS administration infrasrtructure that the message is likely to be trustworthy, or not, without the need for heuristic content analysis. 7.1. Protection of Internal Mail One identitysigning key is particularly amenable to easywithdrawn from service and accurate assessment: The organization's own identity. Members of an organization tend to trust messagesthat purport tothe corresponding key records may be withdrawn from within that organization. However Internet Mail does not provideservice at a straightforward meansspecified future date. 4. The DNS administration infrastructure verifies the authenticity of determining whether such mail is, in fact, from withinthe organization. DKIM can be used to remedy this exposure.key selector termination request. If the organization signs all of its mail, then its boundary MTAs can lookaccepted 1. The key selector is scheduled for mail purporting to be from the organization but does not containdeletion at a verifiable signature. Such mail can be presumed to be spurious. WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN SIGNATURE???? Need to include some of the breakage examples from ADSP spec. 7.2. Recipient-based Assessments Recipients of large volumes of email can internally generate reputation datafuture time determined by site policy. 2. Wait for email senders. Recipients of smaller volumes of messages are likely to needdeletion time to acquire reputation data from a third party. In either case the use of reputation dataarrive 3. The key selector is intrinsically limited to email sendersdeleted 4. Signing Creating messages that have established a prior history of sending messages. In fact, anone or more DKIM signatures, requires support in only two outbound email receivingservice may be in a position to establish bilateral agreementscomponents: o A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with particular senders, such as business partners orunderscores -- and resource records (RR). o A trusted bulk sending services. Although itmodule, called the Signing Module, which is not practical for each recipientwithin the organization's outbound email handling service and which creates and adds the DKIM-Signature: header field(s) to accredit every sender,the definition of core networks of explicit trust canmessage. If the module creates more than one signature, there needs to be quite useful. 7.2.1. Third-party Reputation and Accreditation Services For scaling efficiency,the appropriate means of telling it is appealingwhich one(s) to use Trusted Third Party reputation and accreditation services,use. If a large number of names is used for signing, it will help to allow an email senderhave the administrative tool support a batch processing mode. 4.1. DNS Records A receiver attempting to obtainverify a single assessmentDKIM signature obtains the public key that is then recognized by every email recipient that recognizesassociated with the Trusted Third Party. 7.3. DKIM Supportsignature for that message. The DKIM-Signature: header in the Client The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components ofmessage contains the originatingd= tag with the basic domain name doing the signing and receiving ADMDs. However there is nothing in DKIM that is specific to those venues. In particular, it should be possibleserving as output to support signingthe Identity Assessor, and verifying in MUAs. DKIM requires that all verifiers treat messagesthe s= tag with signatures that do not verify as if they are unsigned. If verification inthe client is to be acceptable to users, it is also essentialselector that successful verification of a signature not result in a less than satisfactory user experience comparedis added to leavingthe message unsigned. 7.4. Per user signatures Although DKIM's use of domain names is optimizedname, for a scope of organization-level signing, it is possiblefinding the specific public key. Hence, the relevant <selector>._domainkey.<domain-name> DNS record needs to administer sub-domains and/or selectors incontain a wayDKIM-related RR that supports per-user signing. NOTE: As stated earlier, it is important to distinguish betweenprovides the use of selectors for differential administrationpublic key information. The administrator of keys, versusthe use of sub-domains for differential reputations. It's also probably a good idea to note that receivers are unlikely to pay attention to reputation at a user granularity even if it's technically feasible to publish it. As a constraint on an authorized DKIM signing agent, its associated key record can specify restrictions onzone containing the email addresses permitted to be signed with thatrelevant domain and key. A typical intent ofname adds this featureinformation. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to allow a companysupport DKIM names, such as with underscores, and to delegate theadd new types of DNS information. 4.2. Signing Module The module doing signing authority for bulk marketing communications withoutcan be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); obvious choices include department-level posting agents, as well as outbound boundary MTAs to the risk of effectively delegatingopen Internet. However any other module, including the authority to sign messages purportingauthor's MUA, is potentially acceptable, as long as the signature survives any remaining handling within the ADMD. Hence the choice among the modules depends upon software development, administrative overhead, security exposures and transit handling tradeoffs. One perspective that helps to comeresolve this choice is the difference between the increased flexibility, from placement at (or close to) the domain-owning organization's CEO. NOTE: Any schemeMUA, versus the streamlined administration and operation, that involves maintenance of a significant number of public keysis likely to require infrastructure enhancements, to support that management. For example, a systemmore easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA. Note the discussion in whichSection 2.2, concerning use of the end user is required to generate a publici= tag. The signing module uses the appropriate private key pair and transmit itto create one or more signatures. The means by which the DNS administrator out of bandsigning module obtains the private key(s) is not likely to meet acceptance criteriaspecified by DKIM. Given that DKIM is intended for either usability or security. 8. Security Considerations TBD 9. IANA Considerations TBD 10. Acknowledgements TBD 11. 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 Fielduse during email transit, rather than for Indicating Message Authentication Status", draft-kucherawy-sender-auth-header-17 (work in progress), October 2008. [RFC0989] Linn, J.long-term storage, it is expected that keys will be changed regularly. For administrative convenience, key information should not be hard-coded into software. 4.3. Signing Policies and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message enciphermentPractices Every organization (ADMD) will have its own policies and authentication procedures", RFC 989, February 1987. [RFC1034] Mockapetris, P., "Domain names - conceptspractices for deciding when to sign messages (message stream) and facilities", STD 13, RFC 1034, November 1987. [RFC1848] Crocker, S., Galvin, J., Murphy, S.,with what domain name, selector and N. Freed, "MIME Object Security Services", RFC 1848, October 1995. [RFC1991] Atkins, D., Stallings, W.,key. Examples of particular message streams include all mail sent from the ADMD, versus mail from particular types of user accounts, versus mail having particular types of content. Given this variability, and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2440] Callas, J., Donnerhacke, L., Finney, H.,the likelihood that signing practices will change over time, it will be useful to have these decisions represented through run-time configuration information, rather than being hard-coded into the signing software. As noted in Section 2.3, the choice of signing name granularity requires balancing administrative convenience and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3156] Elkins, M., Del Torto, D., Levien, R.,utility for recipients. Too much granularity is higher administrative overhead 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., "Analysiswell might attempt to impose more differential analysis on the recipient than they wish to support. In such cases, they are likely to use only a super-name -- right-hand substring -- of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertisedthe signing name. When this occurs, the signer will not know what portion is being used; this then moves DKIM back to the non-deterministic world of heuristics, rather than the mechanistic world of signer/recipient collaboration that DKIM seeks. 5. Verifying To be added. 6. Taxonomy of Signatures A DKIM signature tells the signature verifier that the owner of a particular domain name accepts some responsibility for the message. It does not, in and of itself, provide any information about the trustworthiness or behavior of that identity. What it does provide is a verified identity to which such behavioral information can be associated, so that those who collect and use such information can be assured that it truly pertains to the identity in question. This section lays out a taxonomy of some of the different identities, or combinations of identities, that might usefully be represented by a DKIM signature. 6.1. Single Domain Signature Perhaps the simplest case is when an organization signs its own outbound email using its own domain in the d= tag of the signature. For example, Company A would sign the outbound mail from its employees with d=companyA.example. In the most straightforward configuration, the addresses in the DNS (DomainKeys)",RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M.,5322 From would also be in the companyA.example domain, but that direct correlation is not required. A special case of the Single Domain Signature is an Author Signature as defined by the Author Domain Signing Practices specification. Author signatures are signatures from an authors organization that have an i= value that matches the From: address of the message. Under the ADSP specification, an i= value matches a RFC 5322 From address when the domains of the two match exactly, and if the i= value contains a local part it also matches the local part of the From: address exactly. Although an author signature might in some cases be proof against domain name spoofing the RFC 5322 From address, it is important to note that the DKIM and ADSP validation apply only to the exact address string and not to look-alike addresses nor to the human- friendly "display-name" or names and addresses used within the body of the message. That is, it protects only against the misuse of a precise address string within the RFC5322 From field and nothing else. For example, a message from firstname.lastname@example.org with a valid signature where i=d0main.example would fail an ADSP check because the signature domain, however similar, is distinct; however a message from email@example.com with a valid signature where i=d0main.example would pass an ADSP check, even though to a human it might be obvious that d0main.example is likely a malicious attempt to spoof the domain domain.example. This example highlights that ADSP, like DKIM, is only able to validate a signing identifier: it still requires some external process to attach a meaningful reputation to that identifier. 6.2. Parent Domain Signature Another approach that might be taken by an organization with multiple active subdomains is to apply the same (single) signature to mail from all subdomains. In this case, the signature chosen would usually be the signature of a parent domain common to all subdomains. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature with d=domain.example. This approach has the virtue of simplicity, but it is important to consider the implications of such a choice. As discussed in Section 2.3, if the type of mail sent from the different subdomains is significantly different or if there is reason to believe that the reputation of the subdomains would differ, then it may be a good idea to acknowledge this and provide distinct signatures for each of the subdomains (d=marketing.domain.example, sales.domain.example, etc.). However, if the mail and reputations are likely to be similar, then the simpler approach of using a single common parent domain in the signature may work well. Another approach to distinguishing the streams using a single DKIM key would be to leverage the i= tag in the DKIM signature to differentiate the mail streams. For example, marketing email would be signed with i=marketing.domain.example and d=domain.example. It's important to remember, however, that under core DKIM semantics the i= identifer is opaque to receivers. That means that it will only be an effective differentiator if there is an out of band agreement about the i= semantics (e.g., the semantics specified in ADSP). 6.3. Third Party Signature A signature whose domain does not match the domain of the RFC 5322 From address is sometimes referred to as a third party signature. In certain cases even the parent domain signature described above would be considered a third party signature because it would not be an exact match for the domain in the From: address. Although there is often heated debate about the value of third-party signatures, it is important to note that the DKIM specification attaches no particular significance to the identity in a DKIM signature. The identity specified within the signature is the identity that is taking responsibility for the message, and it is only the interpretation of a given receiver that gives one identity more or less significance than another. In particular, most independent reputation services assign trust based on the specific identifier string, not its "role": in general they make no distinction between, for example, an author signature and a third party signature. For some, a signature unrelated to the author (identity in the RFC 5322 From address) is less valuable because there is an assumption that the presence of an author signature guarantees that the use of the address in the From: header is authorized. For others, that relevance is tied strictly to the recorded behavioral data assigned to the identity in question, i.e. its trust assessment or reputation. The reasoning here is that an identity with a good reputation is unlikely to maintain that good reputation if it is in the habit of vouching for messages that are unwanted or abusive; in fact, doing so will rapidly degrade its reputation so that future messages will no longer benefit from it. It is therefore low risk to facilitate the delivery of messages that contain a valid signature of a domain with a strong positive reputation, independent of whether or not that domain is associated with the address in the RFC5322 From header field of the message. Third party signatures encompass a wide range of identities. Some of the more common are: Service Provider: In cases where email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or other type of service provider, that service provider may choose to DKIM sign outbound mail with either its own identifier -- relying on its own, aggregate reptutation -- or with a subdomain of the provider that is unique to the message author but still part of the provider's aggregate reputation. Such service providers may also encompass delegated business functions such as benefit management, although these will more often be treated as trusted third party senders (see below). Parent Domain. As discussed above, organizations choosing to sign for mail originating from subdomains with a parent domain signature may also considered to be using 3rd party signatures in some configurations, depending on whether or not the "t=s" tag is used to constrain the parent signature to apply to only its own specific domain. The default is that a parent domain signature is considered valid for its subdomains. Reputation Provider: Another possible category of third party signature would be the identity of a 3rd party reputation provider. Such a signature would indicate to receivers that the message was being vouched for by that 3rd party. 6.4. Using Trusted 3rd Party Senders For most of the cases described so far, there has been an assumption that the identity doing the signing was responsible for creating and maintaining their own DKIM signing infrastructure, including their own keys, and signing with their own identity. A different model arises when an organization uses a trusted third party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation: in other words, the mail would come out of the trusted 3rd party's mail servers, but the signature applied would be that of the controlling organization. This can be done by having the 3rd party generate a key pair that is designated uniquely for use by that trusted 3rd party and publishing the public key in the controlling organization's DNS domain, thus enabling the third party to sign mail using the signature of the controlling organization. For example, if Company A outsources its employee benefits to a 3rd party, they can use a special keypair that enables the benefits company to sign mail as "companyA.example". Because the keypair is unique to that trusted 3rd party, it is easy for Company A to revoke the authorization if necessary by simply removing the public key from the companyA.example DNS. In this scenario, it is usually a good idea to limit the specific identities that can be used by even trusted third parties. The DKIM g= tag enables a key record to specify one particular From: address local part that must be specified in the i= tag of the signature: for example, "g=benefits" would require a signature header tag of "i=benefits@companyA.example". It is important to note that although this distinction will be clear to the verifier it may be invisible to the recipient: there is no constraint within the DKIM verification process that constrains that specific i= value to correspond to any of the other message headers. A more reliable way of distinguishing the third part mail stream would be to create a dedicated subdomain (e.g. benefits.companyA.example) and publish the public key there; the signature would then use d=benefits.companyA.example. 6.4.1. DNS Delegation Another possbility for configuring trusted third party access is to have Company A use DNS delegation and have the designated subdomain managed directly by the trusted third party. In this case, Company A would create a subdomain benefits.companya.example, and delegate the DNS management of that subdomain to the benefits company so it could maintain its own key records. Should revocation become necessary, Company A could simply remove the DNS delegation record. 6.5. Multiple Signatures A simple configuration for DKIM-signed mail is to have a single signature on a given message. This works well for domains that manage and send all of their own email from a single source, or for cases where multiple email streams exist but each has its own unique key pair. It also represents the case in which only one of the participants in an email sequence is able to sign, no matter whether they represent the author or one of the operators. The examples thus far have considered the implications of using different identities in DKIM signatures, but have used only one such identity for any given message. In some cases, it may make sense to have more than one identity claiming responsiblity for the same message. One important caveat to the use of multiple signatures is that there is currently no clear consensus amoung receivers on how they plan to handle them. The opinions range from ignoring all but one signature (and the specification of which of them is verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identfier that represents the most positive trust assessment. It is likely that the industry will evolve to accept multiple signatures using either option two or three, but it may take some time before that approach becomes pervasive. There are a number of situations where applying more than one DKIM signature to the same message might make sense. A few examples are: Companies with multiple subdomain identities: A company that has multiple subdomain sending distinct categories of mail might choose to sign with distinct subdomain identities to enable each subdomain to manage its own identity. However, it might also want to provide a common identity that cuts across all of the distinct subdomains. For example, Company A may sign mail for its sales department with a signature where d=marketing.companya.example, and a second signature where d=companya.example Service Providers: Service providers may, as described above, choose to sign outbound messages with either their own identity or with an identity unique to each of their clients (possibly delegated). However, they may also do both: sign each outbound message with their own identity as well as the identity of each individual client. For example, ESP A might sign mail for their client Company B with their service provider signature d=espa.example, and a second client-specific signature where d= either companyb.example, or companyb.espa.example. The existence of the service provider signature could, for example, help cover a new client while they establish their own reputation, or help a very small volume client who might never reach a volume threshold sufficient to establish an individual reputation. Forwarders Forwarded mail poses a number of challenges to email authentication. DKIM is relatively robust in the presence of forwarders as long as the signature is designed to avoid message parts that are likely to be modified, although some forwarders do make modifications that can invalidate a DKIM signature. However, some forwarders such as mailing lists or forward article to a friend services, might choose to add their own signature to outbound messages to vouch for it having legitimately originated from the designated service. In this case, the signature would be added even in the presence of a pre-existing signature, and both signatures would be relevant to the verifier. Any forwarder that modifies messages in ways that will break pre- existing DKIM signatures should always sign its forwarded messages. Reputation Providers: Although third party reputation providers today use a variety of protocols to communicate their information to receivers, it is possible that they, or other organizations willing to put their "seal of approval" on an email stream might choose to use a DKIM signature to do it. In nearly all cases, this "reputation" signature would be in addition to the author or originator signature. 7. Example Usage Scenarios Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or different, and so on. This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive, but to illustrate a set of key deployment considerations. 7.1. Author's Organization - Simple The simplest DKIM configuration is to have all mail from a given organization (Company A) be signed with the same d= value (e.g. d=companya.example). If there is a desire to associate a user identity or some other related information, the i= value can become uniqueID@companya.example, or uniqueID.companya.example. In this scenario, Company A need only generate a single signing key and publish it under their top level domain (companya.example); the signing module would then tailor the i= value as needed at signing time. 7.2. Author's Organization - Differentiated Types of Mail A slight variation of the one signature case is where Company A signs all of its mail, but it wants to differentiate different categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing mail, billing or transactional mail, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, where each category is assigned a unique subdomain and unique signing keys. 7.3. Author Signature As discussed in Section 6.1, author signatures are a special case of signatures from an authors organization where at least one signature on the message has an i= value that matches the From: address of the message. Signers wishing to publish an ADSP record describing their signing practices will want to include an author signature on their outbound mail to avoid ADSP verification failures. For example, if the address in the RFC 5322 From is firstname.lastname@example.org, the d= value of the author signature would be company.example, and the i= value would be either company.example or email@example.com. 7.4. Author Domain Signing Practices To be added. 7.5. Delegated Signing An organization may choose to outsource certain key services to third party companies. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email. If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4 it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or they can delegate a subdomain (e.g. benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain. In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of e.g. d=benefits.companya.example. Note that the From: address is not constrained: it could either be affiliated with the benefits company (e.g. firstname.lastname@example.org, or email@example.com). Note that in both of the above scenarios, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios. 7.6. Independent Third Party Service Providers Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client Company A with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and may sign all outgoing mail from its clients with its own d= domain (e.g. d=espa.example). Should the ESP want to distinguish among its clients, it has two options: Share the d= domain and use the i= value to distinguish among the clients: e.g. a signature on behalf of client A would have d=espa.example and i=clienta.espa.example (or firstname.lastname@example.org) Extend the d= domain so there is a unique value (and subdomain) for each client: e.g. a signature on behalf of client A would have d=clienta.espa.example. Note that this scenario and the delegation scenario are not mutually exclusive: in some cases, it may be desirable to sign the same message with both the ESP and the ESP client identities. 7.7. Mail Streams Based on Behavioral Assessment An ISP (ISP A) might want to assign signatures to outbound mail from their users according to the users past sending behavior (reputation). Since the semantics of behavioral assessments arent allowed as i= values, ISP A (ispa.example) would have to configure subdomains corresponding the assessment categories (e.g. good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these domains as the d= value of the signature. The signing module can also optionally set the i= value to have a unique user id (distinct from the users email address local part), for example email@example.com. Using a userid that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases. Note that in this case the i= values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple i= values over the lifetime of their account). In this scenario, ISP A would have to generate as many keys as there are assessment subdomains (d= values), so that each assessment subdomain had its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired include the user id in the i= tag of the signature. 7.8. Agent or Mediator Signatures Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. 8. Usage Considerations 8.1. Non-standard Submission and Delivery Scenarios The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by travelling users, and other paths that could add or modify headers, or modify the message body. For example, assume Joe works for Company A and has an email address firstname.lastname@example.org. Joe also has a GMail account email@example.com, and he uses GMails multiple address feature to attach his work email firstname.lastname@example.org to his GMail account. When Joe sends email from his GMail account and uses email@example.com as his designated From: address, that email cannot have a signature with d=companya.example because the GMail servers have no access to Company A's private key. In GMail's case it will have a GMail signature, but for some other mail clients offering the same multiple address feature there may be no signature at all on the message. Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC 5322 From to their designated recipient. If Joe used either of his two addresses (firstname.lastname@example.org or email@example.com), the forwarder would be equally unable to sign with a corresponding domain . As in the mail client case, the forwarder may either sign as its own domain, or may put no signature on the message. A third example is the use of privately configured forwarding. Assume that Joe has another account at Yahoo, firstname.lastname@example.org, but he'd prefer to read his Yahoo mail from his GMail account. He sets up his Yahoo account to forward all incoming mail to email@example.com. Assume firstname.lastname@example.org sends email@example.com an email. Depending on how companyb.example configured its signature, and depending on whether or not Yahoo modifies messages that it forwards, it is possible that when Alice's message is received in Joe's gmail account the original signature fails verification. 8.2. 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 that does not contain a verifiable signature. Such mail can in most cases be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g. MTAs at hotels, hotspot networks used by travelling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices. 8.3. Signature Granularity Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer sub-domains or otherwise adjust signatures in a way that supports per-user identification. This user level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity, or by creating and signing with unique per-user keys. A subdomain or local part in the i= tag should be treated as an opaque identifier and thus need not correspond directly to a DNS sub domain or to a specific user address The primary way to sign with per-user keys require that each user have a distinct DNS (sub)domain, where each distinct d= value has a key published (it is possible, although not recommended, to publish the same key in more than one distinct domain). It is technically possible, to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not recommended and is unlikely to be treated uniquely by Identity Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identies. In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be likely to be ignored: In most cases today, if receivers are verifying DKIM signatures they are in general taking the simplest possible approach. In many cases maintaining reputation information at a per user granularity is not interesting to them, in large part because the per user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per user signatures, receivers are unlikely to retain anything more than the base domain reputation. difficult to manage: Any scheme that involves maintenance of a significant number of public keys may require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary managment complexity. It is also important to note that there is no way within the scope of the DKIM specification for a receiver to infer that a sender intends a per-user granularity. What may make sense, however, is to use the infrastructure that enables finer granularity in signatures to identify segments smaller than a domain but much larger than a per-user segmentation. For example, a university might want to segment student, staff, and faculty mail into three distinct streams with differing reputations. This can be done by creating seperate sub-domains for the desired segments, and either specifying the subdomains in the i= tag of the DKIM Signature or by adding subdomains to the d= tag and assigning and signing with different keys for each subdomain. For those who choose to represent user level granularity in signatures, the performance and management considerations above suggest that it would be more effective to do it by specifying a local part or subdomain extension in the i= tag rather than by extending the d= domain and publishing individual keys. 8.4. 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. What follows are some general recommendations for the Email Infrastructure. Outbound: An MSA or an Outbound MTA used for mail submission SHOULD ensure that the message sent is in compliance with the advertised email sending policy. It SHOULD also be able to generate an operator alert if it determines that the email messages do not comply with the published DKIM sending policy. An MSA SHOULD be aware that some MUAs may add their own signatures. If the MSA needs to perform operations on a message to make it comply with its email sending policy, if at all possible, it SHOULD do so in a way that would not break those signatures. [[anchor38: MSK: MUAs being able to sign is a security consideration; MUAs are more prone to vulnerabilities, so an MUA having direct access to signing keys is a security concern; general MUA vulnerability came up during the IETF Security Directorate review of draft-kucherawy-sender-auth-header]] Inbound: When an organization deploys DKIM, it needs to make sure that it email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification. An inbound MTA or an MDA may incorporate an indication of the verification results into the message, such as using an Authentication-Results header field. [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 field. [I-D.kucherawy-sender-auth-header] + Sign the modified message including the verification results (e.g., the Authentication-Results header field). 8.5. Mail User Agent 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, MUAs MAY also support DKIM signing and verifying directly. Outbound: 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 will be in addition to any signature added by the MSA. Some user software goes beyond simple user functionality and also perform MSA and MTA functions. When this is employed for sending directly to a receiving ADMD, the user software SHOULD be considered an outbound MTA. Inbound: An MUA MAY rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA MAY perform DKIM signature verification directly. A verifying MUA SHOULD allow for the case where mail has modified in the inbound MTA path; if a signature fails, the message SHOULD NOT be treated any different than if it did not have a signature. An MUA that looks for an Authentication-Results header field MUST be configurable to choose which Authentication-Results are considered trustable. 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 essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. The mere presence of a verified DKIM signature MUST NOT by itself be used by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified MAY be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators. It is common for components of an ADMD's email infrastructure to do violence to a message, such that a DKIM signature might be rendered 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. 9. Other Considerations 9.1. Security Considerations The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871]. 9.2. IANA Considerations This document has no considerations for IANA. 10. Acknowledgements TBD 11. Informative References [I-D.ietf-dkim-overview] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", draft-ietf-dkim-overview-10 (work in progress), July 2008. [I-D.ietf-dkim-ssp] Local-part, a., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", draft-ietf-dkim-ssp-09 (work in progress), February 2009. [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 Field for Indicating Message Authentication Status", draft-kucherawy-sender-auth-header-20 (work in progress), January 2009. [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. [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.M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Appendix A. Migrating from DomainKeys As with any migration, the steps required will be determined by who is doing the migration and their assessment of o the users of what they are generating, or o the providers of what they are consuming. A.1. Signers A signer that currently signs with DomainKeys (DK) will go through various stages as they migrate to using DKIM, not all of which are required for all signers. The real questions that a signer must ask are: 1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, 2. and how much does the signer care about those receivers? If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if there are no more "large players" looking only at the DK signatures, a signer may choose to stop signing with DK. 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. In particular, the same selectors and DNS Key Records may be used for both, after verifying that they are compatible as discussed below. Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue". One migration strategy is to: o ensure that the current selector DNS key record is compatible with both DK and DKIM o sign messages with both DK and DKIM signatures o when it's decided that DK signatures are no longer necessary, stop signing with DK Another migration strategy is to: o add a new selector DNS key record only for DKIM signatures o sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record) o when it's decided that DK signatures are no longer necessary, stop signing with DK o eventually remove the old DK selector DNS record A combined migration strategy is to: o ensure that the current selector DNS key record is compatible with both DK and DKIM o start signing messages with both DK and DKIM signatures o add a new selector DNS key record for DKIM signatures o switch the DKIM signatures to use the new selector o when it's decided that DK signatures are no longer necessary, stop signing with DK o eventually remove the old DK selector DNS record Another migration strategy is to: o add a new selector DNS key record for DKIM signatures o do a flash cut and replace the DK signatures with DKIM signatures o eventually remove the old DK selector DNS record Another migration strategy is to: o ensure that the current selector DNS key record is compatible with both DK and DKIM o do a flash cut and replace the DK signatures with DKIM signatures Note that when you have separate key records for DK and DKIM, you can use the same public key for both. A.1.1. DNS Selector Key Records The first step in some of the above scenarios is ensuring that the selector DNS key records are compatible for both DK and DKIM. The format of the DNS key record was intentionally meant to be backwardly compatible between the two systems, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK must ignore. However, there is one critical difference between DK and DKIM DNS key records: the definitions of the g fields: g= granularity of the key In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and "g=*;" mean to allow any sending address. If your DK DNS key record has an empty g= field in it ("g=;"), your best course of action is to modify the record to remove the empty field. In that way, the DK semantics will remain the same, and the DKIM semantics will match. If your DNS key record does not have an empty g= field in it ("g=;"), it's probable that the record can be left alone. But your best course of action would still be to make sure it has a v= field. When the decision is made to stop supporting DomainKeys and to only support DKIM, you MUST verify that the "g" field is compatible with DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED that if you want to use an empty g= field in your DKIM selector, you also include the v= field. A.1.2. Removing DomainKeys Signatures The principal use of DomainKeys is at Boundary MTAs. Because no operational transition is ever instantaneous, it is advisable to continue performing DomainKeys signing until it is determined that DomainKeys receive-side support is no longer used, or is sufficiently reduced. That is, a signer SHOULD add a DKIM signature to a message that also has a DomainKeys signature and keep it there until you decide it can go away. The signer may do its transitions in a straightforward manner, or more gradually. Note that because digital signatures are not free, there is a cost to performing both signing algorithms, so you don't want to be signing with both algorithms for too long a period. The tricky part is deciding when DK signatures are no longer necessary. The real questions are: how many DomainKeys verifiers are there that do *not* also do DKIM verification, which ones of them do you care about, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it may choose to verify both signatures, or just one or the other. Many DNS services offer tracking statistics so you can find out how often a DNS record has been accessed. By using separate DNS selector key records for your signatures, you can chart the usage of your records over time, and watch the trends. An additional distinguishing factor to track would take into account the verifiers that verify both the DK and DKIM signatures, and discount those from your counts of DK selector usage. When the number for DK selector access reaches a low-enough level, that's the time to consider stopping your DK signing. Note, this level of rigor is not required. It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above. A.2. Verifiers As a verifier, you are faced with several issues: A.2.1. Do you verify DK signatures? At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it may take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures. A.2.2. Do you verify both DK and DKIM signatures within a single message? For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures may verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails. A.2.3. DNS Selector Key Records The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK must ignore. However, there is one key difference between DK and DKIM DNS key records: the definitions of the g fields: g= granularity of the key In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. v= version of the selector It is recommended that a DKIM selector have v=DKIM1; at its beginning, but it is not required. If a DKIM verifier finds a selector record that has an empty g= field ("g=;") and it does not have a v= field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was 1. from a DK signer that transitioned to supporting DKIM but forgot to remove the g= field (so that it could be used by both DK and DKIM verifiers), or 2. from a DKIM signer that truly meant to use the empty g= field but forgot to put in the v= field. It is RECOMMENDED that you treat such records using the first interpretation, and treat such records as if the signer did not have a g= field in the record. Appendix B. General Coding Criteria for Cryptographic Applications NOTE: This section could possibly be changed into a reference to something else, such as another rfc. 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. 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. Authors' Addresses Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA Email: firstname.lastname@example.org Ellen Siegel Constant Contact, Inc. 1601 Trapelo Rd, Ste 329 Waltham, MA 02451 USA Email: email@example.com Phillip Hallam-Baker VeriSign Inc. Email: firstname.lastname@example.org Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA Email: email@example.com Ellen Siegel Constant Contact, Inc. 1601 Trapelo Rd, Ste 329 Waltham, MA 02451 USA Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 email@example.com.