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