idnits 2.17.1 draft-ietf-dkim-deployment-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC4871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 277: '...s to a responsible identity. DKIM MAY...' RFC 2119 keyword, line 279: '...ide DKIM verifier MUST communicate the...' RFC 2119 keyword, line 281: '... module and MAY communicate the U...' RFC 2119 keyword, line 291: '...ide DKIM verifier MUST communicate the...' RFC 2119 keyword, line 293: '... module and MAY communicate the U...' (58 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If key management hardware support is available, it SHOULD be used. If keys are stored in software, appropriate 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 be accessible through any form of network including private local area networks. Auditing software SHOULD be used periodically to verify that the permissions on the private key files remain secure. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In the most restrictive case a domain holder maintains full control over the creation of key records and employs appropriate key record restrictions to enforce restrictions on the messages for which the third party signer is able to sign. If such restrictions are impractical, the domain holder SHOULD delegate a DNS subzone for publishing key records to the third party signer. The domain holder SHOULD not allow a third party signer unrestricted access to its DNS service for the purpose of publishing key records. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2009) is 5440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-openpgp-rfc2440bis' is defined on line 1854, but no explicit reference was found in the text == Unused Reference: 'RFC0989' is defined on line 1859, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: 'RFC1848' is defined on line 1866, but no explicit reference was found in the text == Unused Reference: 'RFC1991' is defined on line 1869, but no explicit reference was found in the text == Unused Reference: 'RFC2440' is defined on line 1872, but no explicit reference was found in the text == Unused Reference: 'RFC3156' is defined on line 1875, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 1881, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 1889, but no explicit reference was found in the text == Unused Reference: 'RFC4870' is defined on line 1892, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 1904, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-dkim-overview-10 -- Obsolete informational reference (is this intentional?): RFC 989 (Obsoleted by RFC 1040, RFC 1113) -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DomainKeys Identified Mail T. Hansen 3 Internet-Draft AT&T Laboratories 4 Intended status: Informational E. Siegel 5 Expires: December 5, 2009 Constant Contact, Inc. 6 P. Hallam-Baker 7 VeriSign Inc. 8 D. Crocker 9 Brandenburg InternetWorking 10 June 3, 2009 12 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations 13 draft-ietf-dkim-deployment-05 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 5, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 DomainKeys Identified Mail (DKIM) allows an organization to claim 52 responsibility for transmitting a message, in a way that can be 53 validated by a recipient. The organization can be the author's, the 54 originating sending site, an intermediary, or one of their agents. A 55 message can contain multiple signatures, from the same or different 56 organizations involved with the message. DKIM defines a domain-level 57 digital signature authentication framework for email, using public 58 key cryptography, using the domain name service as its key server 59 technology [RFC4871]. This permits verification of a responsible 60 organization, as well as the integrity of the message contents. DKIM 61 will also provide a mechanism that permits potential email signers to 62 publish information about their email signing practices; this will 63 permit email receivers to make additional assessments about messages. 64 DKIM's authentication of email identity can assist in the global 65 control of "spam" and "phishing". This document provides 66 implementation, deployment, operational and migration considerations 67 for DKIM. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5 73 2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5 74 2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7 75 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9 76 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11 77 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14 79 3.1. Private Key Management: Deployment and Ongoing 80 Operations . . . . . . . . . . . . . . . . . . . . . . . . 15 81 3.2. Storing Public Keys: DNS Server Software Considerations . 16 82 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 83 3.4. Third Party Signer Key Management and Selector 84 Administration . . . . . . . . . . . . . . . . . . . . . . 17 85 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18 86 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 20 88 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20 89 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 21 90 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 21 92 5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 22 93 5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 22 94 5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 23 95 5.5. Messages sent through Mailing Lists and other 96 Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23 97 5.6. Generation, Transmission and Use of Results Headers . . . 24 98 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 24 99 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 25 100 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 25 101 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 26 102 6.4. Using Trusted Third Party Senders . . . . . . . . . . . . 27 103 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 28 104 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 30 105 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 30 106 7.2. Author's Organization - Differentiated Types of Mail . . . 31 107 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 31 108 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 31 109 7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 33 110 7.6. Independent Third Party Service Providers . . . . . . . . 34 111 7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 34 112 7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 35 113 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 35 114 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35 115 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36 116 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 37 117 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 38 118 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39 119 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40 120 9.1. Security Considerations . . . . . . . . . . . . . . . . . 40 121 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 41 122 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 123 11. Informative References . . . . . . . . . . . . . . . . . . . . 41 124 Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 42 125 A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 43 126 A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 46 127 Appendix B. General Coding Criteria for Cryptographic 128 Applications . . . . . . . . . . . . . . . . . . . . 47 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 131 1. Introduction 133 DomainKeys Identified Mail (DKIM) allows an organization to claim 134 responsibility for transmitting a message, in a way that can be 135 validated by a recipient. This document provides practical tips for: 136 those who are developing DKIM software, mailing list managers, 137 filtering strategies based on the output from DKIM verification, and 138 DNS servers; those who are deploying DKIM software, keys, mailing 139 list software, and migrating from DomainKeys; and those who are 140 responsible for the on-going operations of an email infrastructure 141 that has deployed DKIM. 143 The document is organized around the key concepts related to DKIM. 144 Within each section, additional considerations specific to 145 development, deployment, or ongoing operations are highlighted where 146 appropriate. The possibility of use of DKIM results as input to a 147 local reputation database is also discussed. 149 2. Using DKIM as Part of Trust Assessment 151 2.1. A Systems View of Email Trust Assessment 153 DKIM participates in a trust-oriented enhancement to the Internet's 154 email service, to facilitate message handling decisions, such as for 155 delivery and for content display. Trust-oriented message handling 156 has substantial differences from approaches that consider messages in 157 terms of risk and abuse. With trust, there is a collaborative 158 exchange between a willing participant along the sending path and a 159 willing participant at the recipient site. In contrast, the risk 160 model entails independent action by the recipient site, in the face 161 of a potentially unknown, hostile and deceptive sender. This 162 translates into a very basic technical difference: In the face of 163 unilateral action by the recipient and even antagonistic efforts by 164 the sender, risk-oriented mechanisms will be based on heuristics, 165 that is, on guessing. Guessing produces statistical results with 166 some false negatives and some false positives. For trust-based 167 exchanges, the goal is the deterministic exchange of information. 168 For DKIM, that information is the one identifier that represents a 169 stream of mail for which an independent assessment is sought (by the 170 signer.) 172 A trust-based service is built upon a validated Responsible 173 Identifier that labels a stream of mail and is controlled by an 174 identity (role, person or organization). The identity is 175 acknowledging some degree of responsibility for the message stream. 176 Given a basis for believing that an identifier is being used in an 177 authorized manner, the recipient site can make and use an assessment 178 of the associated identity. An identity can use different 179 identifiers, on the assumption that the different streams might 180 produce different assessments. For example, even the best-run 181 marketing campaigns will tend to produce some complaints that can 182 affect the reputation of the associated identifier, whereas a stream 183 of transactional messages is likely to have a more pristine 184 reputation. 186 Determining that the identifier's use is valid is quite different 187 from determining that the content of a message is valid. The former 188 means only that the identifier for the responsible role, person or 189 organization has been legitimately associated with a message. The 190 latter means that the content of the message can be believed and, 191 typically, that the claimed author of the content is correct. DKIM 192 validates only the presence of the identifier used to sign the 193 message. Even when this identifier is validated, DKIM carries no 194 implication that any of the message content, including the 195 RFC5322.From field, is valid. Surprisingly, this limit to the 196 semantics of a DKIM signature applies even when the validated signing 197 identifier is the same domain name as is used in the From: field! 198 DKIM's only claim about message content is that the content cited in 199 the DKIM-Signature: field's h= tag has been delivered without 200 modification. That is, it asserts message content integrity, not 201 message content validity. 203 As shown in Figure 1, this enhancement is a communication between a 204 responsible role, person or organization that signs the message and a 205 recipient organization that assesses its trust in the signer and then 206 makes handling decisions based on a collection of assessments, of 207 which the DKIM mechanism is only a part. In this model, validation 208 is an intermediary step, having the sole task of passing a validated 209 Responsible Identifier to the Identity Assessor. The communication 210 is of a single Responsible Identifier that the Responsible Identity 211 wishes to have used by the Identity Assessor. The Identifier is the 212 sole, formal input and output value of DKIM signing. The Identity 213 Assessor uses this single, provided Identifier for consulting 214 whatever assessment data bases are deemed appropriate by the 215 assessing entity. In turn, output from the Identity Assessor is fed 216 into a Handling Filter engine that considers a range of factors, 217 along with this single output value; the range of factors can include 218 ancillary information from the DKIM validation. 220 Identity Assessment covers a range of possible functions. It can be 221 as simple as determining whether the identifier is a member of some 222 list, such as authorized operators or participants in a group that 223 might be of interest for recipient assessment. Equally, it can 224 indicate a degree of trust (reputation) that is to be afforded the 225 actor using that identifier. The extent to which the assessment 226 affects handling of the message is, of course, determined later, by 227 the Handling Filter. 229 +------+------+ +------+------+ 230 | Author | | Recipient | 231 +------+------+ +------+------+ 232 | ^ 233 | | 234 | +------+------+ 235 | -->| Handling |<-- 236 | -->| Filter |<-- 237 | +-------------+ 238 | ^ 239 V Responsible | 240 +-------------+ Identifier +------+------+ 241 | Responsible |. . . . . . . . . . .>| Identity | 242 | Identity | . . | Assessor | 243 +------+------+ . . +-------------+ 244 | . . ^ ^ 245 V . . | | 246 +------------------.-------.--------------------+ | | 247 | +------+------+ . . . . . +-------------+ | | | +-------------+ 248 | | Identifier | | Identifier +--|--+ +--+ Assessment | 249 | | Signer +------------->| Validator | | | Databases | 250 | +-------------+ +-------------+ | +-------------+ 251 | DKIM Service | 252 +-----------------------------------------------+ 254 Figure 1: Actors in a Trust Sequence using DKIM 256 2.2. Choosing a DKIM Tag for the Assessment Identifier 258 The signer of a message needs to be able to provide precise data and 259 know what that data will mean upon delivery to the Assessor. If 260 there is ambiguity in the choice that will be made on the receive 261 side, then the sender cannot know what basis for assessment will be 262 used. DKIM has three values that specify identification information 263 and it is easy to confuse their use, although only one defines the 264 formal input and output of DKIM, with the other two being used for 265 internal protocol functioning and adjunct purposes, such as auditing 266 and debugging. 268 The salient values include the s=, d= and i= parameters in the DKIM- 269 Signature: header field. In order to achieve the end-to-end 270 determinism needed for this collaborative exchange from the signer to 271 the assessor, the core model needs to specify what the signer is 272 required to provide to the assessor. The Update to RFC4871 273 [rfc4871-update]now specifies: 275 DKIM's primary task is to communicate from the Signer to a 276 recipient-side Identity Assessor a single Signing Domain 277 Identifier (SDID) that refers to a responsible identity. DKIM MAY 278 optionally provide a single responsible Agent or User Identifier 279 (AUID)... A receive-side DKIM verifier MUST communicate the 280 Signing Domain Identifier (d=) to a consuming Identity Assessor 281 module and MAY communicate the User Agent Identifier (i=) if 282 present.... To the extent that a receiver attempts to intuit any 283 structured semantics for either of the identifiers, this is a 284 heuristic function that is outside the scope of DKIM's 285 specification and semantics. 287 The single, mandatory value that DKIM supplies as its output is: 289 d= This specifies the "domain of the signing entity." It is a 290 domain name and is combined with the Selector to form a DNS 291 query... A receive-side DKIM verifier MUST communicate the 292 Signing Domain Identifier (d=) to a consuming Identity Assessor 293 module and MAY communicate the User Agent Identifier (i=) if 294 present. 296 The adjunct values are: 298 s= This tag specifies the Selector. It is used to discriminate 299 among different keys that can be used for the same d= domain 300 name. As discussed in Section 4.3 of [I-D.ietf-dkim-overview]: 301 "If verifiers were to employ the selector as part of a name 302 assessment mechanism, then there would be no remaining 303 mechanism for making a transition from an old, or compromised, 304 key to a new one." Consequently, the Selector is not 305 appropriate for use as part or all of the identifier used to 306 make assessments. 308 i= This tag is optional and provides the "[i]dentity of the 309 user or agent (e.g., a mailing list manager) on behalf of which 310 this message is signed." The identity can be in the syntax of 311 an entire email address or only a domain name. The domain name 312 can be the same as for d= or it can be a sub-name of the d= 313 name. 315 NOTE: Although the i= identity has the syntax of an email 316 address, it is not required to have that semantics. That is, 317 "the identity of the user" need not be the same as the user's 318 mailbox. For example the signer might wish to use i= to encode 319 user-related audit information, such as how they were accessing 320 the service at the time of message posting. Therefore it is 321 not possible to conclude anything from the i= string's 322 (dis)similarity to email addresses elsewhere in the header 324 So, i= can have any of these properties: 326 * Be a valid domain when it is the same as d= 328 * Appear to be a sub-domain of d= but might not even exist 330 * Look like a mailbox address but might have different semantics 331 and therefore not function as a valid email address 333 * Be unique for each message, such as indicating access details 334 of the user for the specific posting 336 This underscores why the tag needs to be treated as being opaque, 337 since it can represent any semantics, known only to the signer. 339 Hence, i= serves well as a token that is usable like a Web cookie, 340 for return to the signing ADMD -- such as for auditing and debugging. 341 Of course in some scenarios the i= string might provide a useful 342 adjunct value for additional (heuristic) processing by the Handling 343 Filter. 345 2.3. Choosing the Signing Domain Name 347 A DKIM signing entity can serve different roles, such as author of 348 content, versus operator of the mail service, versus operator of a 349 reputation service. In these different roles, the basis for 350 distinguishing among portions of email traffic can vary. For an 351 entity creating DKIM signatures it is likely that different portions 352 of its mail will warrant different levels of trust. For example: 354 * Mail is sent for different purposes, such as marketing vs. 355 transactional, and recipients demonstrate different patterns of 356 acceptance between these. 358 * For an operator of an email service, there often are distinct 359 sub-populations of users warranting different levels of trust 360 or privilege, such as paid vs. free users, or users engaged in 361 direct correspondence vs. users sending bulk mail. 363 * Mail originating outside an operator's system, such as when it 364 is redistributed by a mailing list service run by the operator, 365 will warrant a different reputation from mail submitted by 366 users authenticated with the operator. 368 It is therefore likely to be useful for a signer to use different d= 369 sub-domain names, for different message traffic streams, so that 370 receivers can make differential assessments. However, too much 371 differentiation -- that is, too fine a granularity of signing domains 372 -- makes it difficult for the receiver to discern a sufficiently 373 stable pattern of traffic for developing an accurate and reliable 374 assessment. So the differentiation needs to achieve a balance. 375 Generally in a trust system, legitimate signers have an incentive to 376 pick a small stable set of identities, so that recipients and others 377 can attribute reputations to them. The set of these identities a 378 receiver trusts is likely to be quite a bit smaller than the set it 379 views as risky. 381 The challenge in using additional layers of sub-domains is whether 382 the extra granularity will be useful for the assessor. In fact, 383 potentially excessive levels invites ambiguity: if the assessor does 384 not take advantage of the added granularity, then what granularity 385 will it use? That ambiguity would move the use of DKIM back to the 386 realm of heuristics, rather than the deterministic processing that is 387 its goal. 389 Hence the challenge is to determine a useful scheme for labeling 390 different traffic streams. The most obvious choices are among 391 different types of content and/or different types of authors. 392 Although stability is essential, it is likely that the choices will 393 change, over time, so the scheme needs to be flexible. 395 For those originating message content, the most likely choice of sub- 396 domain naming scheme will by based upon type of content, which can 397 use content-oriented labels or service-oriented labels. For example: 399 transaction.example.com 400 newsletter.example.com 401 bugreport.example.com 402 support.example.com 403 sales.example.com 404 marketing.example.com 406 where the choices are best dictated by whether they provide the 407 Identity Assessor with the ability to discriminate usefully among 408 streams of mail that demonstrate significantly different degrees of 409 recipient acceptance or safety. Again, the danger in providing too 410 fine a granularity is that related message streams that are labeled 411 separately will not benefit from an aggregate reputation. 413 For those operating messaging services on behalf of a variety of 414 customers, an obvious scheme to use has a different sub-domain label 415 for each customer. For example: 417 widgetco.example.net 418 moviestudio.example.net 419 bigbank.example.net 421 However it can also be appropriate to label by the class of service 422 or class of customer, such as: 424 premier.example.net 425 free.example.net 426 certified.example.net 428 Prior to using domain names for distinguishing among sources of data, 429 IP Addresses have been the basis for distinction. Service operators 430 typically have done this by dedicating specific outbound IP Addresses 431 to specific mail streams -- typically to specific customers. For 432 example, a university might want to distinguish mail from the 433 Administration, versus mail from the student dorms. In order to make 434 adoption of a DKIM-based service easier, it can be reasonable to 435 translate the same partitioning of traffic, using domain names in 436 place of the different IP Addresses. 438 2.4. Recipient-based Assessments 440 DKIM gives the recipient site's Identity Assessor a verifiable 441 identifier to use for analysis. Although the mechanism does not make 442 claims that the signer is a Good Actor or a Bad Actor, it does make 443 it possible to know that use of the identifier is valid. This is in 444 marked contrast with schemes that do not have authentication. 445 Without verification, it is not possible to know whether the 446 identifier -- whether taken from the RFC5322.From field, 447 RFC5321.MailFrom command, or the like -- is being used by an 448 authorized agent. DKIM solves this problem. Hence with DKIM, the 449 Assessor can know that two messages with the same DKIM d= identifier 450 are, in fact, signed by the same person or organization. This 451 permits a far more stable and accurate assessment of mail traffic 452 using that identifier. 454 DKIM is distinctive, in that it provides an identifier which is not 455 necessarily related to any other identifier in the message. Hence, 456 the signer might be the author's ADMD, one of the operators along the 457 transit path, or a reputation service being used by one of those 458 handling services. In fact, a message can have multiple signatures, 459 possibly by any number of these actors. 461 As discussed above, the choice of identifiers needs to be based on 462 differences that the signer thinks will be useful for the recipient 463 Assessor. Over time, industry practices establish norms for these 464 choices. 466 Absent such norms, it is best for signers to distinguish among 467 streams that have significant differences, while consuming the 468 smallest number of identifiers possible. This will limit the 469 burden on recipient Assessors. 471 A common view about a DKIM signature is that it carries a degree of 472 assurance about some or all of the message contents, and in 473 particular that the RFC5322.From field is likely to be valid. In 474 fact, DKIM makes assurances only about the integrity of the data and 475 not about its validity. Still, presumptions of From: field validity 476 remain a concern. Hence a signer using a domain name that is 477 unrelated to the domain name in the From: field can reasonably expect 478 that the disparity will warrant some curiosity, at least until 479 signing by independent operators has produced some established 480 practice among recipient Assessors. 482 With the identifier(s) supplied by DKIM, the Assessor can consult an 483 independent assessment service about the entity associated with the 484 identifier(s). Another possibility is that the Assessor can develop 485 its own reputation rating for the identifier(s). That is, over time, 486 the Assessor can observe the stream of messages associated with the 487 identifier(s) developing a reaction to associated content. For 488 example, if there is a high percentage of user complaints regarding 489 signed mail with a "d=" value of "widgetco.example.net", the Assessor 490 might include that fact in the vector of data it provides to the 491 Handling Filter. This is also discussed briefly in Section 5.4. 493 2.5. Filtering 495 After assessing the signer of a message, each receiving site creates 496 and tunes its own Handling Filter according to criteria specific for 497 that site. Still, there are commonalities across sites, and this 498 section offers a discussion, rather than a specification, of some 499 types of input to that process and how they can be used. 501 The discussion focuses on variations in Organizational Trust versus 502 Message Risk, that is, the degree of positive assessment of a DKIM- 503 signing organization, and the potential danger present in the message 504 stream signed by that organization. While it might seem that higher 505 trust automatically means lower risk, the experience with real-world 506 operations provides examples of every combination of the two factors, 507 as shown in Table 1. Only three levels of granularity are listed, in 508 order to keep discussion manageable. This also ensures extensive 509 flexibility for each site's detailed choices. 511 +---+---------------------+--------------------+--------------------+ 512 | | Low | Medium | High | 513 | | | | | 514 | | | | | 515 | | | | | 516 | | | | | 517 | O | | | | 518 | R | | | | 519 | G | | | | 520 | | | | | 521 | T | | | | 522 | R | | | | 523 | U | | | | 524 | S | | | | 525 | T | | | | 526 | | | | | 527 | M | | | | 528 +---+---------------------+--------------------+--------------------+ 529 | * | Unknown org, | Registered org, | Good Org, | 530 | L | Few msgs: | New Identifier: | Good msgs: | 531 | o | _Mild filtering_ | _Medium filtering_ | _Avoid FP(!)_ | 532 | w | | | | 533 | * | Unknown org, | Registered org, | Good org, Bad msg | 534 | M | New Identifier: | Mixed msgs: | burst: | 535 | e | _Default filtering_ | _Medium filtering_ | _Accept & Contact_ | 536 | d | | | | 537 | i | | | | 538 | u | | | | 539 | * | Black-Listed org, | Registered org, | Good org, | 540 | H | Bad msgs: | Bad msgs: | Compromised: | 541 | i | _Avoid FN(!)_ | _Strong filtering_ | _Fully blocked_ | 542 | g | | | | 543 | h | | | | 544 +---+---------------------+--------------------+--------------------+ 546 Table 1: Organizational Trust vs. Message Risk 548 The table indicates preferences for different handling of different 549 combinations, such as tuning filtering to avoid False Positives (FP) 550 or avoiding False Negatives (FN). Perhaps unexpectedly, it also 551 lists a case in which the receiving site might wish to deliver 552 problematic mail, rather than redirecting it, but also of course 553 contacting the signing organization, seeking resolution of the 554 problem. 556 3. DKIM Key Generation, Storage, and Management 558 By itself, verification of a digital signature only allows the 559 verifier to conclude with a very high degree of certainty that the 560 signature was created by a party with access to the corresponding 561 private signing key. It follows that a verifier requires means to 562 (1) obtain the public key for the purpose of verification and (2) 563 infer useful attributes of the key holder. 565 In a traditional Public Key Infrastructure (PKI), the functions of 566 key distribution and key accreditation are separated. In DKIM 567 [RFC4871], these functions are both performed through the DNS. 569 In either case, the ability to infer semantics from a digital 570 signature depends on the assumption that the corresponding private 571 key is only accessible to a party with a particular set of 572 attributes. In traditional PKI, a Trusted Third Party (TTP) vouches 573 that the key holder has been validated with respect to a specified 574 set of attributes. The range of attributes that may be attested in 575 such a scheme is thus limited only to the type of attributes that a 576 TTP can establish effective processes for validating. In DKIM, 577 Trusted Third parties are not employed and the functions of key 578 distribution and accreditation are combined. 580 Consequently there are only two types of inference that a signer may 581 make from a key published in a DKIM Key Record: 583 1. That a party with the ability to control DNS records within a DNS 584 zone intends to claim responsibility for messages signed using 585 the corresponding private signature key. 587 2. That use of a specific key is restricted to the particular subset 588 of messages identified by the selector. 590 The ability to draw any useful conclusion from verification of a 591 digital signature relies on the assumption that the corresponding 592 private key is only accessible to a party with a particular set of 593 attributes. In the case of DKIM, this means that the party that 594 created the corresponding DKIM key record in the specific zone 595 intended to claim responsibility for the signed message. 597 Ideally we would like to draw a stronger conclusion, that if we 598 obtain a DKIM key record from the DNS zone example.com, that the 599 legitimate holder of the DNS zone example.com claims responsibility 600 for the signed message. In order for this conclusion to be drawn it 601 is necessary for the verifier to assume that the operational security 602 of the DNS zone and corresponding private key are adequate. 604 3.1. Private Key Management: Deployment and Ongoing Operations 606 Access to signing keys MUST be carefully managed to prevent use by 607 unauthorized parties and to minimize the consequences if a compromise 608 were to occur. 610 While a DKIM signing key is used to sign messages on behalf of many 611 mail users, the signing key itself SHOULD be under direct control of 612 as few key holders as possible. If a key holder were to leave the 613 organization, all signing keys held by that key holder SHOULD be 614 withdrawn from service and if appropriate, replaced. 616 If key management hardware support is available, it SHOULD be used. 617 If keys are stored in software, appropriate file control protections 618 MUST be employed, and any location in which the private key is stored 619 in plaintext form SHOULD be excluded from regular backup processes 620 and SHOULD not be accessible through any form of network including 621 private local area networks. Auditing software SHOULD be used 622 periodically to verify that the permissions on the private key files 623 remain secure. 625 Wherever possible a signature key SHOULD exist in exactly one 626 location and be erased when no longer used. Ideally a signature key 627 pair SHOULD be generated as close to the signing point as possible 628 and only the public key component transferred to another party. If 629 this is not possible, the private key MUST be transported in an 630 encrypted format that protects the confidentiality of the signing 631 key. A shared directory on a local file system does not provide 632 adequate security for distribution of signing keys in plaintext form. 634 Key escrow schemes are not necessary and SHOULD NOT be used. In the 635 unlikely event of a signing key becomming lost, a new signature key 636 pair may be generated as easily as recovery from a key escrow scheme. 638 To enable accountability and auditing: 640 o Responsibility for the security of a signing key SHOULD ultimately 641 vest in a single named individual. 643 o Where multiple parties are authorized to sign messages, each 644 signer SHOULD use a different key to enable accountability and 645 auditing. 647 Best practices for management of cryptographic keying material 648 require keying material to be refreshed at regular intervals, 649 particularly where key management is achieved through software. 650 While this practice is highly desirable it is of considerably less 651 importance than the requirement to maintain the secrecy of the 652 corresponding private key. An operational practice in which the 653 private key is stored in tamper proof hardware and changed once a 654 year is considerably more desirable than one in which the signature 655 key is changed on an hourly basis but maintained in software. 657 3.2. Storing Public Keys: DNS Server Software Considerations 659 In order to use DKIM a DNS domain holder requires (1) the ability to 660 create the necessary DKIM DNS records and (2) sufficient operational 661 security controls to prevent insertion of spurious DNS records by an 662 attacker. 664 DNS record management is often operated by an administrative staff 665 that is different from those who operate an organization's email 666 service. In order to ensure that DKIM DNS records are accurate, this 667 imposes a requirement for careful coordination between the two 668 operations groups. If the best practices for private key management 669 described above are observed, such deployment is not a one time 670 event; DNS DKIM selectors will be changed over time signing keys are 671 terminated and replaced. 673 At a minimum, a DNS server that handles queries for DKIM key records 674 MUST allow the server administrators to add free-form TXT records. 675 It would be better if the the DKIM records could be entered using a 676 structured form, supporting the DKIM-specific fields. 678 Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that 679 provides protection against record insertion attacks and zone 680 enumeration. In the case that NSEC3 [RFC5155] records are employed 681 to prevent insertion attack, the OPT-OUT flag MUST be set clear. 683 3.2.1. Assignment of Selectors 685 Selectors are assigned according to the administrative needs of the 686 signing domain, such as for rolling over to a new key or for 687 delegating of the right to authenticate a portion of the namespace to 688 a trusted third party. Examples include: 690 jun2005.eng._domainkey.example.com 692 widget.promotion._domainkey.example.com 694 It is intended that assessments of DKIM identities be based on the 695 domain name, and not include the selector. While past practice of a 696 signer may permit a verifier to infer additional properties of 697 particular messages from the structure DKIM key selector, unannounced 698 administrative changes such as a change of signing softeware may 699 cause such heuristics to fail at any time. 701 3.3. Per User Signing Key Management Issues 703 While a signer may establish business rules, such as issue of 704 individual signature keys for each end-user, DKIM makes no provision 705 for communicating these to other parties. Out of band distribution 706 of such business rules is outside the scope of DKIM. Consequently 707 there is no means by which external parties may make use of such keys 708 to attribute messages with any greater granularity than a DNS domain. 710 If per-user signing keys are assigned for internal purposes (e.g. 711 authenticating messages sent to an MTA for distribution), the 712 following issues need to be considered before using such signatures 713 as an alternative to traditional edge signing at the outbound MTA: 715 External verifiers will be unable to make use of the additional 716 signature granularity without access to additional information 717 passed out of band with respect to [RFC4871]. 719 If the number of user keys is large, the efficiency of local 720 caching of key records by verifiers will be lower. 722 A large number of end users may be less likely to be able to 723 manage private key data securely on their personal computer than 724 an administrator running an edge MTA. 726 3.4. Third Party Signer Key Management and Selector Administration 728 A DKIM key record only asserts that the holder of the corresponding 729 domain name makes a claim of responsibility for messages signed under 730 the corresponding key. In some applications, such as bulk mail 731 delivery, it is desirable to delegate the ability to make a claim of 732 responsibility to another party. In this case the trust relationship 733 is established between the domain holder and the verifier but the 734 private signature key is held by a third party. 736 Signature keys used by a third party signer SHOULD be kept entirely 737 separate from those used by the domain holder and other third party 738 signers. To limit potential exposure of the private key, the 739 signature key pair SHOULD be generated by the third party signer and 740 the public component of the key transmitted to the domain holder, 741 rather than have the domain holder generate the key pair and transmit 742 the private component to the third party signer. 744 Domain holders SHOULD adopt a least privilege approach and grant 745 third party signers the minimum access necessary to perform the 746 desired function. Limiting the access granted to Third Party Signers 747 serves to protect the interests of both parties. The domain holder 748 minimizes its security risk and the Trusted Third Party Signer avoids 749 unnecessary liability. 751 In the most restrictive case a domain holder maintains full control 752 over the creation of key records and employs appropriate key record 753 restrictions to enforce restrictions on the messages for which the 754 third party signer is able to sign. If such restrictions are 755 impractical, the domain holder SHOULD delegate a DNS subzone for 756 publishing key records to the third party signer. The domain holder 757 SHOULD not allow a third party signer unrestricted access to its DNS 758 service for the purpose of publishing key records. 760 3.5. Key Pair / Selector Lifecycle Management 762 Deployments SHOULD establish, document and observe processes for 763 managing the entire lifecycle of a public key pair. 765 3.5.1. Example Key Deployment Process 767 When it is determined that a new key pair is required: 769 1. A Key Pair is generated by the signing device. 771 2. A proposed key selector record is generated and transmitted to 772 the DNS administration infrasrtructure. 774 3. The DNS administration infrastructure verifies the authenticity 775 of the key selector registration request. If accepted 777 1. A key selector is assigned. 779 2. The corresponding key record published in the DNS. 781 3. Wait for DNS updates to propagate (if necessary). 783 4. Report assigned key selector to signing device. 785 4. Signer verifies correct registration of the key record. 787 5. Signer begins generating signatures using the new key pair. 789 6. Signer terminates any private keys that are no longer required 790 due to issue of replacement. 792 3.5.2. Example Key Termination Process 794 When it is determined that a private signature key is no longer 795 required: 797 1. Signer stops using the private key for signature operations. 799 2. Signer deletes all records of the private key, including in- 800 memory copies at the signing device. 802 3. Signer notifies the DNS administration infrasrtructure that the 803 signing key is withdrawn from service and that the corresponding 804 key records may be withdrawn from service at a specified future 805 date. 807 4. The DNS administration infrastructure verifies the authenticity 808 of the key selector termination request. If accepted, 810 1. The key selector is scheduled for deletion at a future time 811 determined by site policy. 813 2. Wait for deletion time to arrive. 815 3. The signer either publishes a revocation key selector with an 816 empty "p=" field, or deletes the key selector record 817 entirely. 819 5. As far as the verifier is concerned, there is no functional 820 difference between verifying against a key selector with an empty 821 "p=" field, and verifying against a missing key selector: both 822 result in a failed signature and the signature should be treated 823 as if it had not been there. However, there is a minor semantic 824 difference: with the empty "p=" field, the signer is explicitly 825 stating that the key has been revoked. The empty "p=" record 826 provides a gravestone for an old selector, making it less likely 827 that the selector might be accidently reused with a different 828 public key. 830 4. Signing 832 Creating messages that have one or more DKIM signatures, requires 833 support in only two outbound email service components: 835 o A DNS Administrative interface that can create and maintain the 836 relevant DNS names -- including names with underscores -- and 837 resource records (RR). 839 o A trusted module, called the Signing Module, which is within the 840 organization's outbound email handling service and which creates 841 and adds the DKIM-Signature: header field(s) to the message. 843 If the module creates more than one signature, there needs to be the 844 appropriate means of telling it which one(s) to use. If a large 845 number of names is used for signing, it will help to have the 846 administrative tool support a batch processing mode. 848 4.1. DNS Records 850 A receiver attempting to verify a DKIM signature obtains the public 851 key that is associated with the signature for that message. The 852 DKIM-Signature: header in the message contains the d= tag with the 853 basic domain name doing the signing and serving as output to the 854 Identity Assessor, and the s= tag with the selector that is added to 855 the name, for finding the specific public key. Hence, the relevant 856 ._domainkey. DNS record needs to contain a 857 DKIM-related RR that provides the public key information. 859 The administrator of the zone containing the relevant domain name 860 adds this information. Initial DKIM DNS information is contained 861 within TXT RRs. DNS administrative software varies considerably in 862 its abilities to support DKIM names, such as with underscores, and to 863 add new types of DNS information. 865 4.2. Signing Module 867 The module doing signing can be placed anywhere within an 868 organization's trusted Administrative Management Domain (ADMD); 869 obvious choices include department-level posting agents, as well as 870 outbound boundary MTAs to the open Internet. However any other 871 module, including the author's MUA, is potentially acceptable, as 872 long as the signature survives any remaining handling within the 873 ADMD. Hence the choice among the modules depends upon software 874 development, administrative overhead, security exposures and transit 875 handling tradeoffs. One perspective that helps to resolve this 876 choice is the difference between the increased flexibility, from 877 placement at (or close to) the MUA, versus the streamlined 878 administration and operation, that is more easily obtained by 879 implementing the mechanism "deeper" into the organization's email 880 infrastructure, such as at its boundary MTA. 882 Note the discussion in Section 2.2, concerning use of the i= tag. 884 The signing module uses the appropriate private key to create one or 885 more signatures. The means by which the signing module obtains the 886 private key(s) is not specified by DKIM. Given that DKIM is intended 887 for use during email transit, rather than for long-term storage, it 888 is expected that keys will be changed regularly. For administrative 889 convenience, key information SHOULD NOT be hard-coded into software. 891 4.3. Signing Policies and Practices 893 Every organization (ADMD) will have its own policies and practices 894 for deciding when to sign messages (message stream) and with what 895 domain name, selector and key. Examples of particular message 896 streams include all mail sent from the ADMD, versus mail from 897 particular types of user accounts, versus mail having particular 898 types of content. Given this variability, and the likelihood that 899 signing practices will change over time, it will be useful to have 900 these decisions represented through run-time configuration 901 information, rather than being hard-coded into the signing software. 903 As noted in Section 2.3, the choice of signing name granularity 904 requires balancing administrative convenience and utility for 905 recipients. Too much granularity is higher administrative overhead 906 and well might attempt to impose more differential analysis on the 907 recipient than they wish to support. In such cases, they are likely 908 to use only a super-name -- right-hand substring -- of the signing 909 name. When this occurs, the signer will not know what portion is 910 being used; this then moves DKIM back to the non-deterministic world 911 of heuristics, rather than the mechanistic world of signer/recipient 912 collaboration that DKIM seeks. 914 5. Verifying 916 A message recipient may verify a DKIM signature to determine if a 917 claim of responsibility has been made for the message by a trusted 918 domain. 920 Access control requires two components: authentication and 921 authorization. By design, verification of a DKIM signature only 922 provides the authentication component of an access control decision 923 and MUST be combined with additional sources of information such as 924 reputation data to arrive at an access control decision. 926 5.1. Intended Scope of Use 928 DKIM requires that a message with a signature that is found to be 929 invalid is to be treated as if the message had not been signed at 930 all. 932 If a DKIM signature fails to verify, it is entirely possible that the 933 message is valid and that either there is a configuration error in 934 the signer's system (e.g. a missing key record) or that the message 935 was inadvertently modified in transit. It is thus undesirable for 936 mail infrastructure to treat messages with invalid signatures less 937 favorably than those with no signatures whatsoever. Contrariwise, 938 creation of an invalid signature requires a trivial amount of effort 939 on the part of an attacker. If messages with invalid signatures were 940 to be treated preferentially to messages with no signatures 941 whatsoever, attackers will simply add invalid signature blocks to 942 gain the preferential treatment. It follows that messages with 943 invalid signatures SHOULD be treated no better and no worse than 944 those with no signature at all. 946 5.2. Signature Scope 948 As with any other digital signature scheme, verifiers MUST only 949 consider the part of the message that is inside the scope of the 950 message as being authenticated by the signature. 952 For example, if the l= option is employed to specify a content length 953 for the scope of the signature, only the part of the message that is 954 within the scope of the content signature would be considered 955 authentic. 957 5.3. Design Scope of Use 959 Public Key cryptography provides an exceptionally high degree of 960 assurance, bordering on absolute certainty, that the party that 961 created a valid digital signature had access to the private key 962 corresponding to the public key indicated in the signature. 964 In order to make useful conclusions from the verification of a valid 965 digital signature, the verifier is obliged to make assumptions that 966 fall far short of absolute certainty. Consequently, mere validation 967 of a DKIM signature does not represent proof positive that a valid 968 claim of responsibility was made for it by the indicated party, that 969 the message is authentic, or that the message is not abusive. In 970 particular: 972 o The legitimate private key holder may have lost control of its 973 private key. 975 o The legitimate domain holder may have lost control of the DNS 976 server for the zone from which the key record was retrieved. 978 o The key record may not have been delivered from the legitimate DNS 979 server for the zone from which the key record was retrieved. 981 o Ownership of the DNS zone may have changed. 983 In practice these limitations have little or no impact on the field 984 of use for which DKIM is designed but may have a bearing if use is 985 made of the DKIM message signature format or key retrieval mechanism 986 in other specifications. 988 In particular the DKIM key retrieval mechanism is designed for ease 989 of use and deployment rather than to provide a high assurance Public 990 Key Infrastructure suitable for purposes that require robust non- 991 repudiation such as establishing legally binding contracts. 992 Developers seeking to extend DKIM beyond its design application 993 SHOULD consider replacing or supplementing the DNS key retreival 994 mechanism with one that is designed to meet the intended purposes. 996 5.4. Inbound Mail Filtering 998 DKIM is frequently employed in a mail filtering strategy to avoid 999 performing content analysis on email originating from trusted 1000 sources. Messages that carry a valid DKIM signature from a trusted 1001 source may be whitelisted, avoiding the need to perform computation 1002 and hence energy intensive content analysis to determine the 1003 disposition of the message. 1005 Mail sources may be determined to be trusted by means of previously 1006 observed behavior and/or reference to external reputation or 1007 accreditation services. The precise means by which this is 1008 acomplished is outside the scope of DKIM. 1010 5.4.1. Non-Verifying Adaptive Spam Filtering Systems 1012 Adaptive (or learning) spam filtering mechanisms that are not capable 1013 of verifying DKIM signatures SHOULD at minimum be configured to 1014 ignore DKIM header data entirely. 1016 5.5. Messages sent through Mailing Lists and other Intermediaries 1018 Intermediaries such as mailing lists pose a particular challenge for 1019 DKIM implementations as the message processing steps performed by the 1020 intermediary may cause the message content to change in ways that 1021 prevent the signature passing verification. 1023 Such intermediaries are strongly encouraged to deploy DKIM signing so 1024 that a verifiable claim of responsibility remains available to 1025 parties attempting to verify the modified message. 1027 5.6. Generation, Transmission and Use of Results Headers 1029 In many deployments it is desirable to separate signature 1030 verification from the application relying on the verification. A 1031 system may choose to relay information indicating the results of its 1032 message authentication efforts using various means; adding a "results 1033 header" to the message is one such mechanism. [RFC5451] For example, 1034 consider the cases where: 1036 o The application relying on DKIM signature verification is not 1037 capable of performing the verification. 1039 o The message may be modified after the signature verification is 1040 performed. 1042 o The signature key may not be available by the time that the 1043 message is read. 1045 In such cases it is important that the communication link between the 1046 signature verifier and the relying application be sufficiently secure 1047 to prevent insertion of a message that carries a bogus results 1048 header. 1050 An intermediary that generates results headers SHOULD ensure that 1051 relying applications are able to distinguish valid results headers 1052 issued by the intermediary from those introduced by an attacker. For 1053 example, this can be accomplished by signing the results header. At 1054 a minimum, results headers on incoming messages SHOULD be removed if 1055 they purport to have been issued by the intermediary but cannot be 1056 verified as authentic. 1058 Further discussion on trusting the results as relayed from a verifier 1059 to something downstream can be found in [RFC5451] 1061 6. Taxonomy of Signatures 1063 A DKIM signature tells the signature verifier that the owner of a 1064 particular domain name accepts some responsibility for the message. 1065 It does not, in and of itself, provide any information about the 1066 trustworthiness or behavior of that identity. What it does provide 1067 is a verified identity to which such behavioral information can be 1068 associated, so that those who collect and use such information can be 1069 assured that it truly pertains to the identity in question. 1071 This section lays out a taxonomy of some of the different identities, 1072 or combinations of identities, that might usefully be represented by 1073 a DKIM signature. 1075 6.1. Single Domain Signature 1077 Perhaps the simplest case is when an organization signs its own 1078 outbound email using its own domain in the SDID ([rfc4871-update]) of 1079 the signature. For example, Company A would sign the outbound mail 1080 from its employees with d=companyA.example. 1082 In the most straightforward configuration, the addresses in the RFC 1083 5322 From would also be in the companyA.example domain, but that 1084 direct correlation is not required. 1086 A special case of the Single Domain Signature is an Author Signature 1087 as defined by the Author Domain Signing Practices specification 1088 ([I-D.ietf-dkim-ssp]). Author signatures are signatures from an 1089 author's organization that have an SDID value that matches that of an 1090 RFC5322 From: address of the signed message. 1092 Although an author signature might in some cases be proof against 1093 spoofing the domain name of the RFC 5322 From address, it is 1094 important to note that the DKIM and ADSP validation apply only to the 1095 exact address string and not to look-alike addresses nor to the 1096 human-friendly "display-name" or names and addresses used within the 1097 body of the message. That is, it protects only against the misuse of 1098 a precise address string within the RFC5322 From field and nothing 1099 else. For example, a message from bob@domain.example with a valid 1100 signature where d=d0main.example would fail an ADSP check because the 1101 signature domain, however similar, is distinct; however a message 1102 from bob@d0main.example with a valid signature where d=d0main.example 1103 would pass an ADSP check, even though to a human it might be obvious 1104 that d0main.example is likely a malicious attempt to spoof the domain 1105 domain.example. This example highlights that ADSP, like DKIM, is 1106 only able to validate a signing identifier: it still requires some 1107 external process to attach a meaningful reputation to that 1108 identifier. 1110 6.2. Parent Domain Signature 1112 Another approach that might be taken by an organization with multiple 1113 active subdomains is to apply the same (single) signature to mail 1114 from all subdomains. In this case, the signature chosen would 1115 usually be the signature of a parent domain common to all subdomains. 1116 For example, mail from marketing.domain.example, 1117 sales.domain.example, and engineering.domain.example might all use a 1118 signature with d=domain.example. 1120 This approach has the virtue of simplicity, but it is important to 1121 consider the implications of such a choice. As discussed in 1122 Section 2.3, if the type of mail sent from the different subdomains 1123 is significantly different or if there is reason to believe that the 1124 reputation of the subdomains would differ, then it may be a good idea 1125 to acknowledge this and provide distinct signatures for each of the 1126 subdomains (d=marketing.domain.example, sales.domain.example, etc.). 1127 However, if the mail and reputations are likely to be similar, then 1128 the simpler approach of using a single common parent domain in the 1129 signature may work well. 1131 Another approach to distinguishing the streams using a single DKIM 1132 key would be to leverage the AUID [rfc4871-update] (i= tag) in the 1133 DKIM signature to differentiate the mail streams. For example, 1134 marketing email would be signed with i=marketing.domain.example and 1135 d=domain.example. 1137 It's important to remember, however, that under core DKIM semantics 1138 the AUID is opaque to receivers. That means that it will only be an 1139 effective differentiator if there is an out of band agreement about 1140 the i= semantics. 1142 6.3. Third Party Signature 1144 A signature whose domain does not match the domain of the RFC 5322 1145 From address is sometimes referred to as a third party signature. In 1146 certain cases even the parent domain signature described above would 1147 be considered a third party signature because it would not be an 1148 exact match for the domain in the From: address. 1150 Although there is often heated debate about the value of third party 1151 signatures, it is important to note that the DKIM specification 1152 attaches no particular significance to the identity in a DKIM 1153 signature. The identity specified within the signature is the 1154 identity that is taking responsibility for the message, and it is 1155 only the interpretation of a given receiver that gives one identity 1156 more or less significance than another. In particular, most 1157 independent reputation services assign trust based on the specific 1158 identifier string, not its "role": in general they make no 1159 distinction between, for example, an author signature and a third 1160 party signature. 1162 For some, a signature unrelated to the author domain (the domain in 1163 the RFC 5322 From address) is less valuable because there is an 1164 assumption that the presence of an author signature guarantees that 1165 the use of the address in the From: header is authorized. 1167 For others, that relevance is tied strictly to the recorded 1168 behavioral data assigned to the identity in question, i.e. its trust 1169 assessment or reputation. The reasoning here is that an identity 1170 with a good reputation is unlikely to maintain that good reputation 1171 if it is in the habit of vouching for messages that are unwanted or 1172 abusive; in fact, doing so will rapidly degrade its reputation so 1173 that future messages will no longer benefit from it. It is therefore 1174 low risk to facilitate the delivery of messages that contain a valid 1175 signature of a domain with a strong positive reputation, independent 1176 of whether or not that domain is associated with the address in the 1177 RFC5322 From header field of the message. 1179 Third party signatures encompass a wide range of identities. Some of 1180 the more common are: 1182 Service Provider: In cases where email is outsourced to an Email 1183 Service Provider (ESP), Internet Service Provider (ISP), or other 1184 type of service provider, that service provider may choose to DKIM 1185 sign outbound mail with either its own identifier -- relying on 1186 its own, aggregate reputation -- or with a subdomain of the 1187 provider that is unique to the message author but still part of 1188 the provider's aggregate reputation. Such service providers may 1189 also encompass delegated business functions such as benefit 1190 management, although these will more often be treated as trusted 1191 third party senders (see below). 1193 Parent Domain. As discussed above, organizations choosing to apply a 1194 parent domain signature to mail originating from subdomains may 1195 have their signatures treated as third party by some verifiers, 1196 depending on whether or not the "t=s" tag is used to constrain the 1197 parent signature to apply only to its own specific domain. The 1198 default is to consider a parent domain signature valid for its 1199 subdomains. 1201 Reputation Provider: Another possible category of third party 1202 signature would be the identity of a third party reputation 1203 provider. Such a signature would indicate to receivers that the 1204 message was being vouched for by that third party. 1206 6.4. Using Trusted Third Party Senders 1208 For most of the cases described so far, there has been an assumption 1209 that the signing agent was responsible for creating and maintaining 1210 its own DKIM signing infrastructure, including its own keys, and 1211 signing with its own identity. 1213 A different model arises when an organization uses a trusted third 1214 party sender for certain key business functions, but still wants that 1215 email to benefit from the organization's own identity and reputation: 1216 in other words, the mail would come out of the trusted third party's 1217 mail servers, but the signature applied would be that of the 1218 controlling organization. 1220 This can be done by having the third party generate a key pair that 1221 is designated uniquely for use by that trusted third party and 1222 publishing the public key in the controlling organization's DNS 1223 domain, thus enabling the third party to sign mail using the 1224 signature of the controlling organization. For example, if Company A 1225 outsources its employee benefits to a third party, it can use a 1226 special keypair that enables the benefits company to sign mail as 1227 "companyA.example". Because the keypair is unique to that trusted 1228 third party, it is easy for Company A to revoke the authorization if 1229 necessary by simply removing the public key from the companyA.example 1230 DNS. 1232 In this scenario, may be a good idea to limit the specific identities 1233 that can be used by even trusted third parties. The DKIM g= tag 1234 enables a key record to specify one particular From: address local 1235 part that must be specified in the i= tag of the signature: for 1236 example, "g=benefits" would require a signature header tag of 1237 "i=benefits@companyA.example". It is important to note that although 1238 this distinction will be clear to the verifier it may be invisible to 1239 the recipient: there is no constraint within the DKIM verification 1240 process that constrains that specific i= value to correspond to any 1241 of the other message headers, including the From: header. 1243 A more reliable way of distinguishing the third party mail stream 1244 would be to create a dedicated subdomain (e.g. 1245 benefits.companyA.example) and publish the public key there; the 1246 signature would then use d=benefits.companyA.example. 1248 6.4.1. DNS Delegation 1250 Another possibility for configuring trusted third party access, as 1251 discussed in section 3.4, is to have Company A use DNS delegation and 1252 have the designated subdomain managed directly by the trusted third 1253 party. In this case, Company A would create a subdomain 1254 benefits.companya.example, and delegate the DNS management of that 1255 subdomain to the benefits company so it could maintain its own key 1256 records. Should revocation become necessary, Company A could simply 1257 remove the DNS delegation record. 1259 6.5. Multiple Signatures 1261 A simple configuration for DKIM-signed mail is to have a single 1262 signature on a given message. This works well for domains that 1263 manage and send all of their own email from single sources, or for 1264 cases where multiple email streams exist but each has its own unique 1265 key pair. It also represents the case in which only one of the 1266 participants in an email sequence is able to sign, no matter whether 1267 it represents the author or one of the operators. 1269 The examples thus far have considered the implications of using 1270 different identities in DKIM signatures, but have used only one such 1271 identity for any given message. In some cases, it may make sense to 1272 have more than one identity claiming responsibility for the same 1273 message. 1275 There are a number of situations where applying more than one DKIM 1276 signature to the same message might make sense. A few examples are: 1278 Companies with multiple subdomain identities: A company that has 1279 multiple subdomains sending distinct categories of mail might 1280 choose to sign with distinct subdomain identities to enable each 1281 subdomain to manage its own identity. However, it might also want 1282 to provide a common identity that cuts across all of the distinct 1283 subdomains. For example, Company A may sign mail for its sales 1284 department with a signature where d=sales.companya.example, and a 1285 second signature where d=companya.example 1287 Service Providers: A service providers may, as described above, 1288 choose to sign outbound messages with either its own identity or 1289 with an identity unique to each of its clients (possibly 1290 delegated). However, it may also do both: sign each outbound 1291 message with its own identity as well as with the identity of each 1292 individual client. For example, ESP A might sign mail for its 1293 client Company B with its service provider signature 1294 d=espa.example, and a second client-specific signature where d= 1295 either companyb.example, or companyb.espa.example. The existence 1296 of the service provider signature could, for example, help cover a 1297 new client while it establishes its own reputation, or help a very 1298 small volume client who might never reach a volume threshold 1299 sufficient to establish an individual reputation. 1301 Forwarders Forwarded mail poses a number of challenges to email 1302 authentication. DKIM is relatively robust in the presence of 1303 forwarders as long as the signature is designed to avoid message 1304 parts that are likely to be modified, although some forwarders do 1305 make modifications that can invalidate a DKIM signature. 1307 However, some forwarders such as mailing lists or "forward article 1308 to a friend" services, might choose to add their own signatures to 1309 outbound messages to vouch for them having legitimately originated 1310 from the designated service. In this case, the signature would be 1311 added even in the presence of a preexisting signature, and both 1312 signatures would be relevant to the verifier. 1314 Any forwarder that modifies messages in ways that will break 1315 preexisting DKIM signatures SHOULD always sign its forwarded 1316 messages. 1318 Reputation Providers: Although third party reputation providers 1319 today use a variety of protocols to communicate their information 1320 to receivers, it is possible that they, or other organizations 1321 willing to put their "seal of approval" on an email stream might 1322 choose to use a DKIM signature to do it. In nearly all cases, 1323 this "reputation" signature would be in addition to the author or 1324 originator signature. 1326 One important caveat to the use of multiple signatures is that there 1327 is currently no clear consensus among receivers on how they plan to 1328 handle them. The opinions range from ignoring all but one signature 1329 (and the specification of which of them is verified differs from 1330 receiver to receiver), to verifying all signatures present and 1331 applying a weighted blend of the trust assessments for those 1332 identifiers, to verifying all signatures present and simply using the 1333 identifier that represents the most positive trust assessment. It is 1334 likely that the industry will evolve to accept multiple signatures 1335 using either the second or third of these, but it may take some time 1336 before one approach becomes pervasive. 1338 7. Example Usage Scenarios 1340 Signatures are created by different types of email actors, based on 1341 different criteria, such as where the actor operates in the sequence 1342 from author to recipient, whether they want different messages to be 1343 evaluated under the same reputation or a different one, and so on. 1344 This section provides some examples of usage scenarios for DKIM 1345 deployments; the selection is not intended to be exhaustive, but to 1346 illustrate a set of key deployment considerations. 1348 7.1. Author's Organization - Simple 1350 The simplest DKIM configuration is to have some mail from a given 1351 organization (Company A) be signed with the same d= value (e.g. 1352 d=companya.example). If there is a desire to associate a user 1353 identity or some other related information, the AUID [rfc4871-update] 1354 value can become uniqueID@companya.example, or 1355 @uniqueID.companya.example. 1357 In this scenario, Company A need only generate a single signing key 1358 and publish it under their top level domain (companya.example); the 1359 signing module would then tailor the AUID value as needed at signing 1360 time. 1362 7.2. Author's Organization - Differentiated Types of Mail 1364 A slight variation of the one signature case is where Company A signs 1365 some of its mail, but it wants to differentiate different categories 1366 of its outbound mail by using different identifiers. For example, it 1367 might choose to distinguish marketing mail, billing or transactional 1368 mail, and individual corporate email into marketing.companya.example, 1369 billing.companya.example, and companya.example, where each category 1370 is assigned a unique subdomain and unique signing keys. 1372 7.3. Author Signature 1374 As discussed in Section 6.1, author signatures are a special case of 1375 signatures from an author's organization where at least one signature 1376 on the message has a SDID [rfc4871-update] value that matches the 1377 From: address of the message. 1379 Signers wishing to publish an Author Domain Signing Practices (ADSP) 1380 [I-D.ietf-dkim-ssp] record describing their signing practices will 1381 want to include an author signature on their outbound mail to avoid 1382 ADSP verification failures. For example, if the address in the RFC 1383 5322 From is bob@company.example, the SDID value of the author 1384 signature would be company.example. 1386 7.4. Author Domain Signing Practices 1388 7.4.1. Introduction 1390 The legacy of the Internet is such that not all messages will be 1391 signed, so the absence of a signature on a message is not an a priori 1392 indication of forgery: in fact, during early phases of deployment it 1393 is very likely that most messages will remain unsigned. 1395 Some domains may decide to sign all of their outgoing mail, for 1396 example, to assist in protecting their brand names. If all of the 1397 legitimate mail for a brand is signed, recipients can be more 1398 aggressive in their filtering of mail that uses the brand but is not 1399 signed by the domain name associated with the brand, because in such 1400 a configuration, the absence of a signature should be more 1401 significant than it would be for the general case. It might be 1402 desirable for such domains to be able to advertise their intent to 1403 other hosts: this is the topic of Author Domain Signing Practices 1404 (ADSP). 1406 Note that ADSP is not for everyone. Sending domains that do not 1407 control all legitimate outbound mail purporting to be from their 1408 domain (i.e., with a From address in their domain) are likely to 1409 experience delivery problems with some percentage of that mail. 1411 Administrators evaluating ADSP for their domains SHOULD carefully 1412 weigh the risk of phishing attacks against the likelihood of 1413 undelivered mail. 1415 This section covers some examples of ADSP usage: for the complete 1416 specification, see [I-D.ietf-dkim-ssp] 1418 7.4.2. A Few Definitions 1420 In the ADSP specification, an in the From header field of 1421 a message [RFC5322] is defined as an "Author Address", and an "Author 1422 Domain" is defined as anything to the right of the '@' in an Author 1423 Address. 1425 An "Author Signature" is thus any valid signature where the value of 1426 the SDID matches an Author Address in the message. 1428 It is important to note that unlike the DKIM specification which 1429 makes no correlation between the signature domain and any message 1430 headers, the ADSP specification applies only to the author domain. 1431 In essence, under ADSP, any non-author signatures are ignored 1432 (treated as if they are not present). 1434 7.4.3. Some ADSP Examples 1436 An organization (Company A) may specify its signing practices by 1437 publishing an ADSP record with "dkim=all" or "dkim=discardable". In 1438 order to avoid misdelivery of its mail at receivers that are 1439 validating ADSP, Company A MUST first have done an exhaustive 1440 analysis to determine all sources of outbound mail from its domain 1441 (companyA.example) and ensure that they all have valid author 1442 signatures from that domain. 1444 For example, email with an RFC 5322 From of bob@ 1445 companyA.example MUST have an author signature where theSDID value is 1446 either "companyA.example" or it will fail an ADSP validation. 1448 Note that once an organization publishes an ADSP record using 1449 dkim=all or dkim=discardable, any email with a RFC 5322 From address 1450 that uses the domain where the ADSP record is published that does not 1451 have a valid author signature is at risk of being mis-delivered or 1452 discarded. For example, if a message with an RFC 5322 From of newsletter@companyA.example has a signature with 1454 d=marketing.companyA.example, that message will fail the ADSP check 1455 because the signature would not be considered a valid author 1456 signature. 1458 Because the semantics of an ADSP author signature are more 1459 constrained than the semantics of a "pure" DKIM signature, it is 1460 important to make sure the nuances are well understood before 1461 deploying an ADSP record. The ADSP specification [I-D.ietf-dkim-ssp] 1462 provides some fairly extensive lookup examples (in Appendix A) and 1463 usage examples (in Appendix B). 1465 In particular, in order to prevent mail from being negatively 1466 impacted or even discarded at the receiver, it is essential to 1467 perform a thorough survey of outbound mail from a domain before 1468 publishing an ADSP policy of anything stronger than "unknown". This 1469 includes mail that might be sent from external sources that may not 1470 be authorized to use the domain signature, as well as mail that risks 1471 modification in transit that might invalidate an otherwise valid 1472 author signature (e.g. mailing lists, courtesy forwarders, and other 1473 paths that could add or modify headers, or modify the message body). 1475 7.5. Delegated Signing 1477 An organization may choose to outsource certain key services to an 1478 independent company. For example, Company A might outsource its 1479 benefits management, or Organization B might outsource its marketing 1480 email. 1482 If Company A wants to ensure that all of the mail sent on its behalf 1483 through the benefits providers email servers shares the Company A 1484 reputation, as discussed in Section 6.4 it can either publish keys 1485 designated for the use of the benefits provider under 1486 companyA.example (preferably under a designated subdomain of 1487 companyA.example), or it can delegate a subdomain (e.g. 1488 benefits.companyA.example) to the provider and enable the provider to 1489 generate the keys and manage the DNS for the designated subdomain. 1491 In both of these cases, mail would be physically going out of the 1492 benefit provider's mail servers with a signature of e.g. 1493 d=benefits.companya.example. Note that the From: address is not 1494 constrained: it could either be affiliated with the benefits company 1495 (e.g. benefits-admin@benefitprovider.example, or 1496 benefits-provider@benefits.companya.example), or with the companyA 1497 domain. 1499 Note that in both of the above scenarios, as discussed in 1500 Section 3.4, security concerns dictate that the keys be generated by 1501 the organization that plans to do the signing so that there is no 1502 need to transfer the private key. In other words, the benefits 1503 provider would generate keys for both of the above scenarios. 1505 7.6. Independent Third Party Service Providers 1507 Another way to manage the service provider configuration would be to 1508 have the service provider sign the outgoing mail on behalf of its 1509 client Company A with its own (provider) identifier. For example, an 1510 Email Service Provider (ESP A) might want to share its own mailing 1511 reputation with its clients, and may sign all outgoing mail from its 1512 clients with its own d= domain (e.g. d=espa.example). 1514 Should the ESP want to distinguish among its clients, it has two 1515 options: 1517 o Share the SDID domain, and use the AUID value to distinguish among 1518 the clients: e.g. a signature on behalf of client A would have 1519 d=espa.example and i=clienta.espa.example (or 1520 i=clienta@espa.example) 1522 o Extend the SDID domain, so there is a unique value (and subdomain) 1523 for each client: e.g. a signature on behalf of client A would have 1524 d=clienta.espa.example. 1526 Note that this scenario and the delegation scenario are not mutually 1527 exclusive: in some cases, it may be desirable to sign the same 1528 message with both the ESP and the ESP client identities. 1530 7.7. Mail Streams Based on Behavioral Assessment 1532 An ISP (ISP A) might want to assign signatures to outbound mail from 1533 its users according to each user's past sending behavior 1534 (reputation). In other words, the ISP would segment its outbound 1535 traffic according to its own assessment of message quality, to aid 1536 recipients in deciding to process these different streams 1537 differently. Since the semantics of behavioral assessments aren't 1538 allowed as AUID values, ISP A (ispa.example) may configure subdomains 1539 corresponding to the assessment categories (e.g. good.ispa.example, 1540 neutral.ispa.example, bad.ispa.example), and use these subdomains in 1541 the d= value of the signature. 1543 The signing module can also optionally set the AUID value to have a 1544 unique user id (distinct from the local-part of the user's email 1545 address), for example user3456@neutral.domain.example. Using a 1546 userid that is distinct from a given email alias is useful in 1547 environments where a single user might register multiple email 1548 aliases. 1550 Note that in this case the AUID values are only partially stable. 1551 They are stable in the sense that a given i= value will always 1552 represent the same identity, but they are unstable in the sense that 1553 a given user can migrate among the assessment subdomains depending on 1554 their sending behavior (i.e., the same user might have multiple AUID 1555 values over the lifetime of a single account). 1557 In this scenario, ISP A may generate as many keys as there are 1558 assessment subdomains (SDID values), so that each assessment 1559 subdomain has its own key. The signing module would then choose its 1560 signing key based on the assessment of the user whose mail was being 1561 signed, and if desired include the user id in the AUID of the 1562 signature. As discussed earlier, the per-user granularity of the 1563 AUID may be ignored by many verifiers, so organizations choosing to 1564 use it should not rely on its use for receiver side filtering 1565 results; however, some organizations may also find the information 1566 useful for thier own purposes in processing bounces or abuse reports. 1568 7.8. Agent or Mediator Signatures 1570 Another scenario is that of an agent, usually a re-mailer of some 1571 kind, that signs on behalf of the service or organization that it 1572 represents. Some examples of agents might be a mailing list manager, 1573 or the "forward article to a friend" service that many online 1574 publications offer. In most of these cases, the signature is 1575 asserting that the message originated with, or was relayed by, the 1576 service asserting responsibility. In general, if the service is 1577 configured in such a way that its forwarding would break existing 1578 DKIM signatures, it should always add its own signature. 1580 8. Usage Considerations 1582 8.1. Non-standard Submission and Delivery Scenarios 1584 The robustness of DKIM's verification mechanism is based on the fact 1585 that only authorized signing modules have access to the designated 1586 private key. This has the side effect that email submission and 1587 delivery scenarios that originate or relay messages from outside the 1588 domain of the authorized signing module will not have access to that 1589 protected private key, and thus will be unable to attach the expected 1590 domain signature to those messages. Such scenarios include mailing 1591 lists, courtesy forwarders, MTAs at hotels, hotspot networks used by 1592 travelling users, and other paths that could add or modify headers, 1593 or modify the message body. 1595 For example, assume Joe works for Company A and has an email address 1596 joe@companya.example. Joe also has a ISP-1 account 1597 joe@isp1.example.com, and he uses ISP-1's multiple address feature to 1598 attach his work email joe@companya.example to his ISP-1 account. 1599 When Joe sends email from his ISP-1 account and uses 1600 joe@companya.example as his designated From: address, that email 1601 cannot have a signature with d=companya.example because the ISP-1 1602 servers have no access to Company A's private key. In ISP-1's case 1603 it will have a ISP-1 signature, but for some other mail clients 1604 offering the same multiple address feature there may be no signature 1605 at all on the message. 1607 Another example might be the use of a forward article to a friend 1608 service. Most instances of these services today allow someone to 1609 send an article with their email address in the RFC 5322 From to 1610 their designated recipient. If Joe used either of his two addresses 1611 (joe@companya.example or joe@isp1.example.com), the forwarder would 1612 be equally unable to sign with a corresponding domain . As in the 1613 mail client case, the forwarder may either sign as its own domain, or 1614 may put no signature on the message. 1616 A third example is the use of privately configured forwarding. 1617 Assume that Joe has another account at ISP-2, joe@isp-2.example.com, 1618 but he'd prefer to read his ISP-2 mail from his ISP-1 account. He 1619 sets up his ISP-2 account to forward all incoming mail to 1620 joe@isp1.example.com. Assume alice@companyb.example sends 1621 joe@isp-2.example.com an email. Depending on how companyb.example 1622 configured its signature, and depending on whether or not ISP-2 1623 modifies messages that it forwards, it is possible that when Alice's 1624 message is received in Joe's ISP-1 account the original signature 1625 fails verification. 1627 8.2. Protection of Internal Mail 1629 One identity is particularly amenable to easy and accurate 1630 assessment: the organization's own identity. Members of an 1631 organization tend to trust messages that purport to be from within 1632 that organization. However Internet Mail does not provide a 1633 straightforward means of determining whether such mail is, in fact, 1634 from within the organization. DKIM can be used to remedy this 1635 exposure. If the organization signs all of its mail, then its 1636 boundary MTAs can look for mail purporting to be from the 1637 organization that does not contain a verifiable signature. 1639 Such mail can in most cases be presumed to be spurious. However, 1640 domain managers are advised to consider the ways that mail processing 1641 can modify messages in ways that will invalidate an existing DKIM 1642 signature: mailing lists, courtesy forwarders, and other paths that 1643 could add or modify headers or modify the message body (e.g. MTAs at 1644 hotels, hotspot networks used by travelling users, and other 1645 scenarios described in the previous section). Such breakage is 1646 particularly relevant in the presence of Author Domain Signing 1647 Practices. 1649 8.3. Signature Granularity 1651 Although DKIM's use of domain names is optimized for a scope of 1652 organization-level signing, it is possible to administer sub-domains 1653 or otherwise adjust signatures in a way that supports per-user 1654 identification. This user level granularity can be specified in two 1655 ways: either by sharing the signing identity and specifying an 1656 extension to the i= value that has a per-user granularity, or by 1657 creating and signing with unique per-user keys. 1659 A subdomain or local part in the i= tag SHOULD be treated as an 1660 opaque identifier and thus need not correspond directly to a DNS 1661 subdomain or be a specific user address. 1663 The primary way to sign with per-user keys requires each user to have 1664 a distinct DNS (sub)domain, where each distinct d= value has a key 1665 published. (It is possible, although not recommended, to publish the 1666 same key in more than one distinct domain.) 1668 It is technically possible to publish per-user keys within a single 1669 domain or subdomain by utilizing different selector values. This is 1670 not recommended and is unlikely to be treated uniquely by Assessors: 1671 the primary purpose of selectors is to facilitate key management, and 1672 the DKIM specification recommends against using them in determining 1673 or assessing identies. 1675 In most cases, it would be impractical to sign email on a per-user 1676 granularity. Such an approach would be 1678 likely to be ignored: In most cases today, if receivers are 1679 verifying DKIM signatures they are in general taking the simplest 1680 possible approach. In many cases maintaining reputation 1681 information at a per user granularity is not interesting to them, 1682 in large part because the per user volume is too small to be 1683 useful or interesting. So even if senders take on the complexity 1684 necessary to support per user signatures, receivers are unlikely 1685 to retain anything more than the base domain reputation. 1687 difficult to manage: Any scheme that involves maintenance of a 1688 significant number of public keys may require infrastructure 1689 enhancements or extensive administrative expertise. For domains 1690 of any size, maintaining a valid per-user keypair, knowing when 1691 keys need to be revoked or added due to user attrition or 1692 onboarding, and the overhead of having the signing engine 1693 constantly swapping keys can create significant and often 1694 unnecessary managment complexity. It is also important to note 1695 that there is no way within the scope of the DKIM specification 1696 for a receiver to infer that a sender intends a per-user 1697 granularity. 1699 As mentioned before, what may make sense, however, is to use the 1700 infrastructure that enables finer granularity in signatures to 1701 identify segments smaller than a domain but much larger than a per- 1702 user segmentation. For example, a university might want to segment 1703 student, staff, and faculty mail into three distinct streams with 1704 differing reputations. This can be done by creating seperate sub- 1705 domains for the desired segments, and either specifying the 1706 subdomains in the i= tag of the DKIM Signature or by adding 1707 subdomains to the d= tag and assigning and signing with different 1708 keys for each subdomain. 1710 For those who choose to represent user level granularity in 1711 signatures, the performance and management considerations above 1712 suggest that it would be more effective to do it by specifying a 1713 local part or subdomain extension in the i= tag rather than by 1714 extending the d= domain and publishing individual keys. 1716 8.4. Email Infrastructure Agents 1718 It is expected that the most common venue for a DKIM implementation 1719 will be within the infrastructure of an organization's email service, 1720 such as a department or a boundary MTA. What follows are some 1721 general recommendations for the Email Infrastructure. 1723 Outbound: An MSA or an Outbound MTA used for mail submission 1724 SHOULD ensure that the message sent is in compliance with the 1725 advertised email sending policy. It SHOULD also be able to 1726 generate an operator alert if it determines that the email 1727 messages do not comply with the published DKIM sending policy. 1729 An MSA SHOULD be aware that some MUAs may add their own 1730 signatures. If the MSA needs to perform operations on a 1731 message to make it comply with its email sending policy, if at 1732 all possible, it SHOULD do so in a way that would not break 1733 those signatures. 1735 MUAs equipped with the ability to sign SHOULD NOT be 1736 encouraged. In terms of security, MUAs are generally not under 1737 the direct control of those in responsible roles within an 1738 organization and are thus more vulnerable to attack and 1739 compromise, which would expose private signing keys to 1740 intruders and thus jeopardize the integrity and reputation of 1741 the organization. 1743 Inbound: When an organization deploys DKIM, it needs to make 1744 sure that its email infrastructure components that do not have 1745 primary roles in DKIM handling do not modify message in ways 1746 that prevent subsequent verification. 1748 An inbound MTA or an MDA may incorporate an indication of the 1749 verification results into the message, such as using an 1750 Authentication-Results header field. [RFC5451] 1752 Intermediaries: An email intermediary is both an inbound and 1753 outbound MTA. Each of the requirements outlined in the 1754 sections relating to MTAs apply. If the intermediary modifies 1755 a message in a way that breaks the signature, the intermediary 1757 + SHOULD deploy abuse filtering measures on the inbound mail, 1758 and 1760 + MAY remove all signatures that will be broken 1762 In addition the intermediary MAY: 1764 + Verify the message signature prior to modification. 1766 + Incorporate an indication of the verification results into 1767 the message, such as using an Authentication-Results header 1768 field. [RFC5451] 1770 + Sign the modified message including the verification results 1771 (e.g., the Authentication-Results header field). 1773 8.5. Mail User Agent 1775 The DKIM specification is expected to be used primarily between 1776 Boundary MTAs, or other infrastructure components of the originating 1777 and receiving ADMDs. However there is nothing in DKIM that is 1778 specific to those venues. In particular, MUAs MAY also support DKIM 1779 signing and verifying directly. 1781 Outbound: An MUA MAY support signing even if mail is to be 1782 relayed through an outbound MSA. In this case the signature 1783 applied by the MUA will be in addition to any signature added 1784 by the MSA. However, the warnings in the previous section 1785 should be taken into consideration. 1787 Some user software goes beyond simple user functionality and 1788 also perform MSA and MTA functions. When this is employed for 1789 sending directly to a receiving ADMD, the user software SHOULD 1790 be considered an outbound MTA. 1792 Inbound: An MUA MAY rely on a report of a DKIM signature 1793 verification that took place at some point in the inbound MTA/ 1794 MDA path (e.g., an Authentication-Results header field), or an 1795 MUA MAY perform DKIM signature verification directly. A 1796 verifying MUA SHOULD allow for the case where mail has modified 1797 in the inbound MTA path; if a signature fails, the message 1798 SHOULD NOT be treated any different than if it did not have a 1799 signature. 1801 An MUA that looks for an Authentication-Results header field 1802 MUST be configurable to choose which Authentication-Results are 1803 considered trustable. The MUA developer is encouraged to re- 1804 read the Security Considerations of [RFC5451]. 1806 DKIM requires that all verifiers treat messages with signatures 1807 that do not verify as if they are unsigned. 1809 If verification in the client is to be acceptable to users, it 1810 is essential that successful verification of a signature not 1811 result in a less than satisfactory user experience compared to 1812 leaving the message unsigned. The mere presence of a verified 1813 DKIM signature MUST NOT by itself be used by an MUA to indicate 1814 that a message is to be treated better than a message without a 1815 verified DKIM signature. However, the fact that a DKIM 1816 signature was verified MAY be used as input into a reputation 1817 system (i.e., a whitelist of domains and users) for 1818 presentation of such indicators. 1820 It is common for components of an ADMD's email infrastructure to do 1821 violence to a message, such that a DKIM signature might be rendered 1822 invalid. Hence, users of MUAs that support DKIM signing and/or 1823 verifying need a basis for knowing that their associated email 1824 infrastructure will not break a signature. 1826 9. Other Considerations 1828 9.1. Security Considerations 1830 The security considerations of the DKIM protocol are described in the 1831 DKIM base specification [RFC4871]. 1833 9.2. IANA Considerations 1835 This document has no considerations for IANA. 1837 10. Acknowledgements 1839 TBD 1841 11. Informative References 1843 [I-D.ietf-dkim-overview] 1844 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1845 Identified Mail (DKIM) Service Overview", 1846 draft-ietf-dkim-overview-10 (work in progress), July 2008. 1848 [I-D.ietf-dkim-ssp] 1849 field, h., Domain, A., error, r., Allman, E., Fenton, J., 1850 Delany, M., and J. Levine, "DomainKeys Identified Mail 1851 (DKIM) Author Domain Signing Practices (ADSP)", 1852 draft-ietf-dkim-ssp-10 (work in progress), May 2009. 1854 [I-D.ietf-openpgp-rfc2440bis] 1855 Callas, J., "OpenPGP Message Format", 1856 draft-ietf-openpgp-rfc2440bis-22 (work in progress), 1857 April 2007. 1859 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 1860 for Internet electronic mail: Part I: Message encipherment 1861 and authentication procedures", RFC 989, February 1987. 1863 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1864 STD 13, RFC 1034, November 1987. 1866 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 1867 Object Security Services", RFC 1848, October 1995. 1869 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1870 Exchange Formats", RFC 1991, August 1996. 1872 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1873 "OpenPGP Message Format", RFC 2440, November 1998. 1875 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1876 "MIME Security with OpenPGP", RFC 3156, August 2001. 1878 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 1879 August 2001. 1881 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1882 Extensions (S/MIME) Version 3.1 Message Specification", 1883 RFC 3851, July 2004. 1885 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1886 Rose, "Resource Records for the DNS Security Extensions", 1887 RFC 4034, March 2005. 1889 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1890 Identified Mail (DKIM)", RFC 4686, September 2006. 1892 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 1893 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1894 May 2007. 1896 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1897 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1898 Signatures", RFC 4871, May 2007. 1900 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1901 Security (DNSSEC) Hashed Authenticated Denial of 1902 Existence", RFC 5155, March 2008. 1904 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1905 October 2008. 1907 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1908 October 2008. 1910 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 1911 Message Authentication Status", RFC 5451, April 2009. 1913 [rfc4871-update] 1914 Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 1915 (DKIM) Signatures -- Update", 1916 I-D draft-ietf-dkim-rfc4871-errata-03, April 2009. 1918 Appendix A. Migrating from DomainKeys 1920 As with any migration, the steps required will be determined by who 1921 is doing the migration and their assessment of 1923 o the users of what they are generating, or 1924 o the providers of what they are consuming. 1926 A.1. Signers 1928 A signer that currently signs with DomainKeys (DK) will go through 1929 various stages as it migrates to using DKIM, not all of which are 1930 required for all signers. The real questions that a signer must ask 1931 are: 1933 1. how many receivers or what types of receivers are *only* looking 1934 at the DK signatures and not the DKIM signatures, and 1936 2. how much does the signer care about those receivers? 1938 If no one is looking at the DK signature any more, then it's no 1939 longer necessary to sign with DK. Or if all "large players" are 1940 looking at DKIM in addition to or instead of DK, a signer MAY choose 1941 to stop signing with DK. 1943 With respect to signing policies, a reasonable, initial approach is 1944 to use DKIM signatures in the same way as DomainKeys signatures are 1945 already being used. In particular, the same selectors and DNS Key 1946 Records may be used for both, after verifying that they are 1947 compatible as discussed below. 1949 Each secondary step in all of the following scenarios is to be 1950 prefaced with the gating factor "test, then when comfortable with the 1951 previous step's results, continue". 1953 One migration strategy is to: 1955 o ensure that the current selector DNS key record is compatible with 1956 both DK and DKIM 1958 o sign messages with both DK and DKIM signatures 1960 o when it's decided that DK signatures are no longer necessary, stop 1961 signing with DK 1963 Another migration strategy is to: 1965 o add a new selector DNS key record only for DKIM signatures 1967 o sign messages with both DK (using the old DNS key record) and DKIM 1968 signatures (using the new DNS key record) 1970 o when it's decided that DK signatures are no longer necessary, stop 1971 signing with DK 1973 o eventually remove the old DK selector DNS record 1975 A combined migration strategy is to: 1977 o ensure that the current selector DNS key record is compatible with 1978 both DK and DKIM 1980 o start signing messages with both DK and DKIM signatures 1982 o add a new selector DNS key record for DKIM signatures 1984 o switch the DKIM signatures to use the new selector 1986 o when it's decided that DK signatures are no longer necessary, stop 1987 signing with DK 1989 o eventually remove the old DK selector DNS record 1991 Another migration strategy is to: 1993 o add a new selector DNS key record for DKIM signatures 1995 o do a flash cut and replace the DK signatures with DKIM signatures 1997 o eventually remove the old DK selector DNS record 1999 Another migration strategy is to: 2001 o ensure that the current selector DNS key record is compatible with 2002 both DK and DKIM 2004 o do a flash cut and replace the DK signatures with DKIM signatures 2006 Note that when you have separate key records for DK and DKIM, you can 2007 use the same public key for both. 2009 A.1.1. DNS Selector Key Records 2011 The first step in some of the above scenarios is ensuring that the 2012 selector DNS key records are compatible for both DK and DKIM. The 2013 format of the DNS key record was intentionally meant to be backwardly 2014 compatible between the two systems, but not necessarily upwardly 2015 compatible. DKIM has enhanced the DK DNS key record format by adding 2016 several optional parameters, which DK must ignore. However, there is 2017 one critical difference between DK and DKIM DNS key records: the 2018 definitions of the "g" fields: 2020 g= granularity of the key In both DK and DKIM, this is an optional 2021 field that is used to constrain which sending address(es) can 2022 legitimately use this selector. Unfortunately, the treatment of 2023 an empty field ("g=;") is different. DKIM allows wildcards where 2024 DK does not. For DK, an empty field is the same as a missing 2025 value, and is treated as allowing any sending address. For DKIM, 2026 an empty field only matches an empty local part. In DKIM, both a 2027 missing value and "g=*;" mean to allow any sending address. 2029 If your DK DNS key record has an empty "g" field in it ("g=;"), 2030 your best course of action is to modify the record to remove the 2031 empty field. In that way, the DK semantics will remain the same, 2032 and the DKIM semantics will match. 2034 If your DNS key record does not have an empty "g" field in it 2035 ("g=;"), it's probable that the record can be left alone. But your 2036 best course of action would still be to make sure it has a "v" field. 2037 When the decision is made to stop supporting DomainKeys and to only 2038 support DKIM, you MUST verify that the "g" field is compatible with 2039 DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED 2040 that if you want to use an empty "g" field in your DKIM selector, you 2041 also include the "v" field. 2043 A.1.2. Removing DomainKeys Signatures 2045 The principal use of DomainKeys is at Boundary MTAs. Because no 2046 operational transition is ever instantaneous, it is advisable to 2047 continue performing DomainKeys signing until it is determined that 2048 DomainKeys receive-side support is no longer used, or is sufficiently 2049 reduced. That is, a signer SHOULD add a DKIM signature to a message 2050 that also has a DomainKeys signature and keep it there until you 2051 decide it is deemed no longer useful. The signer may do its 2052 transitions in a straightforward manner, or more gradually. Note 2053 that because digital signatures are not free, there is a cost to 2054 performing both signing algorithms, so signing with both algorithms 2055 should not be needlessly prolonged. 2057 The tricky part is deciding when DK signatures are no longer 2058 necessary. The real questions are: how many DomainKeys verifiers are 2059 there that do *not* also do DKIM verification, which of those are 2060 important, and how can you track their usage? Most of the early 2061 adopters of DK verification have added DKIM verification, but not all 2062 yet. If a verifier finds a message with both DK and DKIM, it may 2063 choose to verify both signatures, or just one or the other. 2065 Many DNS services offer tracking statistics so it can be determined 2066 how often a DNS record has been accessed. By using separate DNS 2067 selector key records for your signatures, you can chart the usage of 2068 your records over time, and watch the trends. An additional 2069 distinguishing factor to track would take into account the verifiers 2070 that verify both the DK and DKIM signatures, and discount those from 2071 counts of DK selector usage. When the number for DK selector access 2072 reaches a low-enough level, that's the time to consider discontinuing 2073 signing with DK. 2075 Note, this level of rigor is not required. It is perfectly 2076 reasonable for a DK signer to decide to follow the "flash cut" 2077 scenario described above. 2079 A.2. Verifiers 2081 As a verifier, several issues must be considered: 2083 A.2.1. Should DK signature verification be performed? 2085 At the time of writing, there is still a significant number of sites 2086 that are only producing DK signatures. Over time, it is expected 2087 that this number will go to zero, but it may take several years. So 2088 it would be prudent for the foreseeable future for a verifier to look 2089 for and verify both DKIM and DK signatures. 2091 A.2.2. Should both DK and DKIM signatures be evaluated on a single 2092 message? 2094 For a period of time, there will be sites that sign with both DK and 2095 DKIM. A verifier receiving a message that has both types of 2096 signatures may verify both signatures, or just one. One disadvantage 2097 of verifying both signatures is that signers will have a more 2098 difficult time deciding how many verifiers are still using their DK 2099 selectors. One transition strategy is to verify the DKIM signature, 2100 then only verify the DK signature if the DKIM verification fails. 2102 A.2.3. DNS Selector Key Records 2104 The format of the DNS key record was intentionally meant to be 2105 backwardly compatible between DK and DKIM, but not necessarily 2106 upwardly compatible. DKIM has enhanced the DK DNS key record format 2107 by adding several optional parameters, which DK must ignore. 2108 However, there is one key difference between DK and DKIM DNS key 2109 records: the definitions of the g fields: 2111 g= granularity of the key In both DK and DKIM, this is an optional 2112 field that is used to constrain which sending address(es) can 2113 legitimately use this selector. Unfortunately, the treatment of 2114 an empty field ("g=;") is different. For DK, an empty field is 2115 the same as a missing value, and is treated as allowing any 2116 sending address. For DKIM, an empty field only matches an empty 2117 local part. 2119 v= version of the selector It is recommended that a DKIM selector 2120 have "v=DKIM1;" at its beginning, but it is not required. 2122 If a DKIM verifier finds a selector record that has an empty "g" 2123 field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its 2124 beginning, it is faced with deciding if this record was 2126 1. from a DK signer that transitioned to supporting DKIM but forgot 2127 to remove the "g" field (so that it could be used by both DK and 2128 DKIM verifiers), or 2130 2. from a DKIM signer that truly meant to use the empty "g" field 2131 but forgot to put in the "v" field. It is RECOMMENDED that you 2132 treat such records using the first interpretation, and treat such 2133 records as if the signer did not have a "g" field in the record. 2135 Appendix B. General Coding Criteria for Cryptographic Applications 2137 NOTE: This section could possibly be changed into a reference to 2138 something else, such as another rfc. 2140 Correct implementation of a cryptographic algorithm is a necessary 2141 but not a sufficient condition for the coding of cryptographic 2142 applications. Coding of cryptographic libraries requires close 2143 attention to security considerations that are unique to cryptographic 2144 applications. 2146 In addition to the usual security coding considerations, such as 2147 avoiding buffer or integer overflow and underflow, implementers 2148 should pay close attention to management of cryptographic private 2149 keys and session keys, ensuring that these are correctly initialized 2150 and disposed of. 2152 Operating system mechanisms that permit the confidentiality of 2153 private keys to be protected against other processes should be used 2154 when available. In particular, great care must be taken when 2155 releasing memory pages to the operating system to ensure that private 2156 key information is not disclosed to other processes. 2158 Certain implementations of public key algorithms such as RSA may be 2159 vulnerable to a timing analysis attack. 2161 Support for cryptographic hardware providing key management 2162 capabilities is strongly encouraged. In addition to offering 2163 performance benefits, many cryptographic hardware devices provide 2164 robust and verifiable management of private keys. 2166 Fortunately appropriately designed and coded cryptographic libraries 2167 are available for most operating system platforms under license terms 2168 compatible with commercial, open source and free software license 2169 terms. Use of standard cryptographic libraries is strongly 2170 encouraged. These have been extensively tested, reduce development 2171 time and support a wide range of cryptographic hardware. 2173 Authors' Addresses 2175 Tony Hansen 2176 AT&T Laboratories 2177 200 Laurel Ave. South 2178 Middletown, NJ 07748 2179 USA 2181 Email: tony+dkimov@maillennium.att.com 2183 Ellen Siegel 2184 Constant Contact, Inc. 2185 1601 Trapelo Rd, Ste 329 2186 Waltham, MA 02451 2187 USA 2189 Email: esiegel@constantcontact.com 2191 Phillip Hallam-Baker 2192 VeriSign Inc. 2194 Email: pbaker@verisign.com 2196 Dave Crocker 2197 Brandenburg InternetWorking 2198 675 Spruce Dr. 2199 Sunnyvale, CA 94086 2200 USA 2202 Email: dcrocker@bbiw.net