idnits 2.17.1 draft-ietf-dkim-deployment-03.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC4871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 269: '... needs to specify that the signer MUST...' RFC 2119 keyword, line 271: '...ent. This value MUST be the basis for...' RFC 2119 keyword, line 272: '...ent. The signer MAY provide the asses...' RFC 2119 keyword, line 273: '...paque value that MAY be used when repo...' RFC 2119 keyword, line 274: '...DKIM process and MAY be used for addit...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1252 has weird spacing: '... domain and u...' == Line 1257 has weird spacing: '... domain so th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2009) is 5554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5155' is mentioned on line 658, but not defined == Unused Reference: 'I-D.ietf-dkim-ssp' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-openpgp-rfc2440bis' is defined on line 1573, but no explicit reference was found in the text == Unused Reference: 'RFC0989' is defined on line 1584, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1588, but no explicit reference was found in the text == Unused Reference: 'RFC1848' is defined on line 1591, but no explicit reference was found in the text == Unused Reference: 'RFC1991' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: 'RFC2440' is defined on line 1597, but no explicit reference was found in the text == Unused Reference: 'RFC3156' is defined on line 1600, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 1603, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 1606, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 1610, but no explicit reference was found in the text == Unused Reference: 'RFC4870' is defined on line 1613, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 1621, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 1625, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1628, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-dkim-overview-10 == Outdated reference: A later version (-10) exists of draft-ietf-dkim-ssp-09 -- Obsolete informational reference (is this intentional?): RFC 989 (Obsoleted by RFC 1040, RFC 1113) -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 4 errors (**), 0 flaws (~~), 21 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DomainKeys Identified Mail T. Hansen 3 Internet-Draft AT&T Laboratories 4 Intended status: Informational E. Siegel 5 Expires: August 13, 2009 Constant Contact, Inc. 6 P. Hallam-Baker 7 VeriSign Inc. 8 D. Crocker 9 Brandenburg InternetWorking 10 February 9, 2009 12 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations 13 draft-ietf-dkim-deployment-03 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 13, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 DomainKeys Identified Mail (DKIM) allows an organization to claim 53 responsibility for transmitting a message, in a way that can be 54 validated by a recipient. The organization can be the author's, the 55 originating sending site, an intermediary, or one of their agents. A 56 message can contain multiple signatures, from the same or different 57 organizations involved with the message. DKIM defines a domain-level 58 digital signature authentication framework for email, using public 59 key cryptography, using the domain name service as its key server 60 technology [RFC4871]. This permits verification of a responsible 61 organization, as well as the integrity of the message contents. DKIM 62 will also provide a mechanism that permits potential email signers to 63 publish information about their email signing practices; this will 64 permit email receivers to make additional assessments about messages. 65 DKIM's authentication of email identity can assist in the global 66 control of "spam" and "phishing". This document provides 67 implementation, deployment, operational and migration considerations 68 for DKIM. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5 74 2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5 75 2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7 76 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9 77 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11 78 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14 80 3.1. Private Key Management: Deployment and Ongoing 81 Operations . . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.2. Storing Public Keys: DNS Server Software Considerations . 16 83 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 84 3.4. Third Party Signer Key Management and Selector 85 Administration . . . . . . . . . . . . . . . . . . . . . . 17 86 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18 87 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20 90 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 20 91 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 21 93 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 21 94 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 22 95 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 23 96 6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 24 97 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 25 98 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 27 99 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 27 100 7.2. Author's Organization - Differentiated Types of Mail . . . 27 101 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 27 102 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 28 103 7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 28 104 7.6. Independent Third Party Service Providers . . . . . . . . 28 105 7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 29 106 7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 29 107 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 30 108 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 30 109 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 31 110 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 31 111 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 32 112 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 34 113 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 35 114 9.1. Security Considerations . . . . . . . . . . . . . . . . . 35 115 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 117 11. Informative References . . . . . . . . . . . . . . . . . . . . 35 118 Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 37 119 A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 37 120 A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 40 121 Appendix B. General Coding Criteria for Cryptographic 122 Applications . . . . . . . . . . . . . . . . . . . . 41 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 125 1. Introduction 127 DomainKeys Identified Mail (DKIM) allows an organization to claim 128 responsibility for transmitting a message, in a way that can be 129 validated by a recipient. This document provides practical tips for: 130 those who are developing DKIM software, mailing list managers, 131 filtering strategies based on the output from DKIM verification, and 132 DNS servers; those who are deploying DKIM software, keys, mailing 133 list software, and migrating from DomainKeys; and those who are 134 responsible for the on-going operations of an email infrastructure 135 that has deployed DKIM. 137 The document is organized around the key concepts related to DKIM. 138 Within each section, additional considerations specific to 139 development, deployment, or ongoing operations are highlighted where 140 appropriate. 142 [[anchor2: MSK: maybe this is a good place to mention the possibility 143 of collecting verification history for selectors domains as a means 144 of observing over time behaviour of signers for the purpose of 145 asserting local reputation]] 147 2. Using DKIM as Part of Trust Assessment 149 2.1. A Systems View of Email Trust Assessment 151 DKIM participates in a trust-oriented enhancement to the Internet's 152 email service, to facilitate message handling decisions, such as for 153 delivery and for content display. Trust-oriented message handling 154 has substantial differences from approaches that consider messages in 155 terms of risk and abuse. With trust, there is a collaborative 156 exchange between a willing participant along the sending path and a 157 willing participant at the recipient site. In contrast, the risk 158 model entails independent action by the recipient site, in the face 159 of a potentially unknown, hostile and deceptive sender. This 160 translates into a very basic technical difference: In the face of 161 unilateral action by the recipient and even antagonistic efforts by 162 the sender, risk-oriented mechanisms must be based on heuristics, 163 that is, on guessing. Guessing produces statistical results with 164 some false negatives and some false positives. For trust-based 165 exchanges, the goal is the deterministic exchange of information. 166 For DKIM, that information is the one identifier that represents a 167 stream of mail for which an independent assessment is sought (by the 168 signer.) 170 A trust-based service is built upon a validated Responsible 171 Identifier that labels a stream of mail and is controlled by an 172 identity (role, person or organization.) The identity is 173 acknowledging some degree of responsibility for the message stream. 174 Given a basis for believing that an identifier is being used in an 175 authorized manner, the recipient site can make and use an assessment 176 of the associated identity. An identity can use different 177 identifiers, on the assumption that the different streams might 178 produce different assessments. For example, even the best-run 179 marketing campaigns will tend to produce some complaints that can 180 affect the reputation of the associated identifier. Whereas a stream 181 of transactional messages is likely to have a more pristine 182 reputation. 184 Determining that the identifier's use is valid is quite different 185 from determining that the content of a message is valid. The former 186 means only that the identifier for the responsible role, person or 187 organization has been legitimately associated with a message. The 188 latter means that the content of the message can be believed and, 189 typically, that the claimed author of the content is correct. DKIM 190 validates only the presence of the identifier used to sign the 191 message. Even when this identifier is validated, DKIM carries no 192 implication that any of the message content, including the 193 RFC5322.From field, is valid. Surprisingly, this limit to the 194 semantics of a DKIM signature applies even when the validated signing 195 identifier is the same domain name as is used in the From: field! 196 DKIM's only claim about message content is that the content cited in 197 the DKIM-Signature: field's h= tag have been delivered without 198 modification. That is, it asserts message content integrity, not 199 message content validity. 201 As shown in Figure 1, this enhancement is a communication between a 202 responsible role, person or organization that signs the message and a 203 recipient organization that assesses its trust in the signer and then 204 makes handling decisions based on a collection of assessments, of 205 which the DKIM mechanism is only a part. In this model, validation 206 is an intermediary step, having the sole task of passing a validated 207 Responsible Identifier to the Identity Assessor. The communication 208 is of a single Responsible Identifier that the Responsible Identity 209 wishes to have used by the Identity Assessor. The Identifier is the 210 sole, formal input and output value of DKIM signing. The Identity 211 Assessor uses this single, provided Identifier for consulting 212 whatever assessment data bases are deemed appropriate by the 213 assessing entity. In turn, output from the Identity Assessor is fed 214 into a Handling Filter engine that considers a range of factors, 215 along with this single output value; the range of factors can include 216 ancillary information from the DKIM validation. 218 Identity Assessment covers a range of possible functions. It can be 219 as simple as determining whether the identifier is a member of some 220 list, such as authorized operators or participants in a group that 221 might be of interest for recipient assessment. Equally, it can 222 indicate a degree of trust (reputation) that is to be afforded the 223 actor using that identifier. The extent to which the assessment 224 affects handling of the message is, of course, determined later, by 225 the Handling Filter. 227 +------+------+ +------+------+ 228 | Author | | Recipient | 229 +------+------+ +------+------+ 230 | ^ 231 | | 232 | +------+------+ 233 | -->| Handling |<-- 234 | -->| Filter |<-- 235 | +-------------+ 236 | ^ 237 V Responsible | 238 +-------------+ Identifier +------+------+ 239 | Responsible |. . . . . . . . . . .>| Identity | 240 | Identity | . . | Assessor | 241 +------+------+ . . +-------------+ 242 | . . ^ ^ 243 V . . | | 244 +------------------.-------.--------------------+ | | 245 | +------+------+ . . . . . +-------------+ | | | +-------------+ 246 | | Identifier | | Identifier +--|--+ +--+ Assessment | 247 | | Signer +------------->| Validator | | | Databases | 248 | +-------------+ +-------------+ | +-------------+ 249 | DKIM Service | 250 +-----------------------------------------------+ 252 Figure 1: Actors in a Trust Sequence using DKIM 254 2.2. Choosing a DKIM Tag for the Assessment Identifier 256 The signer of a message needs to be able to provide precise data and 257 know what that data will mean upon delivery to the Assessor. If 258 there is ambiguity in the choice that will be made on the receive 259 side, then the sender cannot know what basis for assessment will be 260 used. DKIM has three values that specify identification information 261 and it is easy to confuse their use, although only one defines the 262 formal input and output of DKIM, with the other two being used for 263 internal protocol functioning and adjunct purposes, such as auditing 264 and debugging. 266 The salient values include the s=, d= and i= parameters in the DKIM- 267 Signature: header field. In order to achieve the end-to-end 268 determinism needed for this collaborative exchange from the signer to 269 the assessor, the core model needs to specify that the signer MUST 270 provide the assessor with a single, opaque value that the signer 271 wishes to have used for assessment. This value MUST be the basis for 272 DKIM-based assessment. The signer MAY provide the assessor with a 273 second, opaque value that MAY be used when reporting problems with 274 the end-to-end DKIM process and MAY be used for additional analysis, 275 such as by the higher-level Handling Filter. These values are 276 opaque, in that any internal semantics are known only to the signer 277 and MUST NOT be assumed by the Assessor, within the confines of 278 DKIM's formal signing specification. Assessment MUST use a value as 279 a single, complete and uninterpreted string. 281 The single, mandatory value that DKIM supplies as its output is: 283 d= This specifies the "domain of the signing entity." It is a 284 domain name and is combined with the Selector to form a DNS 285 query. 287 The adjunct values are: 289 s= This tag specifies the Selector. It is used to discriminate 290 among different keys that can be used for the same d= domain 291 name. As discussed in Section 4.3 of [I-D.ietf-dkim-overview]: 292 "If verifiers were to employ the selector as part of a name 293 assessment mechanism, then there would be no remaining 294 mechanism for making a transition from an old, or compromised, 295 key to a new one." Consequently, the Selector is not 296 appropriate for use as part or all of the identifier used to 297 make assessments. 299 i= This tag is optional and provides the "[i]dentity of the 300 user or agent (e.g., a mailing list manager) on behalf of which 301 this message is signed." The identity can be in the syntax of 302 an entire email address or only a domain name. The domain name 303 can be the same as for d= or it can be a sub-name of the d= 304 name. 306 NOTE: Although the i= identity has the syntax of an email 307 address, it is not required to have that semantics. That is, 308 "the identity of the user" need not be the same as the user's 309 mailbox. For example the signer might wish to use i= to encode 310 user-related audit information, such as how they were accessing 311 the service at the time of message posting. Therefore it is 312 not possible to conclude anything from the i= string's 313 (dis)similarity to email addresses elsewhere in the header 315 So, i= can have any of these properties: 317 * Be a valid domain when it is the same as d= 319 * Appear to be a sub-domain of d= but might not even exist 321 * Look like a mailbox address but might have different semantics 322 and therefore not function as a valid email address 324 * Be unique for each message, such as indicating access details 325 of the user for the specific posting 327 This underscores why the tag needs to be treated as being opaque, 328 since it can represent any semantics, known only to the signer. 330 Hence, i= serves well as a token that is usable like an Web cookie, 331 for return to the signing ADMD -- such as for auditing and debugging. 332 Of course in some scenarios the i= string might provide a useful 333 adjunct value for additional (heuristic) processing by the Handling 334 Filter. 336 2.3. Choosing the Signing Domain Name 338 A DKIM signing entity can serve different roles, such as author of 339 content, versus operator of the mail service, versus operator of a 340 reputation service. In these different roles, the basis for 341 distinguishing among portions of email traffic can vary. For an 342 entity creating DKIM signatures it is likely that different portions 343 of their mail will warrant different levels of trust. For example: 345 * Mail is sent for different purposes, such as marketing vs. 346 transactional, and recipients demonstrate different patterns of 347 acceptance between these. 349 * For an operator of an email service, there often are distinct 350 sub-populations of users warranting different levels of trust 351 or privilege, such as paid vs. free users, or users engaged in 352 direct correspondence vs. users sending bulk mail. 354 * Mail originating outside an operator's system, such as when it 355 is redistributed by a mailing list service run by the operator, 356 will warrant a different reputation from mail submitted by 357 users authenticated with the operator. 359 It is therefore likely to be useful for a signer to use different d= 360 sub-domain names, for different message traffic streams, so that 361 receivers can make differential assessments. However, too much 362 differentiation -- that is, too fine a granularity of signing domains 363 -- makes it difficult for the receiver to discern a sufficiently 364 stable pattern of traffic for developing an accurate and reliable 365 assessment. So the differentiation needs to achieve a balance. 366 Generally in a trust system, legitimate signers have an incentive to 367 pick a small stable set of identities, so that recipients and others 368 can attribute reputations to them. The set of these identities a 369 receiver trusts is likely to be quite a bit smaller than the set it 370 views as risky. 372 The challenge in using additional layers of sub-domains is whether 373 the extra granularity will be useful for the assessor. In fact, 374 potentially excessive levels invites ambiguity: if the assessor does 375 not take advantage of the added granularity, then what granularity 376 will it use? That ambiguity would move the use of DKIM back to the 377 realm of heuristics, rather than the deterministic processing that is 378 its goal. 380 Hence the challenge is to determine a useful scheme for labeling 381 different traffic streams. The most obvious choices are among 382 different types of content and/or different types of authors. 383 Although stability is essential, it is likely that the choices will 384 change, over time, so the scheme needs to be flexible. 386 For those originating message content, the most likely choice of sub- 387 domain naming scheme will by based upon type of content, which can 388 use content-oriented labels or service-oriented labels. For example: 390 transaction.example.com 391 newsletter.example.com 392 bugreport.example.com 393 support.example.com 394 sales.example.com 395 marketing.example.com 397 where the choices are best dictated by whether they provide the 398 Identity Assessor with the ability to discriminate usefully among 399 streams of mail that demonstrate significantly different degrees of 400 recipient acceptance or safety. Again, the danger in providing too 401 fine a granularity is that related message streams that are labeled 402 separately will not benefit from an aggregate reputation. 404 For those operating messaging services on behalf of a variety of 405 customers, an obvious scheme to use has a different sub-domain label 406 for each customer. For example: 408 widgetco.example.net 409 moviestudio.example.net 410 bigbank.example.net 412 However it can also be appropriate to label by the class of service 413 or class of customer, such as: 415 premier.example.net 416 free.example.net 417 certified.example.net 419 Prior to using domain names for distinguishing among sources of data, 420 IP Addresses have been the basis for distinction. Service operators 421 typically have done this by dedicating specific outbound IP Addresses 422 to specific mail streams -- typically to specific customers. For 423 example, a university might want to distinguish mail from the 424 Administration, versus mail from the student dorms. In order to make 425 adoption of a DKIM-based service easier, it can be reasonable to 426 translate the same partitioning of traffic, using domain names in 427 place of the different IP Addresses. 429 2.4. Recipient-based Assessments 431 DKIM gives the recipient site's Identity Assessor a verifiable 432 identifier to use for analysis. Although the mechanism does not make 433 claims that the signer is a Good Actor or a Bad Actor, it does make 434 it possible to know that use of the identifier is valid. This is in 435 marked contrast with schemes that do not have authentication. 436 Without verification, it is not possible to know whether the 437 identifier -- whether taken from the RFC5322.From field, 438 RFC5321.MailFrom command, or the like -- is being used by an 439 authorized agent. DKIM solves this problem. Hence with DKIM, the 440 Assessor can know that two messages with the same DKIM d= identifier 441 are, in fact, signed by the same person or organization. This 442 permits a far more stable and accurate assessment of mail traffic 443 using that identifier. 445 DKIM is distinctive, in that it provides an identifier which is not 446 necessarily related to any other identifier in the message. Hence, 447 the signer might be the author's ADMD, one of the operators along the 448 transit path, or a reputation service being used by one of those 449 handling services. In fact, a message can have multiple signatures, 450 possibly by different of these actors. 452 As discussed above, the choice of identifiers needs to be based on 453 differences that the signer thinks will be useful for the recipient 454 Assessor. Over time, industry practices establish norms for these 455 choices. 457 Absent such norms, it is best for signers to distinguish among 458 streams that have significant differences, while consuming the 459 smallest number of identifiers possible. This will limit the 460 burden on recipient Assessors. 462 A common view about a DKIM signature is that it carries a degree of 463 assurance about some or all of the message contents, and in 464 particular that the RFC5322.From field is likely to be valid. In 465 fact, DKIM makes assurances only about the integrity of the data and 466 not about its validity. Still, presumptions of From: field validity 467 remain a concern. Hence a signer using a domain name that is 468 unrelated to the domain name in the From: field can reasonably expect 469 that the disparity will warrant some curiosity, at least until 470 signing by independent operators has produced some established 471 practice among recipient Assessors. 473 2.5. Filtering 475 After assessing the signer of a message, each receiving site creates 476 and tunes its own Handling Filter according to criteria specific for 477 that site. Still, there are commonalities across sites, and this 478 section offers a discussion, rather than a specification, of some 479 types of input to that process and how they can be used. 481 The discussion focuses on variations in Organizational Trust versus 482 Message Risk. That is, the degree of positive assessment of a DKIM- 483 signing organization, and the potential danger present in the message 484 stream signed by that organization. While it might seem that higher 485 trust automatically means lower risk, the experience with real-world 486 operations provides examples of every combination of the two factors, 487 as shown in Table 1. Only 3 levels of granularity are listed, in 488 order to keep discussion manageable. This also ensures extensive 489 flexibility for each site's detailed choices. 491 +---+---------------------+--------------------+--------------------+ 492 | | Low | Medium | High | 493 | | | | | 494 | | | | | 495 | | | | | 496 | | | | | 497 | O | | | | 498 | R | | | | 499 | G | | | | 500 | | | | | 501 | T | | | | 502 | R | | | | 503 | U | | | | 504 | S | | | | 505 | T | | | | 506 | | | | | 507 | M | | | | 508 +---+---------------------+--------------------+--------------------+ 509 | * | Unknown org, | Registered org, | Good Org, | 510 | L | Few msgs: | New Identifier: | Good msgs: | 511 | o | _Mild filtering_ | _Medium filtering_ | _Avoid FP(!)_ | 512 | w | | | | 513 | * | Unknown org, | Registered org, | Good org, Bad msg | 514 | M | New Identifier: | Mixed msgs: | burst: | 515 | e | _Default filtering_ | _Medium filtering_ | _Accept & Contact_ | 516 | d | | | | 517 | i | | | | 518 | u | | | | 519 | * | Black-Listed org, | Registered org, | Good org, | 520 | H | Bad msgs: | Bad msgs: | Compromised: | 521 | i | _Avoid FN(!)_ | _Strong filtering_ | _Fully blocked_ | 522 | g | | | | 523 | h | | | | 524 +---+---------------------+--------------------+--------------------+ 526 Table 1: Organizational Trust vs. Message Risk 528 The table indicates preferences for different handling of different 529 combinations, such as tuning filtering to avoid False Positives (FP) 530 or avoiding False Negatives (FN). Perhaps unexpectedly, it also 531 lists a case in which the receiving site might wish to deliver 532 problematic mail, rather than redirecting it, but also of course 533 contacting the signing organization, seeking resolution of the 534 problem. 536 3. DKIM Key Generation, Storage, and Management 538 By itself, verification of a digital signature only allows the 539 verifier to conclude with a very high degree of certainty that the 540 signature was created by a party with access to the corresponding 541 private signing key. It follows that a verifier requires means to 542 (1) obtain the public key for the purpose of verification and (2) 543 infer useful attributes of the key holder. 545 In a traditional Public Key Infrastructure (PKI), the functions of 546 key distribution and key accreditation are separated. In DKIM, these 547 functions are both performed through the DNS [RFC4871] (Allman, E., 548 Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, 549 "DomainKeys Identified Mail (DKIM) Signatures," May 2007.). 551 In either case, the ability to infer semantics from a digital 552 signature depends on the assumption that the corresponding private 553 key is only accessible to a party with a particular set of 554 attributes. In traditional PKI a Trusted Third Party (TTP) vouches 555 that the key holder has been validated with respect to a specified 556 set of attributes. The range of attributes that may be attested in 557 such a scheme is thus limited only to the type of attributes that a 558 TTP can establish effective processes for validating. 560 In DKIM, TTPs are not employed and the functions of key distribution 561 and accreditation are combined. Consequently there are only two 562 types of inference that a signer may make from a key published in a 563 DKIM Key Record: 565 1. That a party with the ability to control DNS records within a DNS 566 zone intends to claim responsibility for messages signed using 567 the corresponding private signature key. 569 2. That use of a specific key is restricted to a particular subset 570 of messages. 572 The ability to draw any useful conclusion from verification of a 573 digital signature relies on the assumption that the corresponding 574 private key is only accessible to a party with a particular set of 575 attributes. In the case of DKIM, this means that the party that 576 created the corresponding DKIM key record in the specific zone 577 intended to claim responsibility for the signed message. 579 Ideally we would like to draw a stronger conclusion, that if we 580 obtain a DKIM key record from the DNS zone example.com, that the 581 legitimate holder of the DNS zone example.com claims responsibility 582 for the signed message. In order for this conclusion to be drawn it 583 is necessary for the verifier to assume that the operational security 584 of the DNS zone and corresponding private key are adequate. 586 3.1. Private Key Management: Deployment and Ongoing Operations 588 Access to signing keys must be carefully managed to prevent use by 589 unauthorized parties and to minimize the consequences should a 590 compromise occur. 592 While a DKIM signing key is used to sign messages on behalf of many 593 mail users, the signing key itself should be under direct control of 594 as few key-holders as possible. Should a key-holder leave the 595 organization, all signing keys held by that key holder should be 596 withdrawn from service and if appropriate, replaced. 598 If key management hardware support is available, it should be used. 599 If keys are stored in software, sppropriate file control protections 600 must be employed and any location in which the private key is stored 601 in plaintext form should be excluded from regular backup processes 602 and should not be accessible through any form of network including 603 private local area networks. Auditing software should be used 604 periodically to verify that the permissions on the private key files 605 remain secure. 607 Wherever possible a signature key should exist in exactly one 608 location and be erased when no longer used. Ideally a signature key 609 pair should be generated as close to the signing point as possible 610 and only the public key component transferred to another party. If 611 this is not possible, the private key MUST be transported in an 612 encrypted format that protects the confidentiality of the signing 613 key. A shared directory on a local file system does not provide 614 adequate security for distribution of signing keys in plaintext form. 616 Key escrow schemes are not necessary and should not be used. In the 617 unlikely event of a signing key becomming lost, a new signature key 618 pair may be generated as easily as recovery from a key escrow scheme. 620 Responsibility for the security of a signing key should ultimately 621 vest in a single named individual. Where multiple parties are 622 authorized to sign messages, each signer should use a different key 623 to enable accountability and auditing. 625 Best practices for management of cryptographic keying material 626 require keying material to be refreshed at regular intervals, 627 particular where key management is achieved through software. While 628 this practice is highly desirable it is of considerably less 629 importance than the requirement to maintain the secrecy of the 630 corresponding private key. An operational practice in which the 631 private key is stored in tamper proof hardware and changed once a 632 year is considerably more desirable than one in which the signature 633 key is changed on an hourly basis but maintained in software. 635 3.2. Storing Public Keys: DNS Server Software Considerations 637 In order to use DKIM a DNS domain holder requires (1) the ability to 638 create the necessary DKIM DNS records and (2) sufficient operational 639 security controls to prevent insertion of spurious DNS records by an 640 attacker. 642 DNS record management is usually operated by an administrative staff 643 that is different from those who operate an organization's email 644 service. In order to ensure that DKIM DNS records are accurate, this 645 imposes a requirement for careful coordination between the two 646 operations groups. If the best practices for private key management 647 described above are observed, such deployment is not a one time 648 event, DNS DKIM selectors will be changed over time signing keys are 649 terminated and replaced. 651 At a minimum, a DNS server that handles queries for DKIM key records 652 must allow the server administrators to add free-form TXT records. 653 It would be better if the the DKIM records could be entered using a 654 structured form, supporting the DKIM-specific fields. 656 Ideally DNSSEC [] should be employed in a configuration that provides 657 protection against record insertion attacks and zone enumeration. In 658 the case that NSEC3 [RFC 5155] records are employed to prevent 659 insertion attack, the OPT-OUT flag must be set clear. 661 3.2.1. Assignment of Selectors 663 Selectors are assigned according to the administrative needs of the 664 signing domain, such as for rolling over to a new key or for 665 delegating of the right to authenticate a portion of the namespace to 666 a trusted third party. Examples include: 668 jun2005.eng._domainkey.example.com 670 widget.promotion._domainkey.example.com 672 It is intended that assessments of DKIM identities be based on the 673 domain name, and not include the selector. While past practice of a 674 signer may permit a verifier to infer additional properties of 675 particular messages from the structure DKIM key selector, unannounced 676 administrative changes such as a change of signing softeware may 677 cause such heuristics to fail at any time. 679 3.3. Per User Signing Key Management Issues 681 While a signer may establish business rules, such as issue of 682 individual signature keys for each end-user, DKIM makes no provision 683 for communicating these to other parties. Out of band distribution 684 of such business rules is outside the scope of DKIM. Consequently 685 there is no means by which external parties may make use of such keys 686 to attribute messages with any greater granularity than a DNS domain. 688 If per-user signing keys are assigned for internal purposes (e.g. 689 authenticating messages sent to an MTA for distribution), the 690 following issues need to be considered before using such signatures 691 as an alternative to traditional edge signing at the outbound MTA: 693 External verifiers will be unable to make use of the additional 694 signature granularity without access to additional information 695 passed out of band with respect to DKIM-base. 697 If the number of user keys is large, the efficiency of local 698 caching of key records by verifiers will be lower. 700 A large number of end users may be less likely to be able to 701 manage private key data securely on their personal computer than 702 an administrator running an edge MTA. 704 3.4. Third Party Signer Key Management and Selector Administration 706 A DKIM key record only asserts that the holder of the corresponding 707 domain name makes a claim of responsibility for messages signed under 708 the corresponding key. In some applications, such as bulk mail 709 delivery it is desirable to delegate the ability to make a claim of 710 responsibility to another party. In this case the trust relationship 711 is established between the domain holder and the verifier but the 712 private signature key is held by a third party. 714 Signature keys used by a third party signer should be kept entirely 715 separate from those used by the domain holder and other third party 716 signers. As with any other private key, the signature key pair 717 should be generated by the third party signer and the public 718 component of the key transmitted to the domain holder rather than 719 have the domain holder generate the key pair and transmit the private 720 component to the third party signer. 722 Domain holders should adopt a least privilege approach and grant 723 third party signers the minimum access necessary to perform the 724 desired function. Limiting the access granted to Third Party Signers 725 serves to protect the interests of both parties. The domain holder 726 minimizes their security risk and the Trusted Third Party Signer 727 avoids unnecessary liability. 729 In the most restrictive case a domain holder maintains full control 730 over the creation of key records and employ appropriate key record 731 restrictions to enforce restrictions on the messages for which the 732 third party signer is able to sign. If such restrictions are 733 impractical, the domain holder should delegate a DNS subzone for 734 publishing key records to the third party signer. The domain holder 735 should not allow a third party signer unrestricted access to their 736 DNS service for the purpose of publishing key records. 738 3.5. Key Pair / Selector Lifecycle Management 740 Deployments should establish, document and observe processes for 741 managing the entire lifecycle of a public key pair. 743 3.5.1. Example Key Deployment Process 745 When it is determined that a new key pair is required: 747 1. A Key Pair is generated by the signing device 749 2. A proposed key selector record is generated and transmitted to 750 the DNS administration infrasrtructure. 752 3. The DNS administration infrastructure verifies the authenticity 753 of the key selector registration request. If accepted 755 1. A key selector is assigned. 757 2. The corresponding key record published in the DNS. 759 3. Wait for DNS updates to propagate (if necessary). 761 4. Report assigned key selector to signing device. 763 4. Signer verifies correct registration of the key record. 765 5. Signer begins generating signatures using the new key pair. 767 6. Signer terminates any private keys that are no longer required 768 due to issue of replacement. 770 3.5.2. Example Key Termination Process 772 When it is determined that a private signature key is no longer 773 required: 775 1. Signer stops using the private key for signature operations. 777 2. Signer deletes all records of the private key, including in- 778 memory copies at the signing device. 780 3. Signer notifies the DNS administration infrasrtructure that the 781 signing key is withdrawn from service and that the corresponding 782 key records may be withdrawn from service at a specified future 783 date. 785 4. The DNS administration infrastructure verifies the authenticity 786 of the key selector termination request. If accepted 788 1. The key selector is scheduled for deletion at a future time 789 determined by site policy. 791 2. Wait for deletion time to arrive 793 3. The key selector is deleted 795 4. Signing 797 Creating messages that have one or more DKIM signatures, requires 798 support in only two outbound email service components: 800 o A DNS Administrative interface that can create and maintain the 801 relevant DNS names -- including names with underscores -- and 802 resource records (RR). 804 o A trusted module, called the Signing Module, which is within the 805 organization's outbound email handling service and which creates 806 and adds the DKIM-Signature: header field(s) to the message. 808 If the module creates more than one signature, there needs to be the 809 appropriate means of telling it which one(s) to use. If a large 810 number of names is used for signing, it will help to have the 811 administrative tool support a batch processing mode. 813 4.1. DNS Records 815 A receiver attempting to verify a DKIM signature obtains the public 816 key that is associated with the signature for that message. The 817 DKIM-Signature: header in the message contains the d= tag with the 818 basic domain name doing the signing and serving as output to the 819 Identity Assessor, and the s= tag with the selector that is added to 820 the name, for finding the specific public key. Hence, the relevant 821 ._domainkey. DNS record needs to contain a 822 DKIM-related RR that provides the public key information. 824 The administrator of the zone containing the relevant domain name 825 adds this information. Initial DKIM DNS information is contained 826 within TXT RRs. DNS administrative software varies considerably in 827 its abilities to support DKIM names, such as with underscores, and to 828 add new types of DNS information. 830 4.2. Signing Module 832 The module doing signing can be placed anywhere within an 833 organization's trusted Administrative Management Domain (ADMD); 834 obvious choices include department-level posting agents, as well as 835 outbound boundary MTAs to the open Internet. However any other 836 module, including the author's MUA, is potentially acceptable, as 837 long as the signature survives any remaining handling within the 838 ADMD. Hence the choice among the modules depends upon software 839 development, administrative overhead, security exposures and transit 840 handling tradeoffs. One perspective that helps to resolve this 841 choice is the difference between the increased flexibility, from 842 placement at (or close to) the MUA, versus the streamlined 843 administration and operation, that is more easily obtained by 844 implementing the mechanism "deeper" into the organization's email 845 infrastructure, such as at its boundary MTA. 847 Note the discussion in Section 2.2, concerning use of the i= tag. 849 The signing module uses the appropriate private key to create one or 850 more signatures. The means by which the signing module obtains the 851 private key(s) is not specified by DKIM. Given that DKIM is intended 852 for use during email transit, rather than for long-term storage, it 853 is expected that keys will be changed regularly. For administrative 854 convenience, key information should not be hard-coded into software. 856 4.3. Signing Policies and Practices 858 Every organization (ADMD) will have its own policies and practices 859 for deciding when to sign messages (message stream) and with what 860 domain name, selector and key. Examples of particular message 861 streams include all mail sent from the ADMD, versus mail from 862 particular types of user accounts, versus mail having particular 863 types of content. Given this variability, and the likelihood that 864 signing practices will change over time, it will be useful to have 865 these decisions represented through run-time configuration 866 information, rather than being hard-coded into the signing software. 868 As noted in Section 2.3, the choice of signing name granularity 869 requires balancing administrative convenience and utility for 870 recipients. Too much granularity is higher administrative overhead 871 and well might attempt to impose more differential analysis on the 872 recipient than they wish to support. In such cases, they are likely 873 to use only a super-name -- right-hand substring -- of the signing 874 name. When this occurs, the signer will not know what portion is 875 being used; this then moves DKIM back to the non-deterministic world 876 of heuristics, rather than the mechanistic world of signer/recipient 877 collaboration that DKIM seeks. 879 5. Verifying 881 To be added. 883 6. Taxonomy of Signatures 885 A DKIM signature tells the signature verifier that the owner of a 886 particular domain name accepts some responsibility for the message. 887 It does not, in and of itself, provide any information about the 888 trustworthiness or behavior of that identity. What it does provide 889 is a verified identity to which such behavioral information can be 890 associated, so that those who collect and use such information can be 891 assured that it truly pertains to the identity in question. 893 This section lays out a taxonomy of some of the different identities, 894 or combinations of identities, that might usefully be represented by 895 a DKIM signature. 897 6.1. Single Domain Signature 899 Perhaps the simplest case is when an organization signs its own 900 outbound email using its own domain in the d= tag of the signature. 901 For example, Company A would sign the outbound mail from its 902 employees with d=companyA.example. 904 In the most straightforward configuration, the addresses in the RFC 905 5322 From would also be in the companyA.example domain, but that 906 direct correlation is not required. 908 A special case of the Single Domain Signature is an Author Signature 909 as defined by the Author Domain Signing Practices specification. 910 Author signatures are signatures from an authors organization that 911 have an i= value that matches the From: address of the message. 912 Under the ADSP specification, an i= value matches a RFC 5322 From 913 address when the domains of the two match exactly, and if the i= 914 value contains a local part it also matches the local part of the 915 From: address exactly. 917 Although an author signature might in some cases be proof against 918 domain name spoofing the RFC 5322 From address, it is important to 919 note that the DKIM and ADSP validation apply only to the exact 920 address string and not to look-alike addresses nor to the human- 921 friendly "display-name" or names and addresses used within the body 922 of the message. That is, it protects only against the misuse of a 923 precise address string within the RFC5322 From field and nothing 924 else. For example, a message from bob@domain.example with a valid 925 signature where i=d0main.example would fail an ADSP check because the 926 signature domain, however similar, is distinct; however a message 927 from bob@d0main.example with a valid signature where i=d0main.example 928 would pass an ADSP check, even though to a human it might be obvious 929 that d0main.example is likely a malicious attempt to spoof the domain 930 domain.example. This example highlights that ADSP, like DKIM, is 931 only able to validate a signing identifier: it still requires some 932 external process to attach a meaningful reputation to that 933 identifier. 935 6.2. Parent Domain Signature 937 Another approach that might be taken by an organization with multiple 938 active subdomains is to apply the same (single) signature to mail 939 from all subdomains. In this case, the signature chosen would 940 usually be the signature of a parent domain common to all subdomains. 941 For example, mail from marketing.domain.example, 942 sales.domain.example, and engineering.domain.example might all use a 943 signature with d=domain.example. 945 This approach has the virtue of simplicity, but it is important to 946 consider the implications of such a choice. As discussed in 947 Section 2.3, if the type of mail sent from the different subdomains 948 is significantly different or if there is reason to believe that the 949 reputation of the subdomains would differ, then it may be a good idea 950 to acknowledge this and provide distinct signatures for each of the 951 subdomains (d=marketing.domain.example, sales.domain.example, etc.). 952 However, if the mail and reputations are likely to be similar, then 953 the simpler approach of using a single common parent domain in the 954 signature may work well. 956 Another approach to distinguishing the streams using a single DKIM 957 key would be to leverage the i= tag in the DKIM signature to 958 differentiate the mail streams. For example, marketing email would 959 be signed with i=marketing.domain.example and d=domain.example. 961 It's important to remember, however, that under core DKIM semantics 962 the i= identifer is opaque to receivers. That means that it will 963 only be an effective differentiator if there is an out of band 964 agreement about the i= semantics (e.g., the semantics specified in 965 ADSP). 967 6.3. Third Party Signature 969 A signature whose domain does not match the domain of the RFC 5322 970 From address is sometimes referred to as a third party signature. In 971 certain cases even the parent domain signature described above would 972 be considered a third party signature because it would not be an 973 exact match for the domain in the From: address. 975 Although there is often heated debate about the value of third-party 976 signatures, it is important to note that the DKIM specification 977 attaches no particular significance to the identity in a DKIM 978 signature. The identity specified within the signature is the 979 identity that is taking responsibility for the message, and it is 980 only the interpretation of a given receiver that gives one identity 981 more or less significance than another. In particular, most 982 independent reputation services assign trust based on the specific 983 identifier string, not its "role": in general they make no 984 distinction between, for example, an author signature and a third 985 party signature. 987 For some, a signature unrelated to the author (identity in the RFC 988 5322 From address) is less valuable because there is an assumption 989 that the presence of an author signature guarantees that the use of 990 the address in the From: header is authorized. 992 For others, that relevance is tied strictly to the recorded 993 behavioral data assigned to the identity in question, i.e. its trust 994 assessment or reputation. The reasoning here is that an identity 995 with a good reputation is unlikely to maintain that good reputation 996 if it is in the habit of vouching for messages that are unwanted or 997 abusive; in fact, doing so will rapidly degrade its reputation so 998 that future messages will no longer benefit from it. It is therefore 999 low risk to facilitate the delivery of messages that contain a valid 1000 signature of a domain with a strong positive reputation, independent 1001 of whether or not that domain is associated with the address in the 1002 RFC5322 From header field of the message. 1004 Third party signatures encompass a wide range of identities. Some of 1005 the more common are: 1007 Service Provider: In cases where email is outsourced to an Email 1008 Service Provider (ESP), Internet Service Provider (ISP), or other 1009 type of service provider, that service provider may choose to DKIM 1010 sign outbound mail with either its own identifier -- relying on 1011 its own, aggregate reptutation -- or with a subdomain of the 1012 provider that is unique to the message author but still part of 1013 the provider's aggregate reputation. Such service providers may 1014 also encompass delegated business functions such as benefit 1015 management, although these will more often be treated as trusted 1016 third party senders (see below). 1018 Parent Domain. As discussed above, organizations choosing to sign 1019 for mail originating from subdomains with a parent domain 1020 signature may also considered to be using 3rd party signatures in 1021 some configurations, depending on whether or not the "t=s" tag is 1022 used to constrain the parent signature to apply to only its own 1023 specific domain. The default is that a parent domain signature is 1024 considered valid for its subdomains. 1026 Reputation Provider: Another possible category of third party 1027 signature would be the identity of a 3rd party reputation 1028 provider. Such a signature would indicate to receivers that the 1029 message was being vouched for by that 3rd party. 1031 6.4. Using Trusted 3rd Party Senders 1033 For most of the cases described so far, there has been an assumption 1034 that the identity doing the signing was responsible for creating and 1035 maintaining their own DKIM signing infrastructure, including their 1036 own keys, and signing with their own identity. 1038 A different model arises when an organization uses a trusted third 1039 party sender for certain key business functions, but still wants that 1040 email to benefit from the organization's own identity and reputation: 1041 in other words, the mail would come out of the trusted 3rd party's 1042 mail servers, but the signature applied would be that of the 1043 controlling organization. 1045 This can be done by having the 3rd party generate a key pair that is 1046 designated uniquely for use by that trusted 3rd party and publishing 1047 the public key in the controlling organization's DNS domain, thus 1048 enabling the third party to sign mail using the signature of the 1049 controlling organization. For example, if Company A outsources its 1050 employee benefits to a 3rd party, they can use a special keypair that 1051 enables the benefits company to sign mail as "companyA.example". 1052 Because the keypair is unique to that trusted 3rd party, it is easy 1053 for Company A to revoke the authorization if necessary by simply 1054 removing the public key from the companyA.example DNS. 1056 In this scenario, it is usually a good idea to limit the specific 1057 identities that can be used by even trusted third parties. The DKIM 1058 g= tag enables a key record to specify one particular From: address 1059 local part that must be specified in the i= tag of the signature: for 1060 example, "g=benefits" would require a signature header tag of 1061 "i=benefits@companyA.example". It is important to note that although 1062 this distinction will be clear to the verifier it may be invisible to 1063 the recipient: there is no constraint within the DKIM verification 1064 process that constrains that specific i= value to correspond to any 1065 of the other message headers. 1067 A more reliable way of distinguishing the third part mail stream 1068 would be to create a dedicated subdomain (e.g. 1069 benefits.companyA.example) and publish the public key there; the 1070 signature would then use d=benefits.companyA.example. 1072 6.4.1. DNS Delegation 1074 Another possbility for configuring trusted third party access is to 1075 have Company A use DNS delegation and have the designated subdomain 1076 managed directly by the trusted third party. In this case, Company A 1077 would create a subdomain benefits.companya.example, and delegate the 1078 DNS management of that subdomain to the benefits company so it could 1079 maintain its own key records. Should revocation become necessary, 1080 Company A could simply remove the DNS delegation record. 1082 6.5. Multiple Signatures 1084 A simple configuration for DKIM-signed mail is to have a single 1085 signature on a given message. This works well for domains that 1086 manage and send all of their own email from a single source, or for 1087 cases where multiple email streams exist but each has its own unique 1088 key pair. It also represents the case in which only one of the 1089 participants in an email sequence is able to sign, no matter whether 1090 they represent the author or one of the operators. 1092 The examples thus far have considered the implications of using 1093 different identities in DKIM signatures, but have used only one such 1094 identity for any given message. In some cases, it may make sense to 1095 have more than one identity claiming responsiblity for the same 1096 message. 1098 One important caveat to the use of multiple signatures is that there 1099 is currently no clear consensus amoung receivers on how they plan to 1100 handle them. The opinions range from ignoring all but one signature 1101 (and the specification of which of them is verified differs from 1102 receiver to receiver), to verifying all signatures present and 1103 applying a weighted blend of the trust assessments for those 1104 identifiers, to verifying all signatures present and simply using the 1105 identfier that represents the most positive trust assessment. It is 1106 likely that the industry will evolve to accept multiple signatures 1107 using either option two or three, but it may take some time before 1108 that approach becomes pervasive. 1110 There are a number of situations where applying more than one DKIM 1111 signature to the same message might make sense. A few examples are: 1113 Companies with multiple subdomain identities: A company that has 1114 multiple subdomain sending distinct categories of mail might 1115 choose to sign with distinct subdomain identities to enable each 1116 subdomain to manage its own identity. However, it might also want 1117 to provide a common identity that cuts across all of the distinct 1118 subdomains. For example, Company A may sign mail for its sales 1119 department with a signature where d=marketing.companya.example, 1120 and a second signature where d=companya.example 1122 Service Providers: Service providers may, as described above, choose 1123 to sign outbound messages with either their own identity or with 1124 an identity unique to each of their clients (possibly delegated). 1125 However, they may also do both: sign each outbound message with 1126 their own identity as well as the identity of each individual 1127 client. For example, ESP A might sign mail for their client 1128 Company B with their service provider signature d=espa.example, 1129 and a second client-specific signature where d= either 1130 companyb.example, or companyb.espa.example. The existence of the 1131 service provider signature could, for example, help cover a new 1132 client while they establish their own reputation, or help a very 1133 small volume client who might never reach a volume threshold 1134 sufficient to establish an individual reputation. 1136 Forwarders Forwarded mail poses a number of challenges to email 1137 authentication. DKIM is relatively robust in the presence of 1138 forwarders as long as the signature is designed to avoid message 1139 parts that are likely to be modified, although some forwarders do 1140 make modifications that can invalidate a DKIM signature. 1142 However, some forwarders such as mailing lists or forward article 1143 to a friend services, might choose to add their own signature to 1144 outbound messages to vouch for it having legitimately originated 1145 from the designated service. In this case, the signature would be 1146 added even in the presence of a pre-existing signature, and both 1147 signatures would be relevant to the verifier. 1149 Any forwarder that modifies messages in ways that will break pre- 1150 existing DKIM signatures should always sign its forwarded 1151 messages. 1153 Reputation Providers: Although third party reputation providers 1154 today use a variety of protocols to communicate their information 1155 to receivers, it is possible that they, or other organizations 1156 willing to put their "seal of approval" on an email stream might 1157 choose to use a DKIM signature to do it. In nearly all cases, 1158 this "reputation" signature would be in addition to the author or 1159 originator signature. 1161 7. Example Usage Scenarios 1163 Signatures are created by different types of email actors, based on 1164 different criteria, such as where the actor operates in the sequence 1165 from author to recipient, whether they want different messages to be 1166 evaluated under the same reputation or different, and so on. This 1167 section provides some examples of usage scenarios for DKIM 1168 deployments; the selection is not intended to be exhaustive, but to 1169 illustrate a set of key deployment considerations. 1171 7.1. Author's Organization - Simple 1173 The simplest DKIM configuration is to have all mail from a given 1174 organization (Company A) be signed with the same d= value (e.g. 1175 d=companya.example). If there is a desire to associate a user 1176 identity or some other related information, the i= value can become 1177 uniqueID@companya.example, or uniqueID.companya.example. 1179 In this scenario, Company A need only generate a single signing key 1180 and publish it under their top level domain (companya.example); the 1181 signing module would then tailor the i= value as needed at signing 1182 time. 1184 7.2. Author's Organization - Differentiated Types of Mail 1186 A slight variation of the one signature case is where Company A signs 1187 all of its mail, but it wants to differentiate different categories 1188 of its outbound mail by using different identifiers. For example, it 1189 might choose to distinguish marketing mail, billing or transactional 1190 mail, and individual corporate email into marketing.companya.example, 1191 billing.companya.example, and companya.example, where each category 1192 is assigned a unique subdomain and unique signing keys. 1194 7.3. Author Signature 1196 As discussed in Section 6.1, author signatures are a special case of 1197 signatures from an authors organization where at least one signature 1198 on the message has an i= value that matches the From: address of the 1199 message. 1201 Signers wishing to publish an ADSP record describing their signing 1202 practices will want to include an author signature on their outbound 1203 mail to avoid ADSP verification failures. For example, if the 1204 address in the RFC 5322 From is bob@company.example, the d= value of 1205 the author signature would be company.example, and the i= value would 1206 be either company.example or bob@company.example. 1208 7.4. Author Domain Signing Practices 1210 To be added. 1212 7.5. Delegated Signing 1214 An organization may choose to outsource certain key services to third 1215 party companies. For example, Company A might outsource its benefits 1216 management, or Organization B might outsource its marketing email. 1218 If Company A wants to ensure that all of the mail sent on its behalf 1219 through the benefits providers email servers shares the Company A 1220 reputation, as discussed in Section 6.4 it can either publish keys 1221 designated for the use of the benefits provider under 1222 companyA.example (preferably under a designated subdomain of 1223 companyA.example), or they can delegate a subdomain (e.g. 1224 benefits.companyA.example) to the provider and enable the provider to 1225 generate the keys and manage the DNS for the designated subdomain. 1227 In both of these cases, mail would be physically going out of the 1228 benefit provider's mail servers with a signature of e.g. 1229 d=benefits.companya.example. Note that the From: address is not 1230 constrained: it could either be affiliated with the benefits company 1231 (e.g. benefits-admin@benefitprovider.example, or 1232 benefits-provider@benefits.companya.example). 1234 Note that in both of the above scenarios, security concerns dictate 1235 that the keys be generated by the organization that plans to do the 1236 signing so that there is no need to transfer the private key. In 1237 other words, the benefits provider would generate keys for both of 1238 the above scenarios. 1240 7.6. Independent Third Party Service Providers 1242 Another way to manage the service provider configuration would be to 1243 have the service provider sign the outgoing mail on behalf of its 1244 client Company A with its own (provider) identifier. For example, an 1245 Email Service Provider (ESP A) might want to share its own mailing 1246 reputation with its clients, and may sign all outgoing mail from its 1247 clients with its own d= domain (e.g. d=espa.example). 1249 Should the ESP want to distinguish among its clients, it has two 1250 options: 1252 Share the d= domain and use the i= value to distinguish among the 1253 clients: e.g. a signature on behalf of client A would have 1254 d=espa.example and i=clienta.espa.example (or 1255 i=clienta@espa.example) 1257 Extend the d= domain so there is a unique value (and subdomain) for 1258 each client: e.g. a signature on behalf of client A would have 1259 d=clienta.espa.example. 1261 Note that this scenario and the delegation scenario are not mutually 1262 exclusive: in some cases, it may be desirable to sign the same 1263 message with both the ESP and the ESP client identities. 1265 7.7. Mail Streams Based on Behavioral Assessment 1267 An ISP (ISP A) might want to assign signatures to outbound mail from 1268 their users according to the users past sending behavior 1269 (reputation). Since the semantics of behavioral assessments arent 1270 allowed as i= values, ISP A (ispa.example) would have to configure 1271 subdomains corresponding the assessment categories (e.g. 1272 good.ispa.example, neutral.ispa.example, bad.ispa.example), and use 1273 these domains as the d= value of the signature. 1275 The signing module can also optionally set the i= value to have a 1276 unique user id (distinct from the users email address local part), 1277 for example user3456@neutral.domain.example. Using a userid that is 1278 distinct from a given email alias is useful in environments where a 1279 single user might register multiple email aliases. 1281 Note that in this case the i= values are only partially stable. They 1282 are stable in the sense that a given i= value will always represent 1283 the same identity, but they are unstable in the sense that a given 1284 user can migrate among the assessment subdomains depending on their 1285 sending behavior (i.e., the same user might have multiple i= values 1286 over the lifetime of their account). 1288 In this scenario, ISP A would have to generate as many keys as there 1289 are assessment subdomains (d= values), so that each assessment 1290 subdomain had its own key. The signing module would then choose its 1291 signing key based on the assessment of the user whose mail was being 1292 signed, and if desired include the user id in the i= tag of the 1293 signature. 1295 7.8. Agent or Mediator Signatures 1297 Another scenario is that of an agent, usually a re-mailer of some 1298 kind, that signs on behalf of the service or organization that it 1299 represents. Some examples of agents might be a mailing list manager, 1300 or the "forward article to a friend" service that many online 1301 publications offer. In most of these cases, the signature is 1302 asserting that the message originated with, or was relayed by, the 1303 service asserting responsibility. 1305 8. Usage Considerations 1307 8.1. Non-standard Submission and Delivery Scenarios 1309 The robustness of DKIM's verification mechanism is based on the fact 1310 that only authorized signing modules have access to the designated 1311 private key. This has the side effect that email submission and 1312 delivery scenarios that originate or relay messages from outside the 1313 domain of the authorized signing module will not have access to that 1314 protected private key, and thus will be unable to attach the expected 1315 domain signature to those messages. Such scenarios include mailing 1316 lists, courtesy forwarders, MTAs at hotels, hotspot networks used by 1317 travelling users, and other paths that could add or modify headers, 1318 or modify the message body. 1320 For example, assume Joe works for Company A and has an email address 1321 joe@companya.example. Joe also has a GMail account joe@gmail.com, 1322 and he uses GMails multiple address feature to attach his work email 1323 joe@companya.example to his GMail account. When Joe sends email from 1324 his GMail account and uses joe@companya.example as his designated 1325 From: address, that email cannot have a signature with 1326 d=companya.example because the GMail servers have no access to 1327 Company A's private key. In GMail's case it will have a GMail 1328 signature, but for some other mail clients offering the same multiple 1329 address feature there may be no signature at all on the message. 1331 Another example might be the use of a forward article to a friend 1332 service. Most instances of these services today allow someone to 1333 send an article with their email address in the RFC 5322 From to 1334 their designated recipient. If Joe used either of his two addresses 1335 (joe@companya.example or joe@gmail.com), the forwarder would be 1336 equally unable to sign with a corresponding domain . As in the mail 1337 client case, the forwarder may either sign as its own domain, or may 1338 put no signature on the message. 1340 A third example is the use of privately configured forwarding. 1341 Assume that Joe has another account at Yahoo, joe@yahoo.com, but he'd 1342 prefer to read his Yahoo mail from his GMail account. He sets up his 1343 Yahoo account to forward all incoming mail to joe@gmail.com. Assume 1344 alice@companyb.example sends joe@yahoo.com an email. Depending on 1345 how companyb.example configured its signature, and depending on 1346 whether or not Yahoo modifies messages that it forwards, it is 1347 possible that when Alice's message is received in Joe's gmail account 1348 the original signature fails verification. 1350 8.2. Protection of Internal Mail 1352 One identity is particularly amenable to easy and accurate 1353 assessment: the organization's own identity. Members of an 1354 organization tend to trust messages that purport to be from within 1355 that organization. However Internet Mail does not provide a 1356 straightforward means of determining whether such mail is, in fact, 1357 from within the organization. DKIM can be used to remedy this 1358 exposure. If the organization signs all of its mail, then its 1359 boundary MTAs can look for mail purporting to be from the 1360 organization that does not contain a verifiable signature. 1362 Such mail can in most cases be presumed to be spurious. However, 1363 domain managers are advised to consider the ways that mail processing 1364 can modify messages in ways that will invalidate an existing DKIM 1365 signature: mailing lists, courtesy forwarders, and other paths that 1366 could add or modify headers or modify the message body (e.g. MTAs at 1367 hotels, hotspot networks used by travelling users, and other 1368 scenarios described in the previous section). Such breakage is 1369 particularly relevant in the presence of Author Domain Signing 1370 Practices. 1372 8.3. Signature Granularity 1374 Although DKIM's use of domain names is optimized for a scope of 1375 organization-level signing, it is possible to administer sub-domains 1376 or otherwise adjust signatures in a way that supports per-user 1377 identification. This user level granularity can be specified in two 1378 ways: either by sharing the signing identity and specifying an 1379 extension to the i= value that has a per-user granularity, or by 1380 creating and signing with unique per-user keys. 1382 A subdomain or local part in the i= tag should be treated as an 1383 opaque identifier and thus need not correspond directly to a DNS sub 1384 domain or to a specific user address 1386 The primary way to sign with per-user keys require that each user 1387 have a distinct DNS (sub)domain, where each distinct d= value has a 1388 key published (it is possible, although not recommended, to publish 1389 the same key in more than one distinct domain). 1391 It is technically possible, to publish per-user keys within a single 1392 domain or subdomain by utilizing different selector values. This is 1393 not recommended and is unlikely to be treated uniquely by Identity 1394 Assessors: the primary purpose of selectors is to facilitate key 1395 management, and the DKIM specification recommends against using them 1396 in determining or assessing identies. 1398 In most cases, it would be impractical to sign email on a per-user 1399 granularity. Such an approach would be 1401 likely to be ignored: In most cases today, if receivers are 1402 verifying DKIM signatures they are in general taking the simplest 1403 possible approach. In many cases maintaining reputation 1404 information at a per user granularity is not interesting to them, 1405 in large part because the per user volume is too small to be 1406 useful or interesting. So even if senders take on the complexity 1407 necessary to support per user signatures, receivers are unlikely 1408 to retain anything more than the base domain reputation. 1410 difficult to manage: Any scheme that involves maintenance of a 1411 significant number of public keys may require infrastructure 1412 enhancements or extensive administrative expertise. For domains 1413 of any size, maintaining a valid per-user keypair, knowing when 1414 keys need to be revoked or added due to user attrition or 1415 onboarding, and the overhead of having the signing engine 1416 constantly swapping keys can create significant and often 1417 unnecessary managment complexity. It is also important to note 1418 that there is no way within the scope of the DKIM specification 1419 for a receiver to infer that a sender intends a per-user 1420 granularity. 1422 What may make sense, however, is to use the infrastructure that 1423 enables finer granularity in signatures to identify segments smaller 1424 than a domain but much larger than a per-user segmentation. For 1425 example, a university might want to segment student, staff, and 1426 faculty mail into three distinct streams with differing reputations. 1427 This can be done by creating seperate sub-domains for the desired 1428 segments, and either specifying the subdomains in the i= tag of the 1429 DKIM Signature or by adding subdomains to the d= tag and assigning 1430 and signing with different keys for each subdomain. 1432 For those who choose to represent user level granularity in 1433 signatures, the performance and management considerations above 1434 suggest that it would be more effective to do it by specifying a 1435 local part or subdomain extension in the i= tag rather than by 1436 extending the d= domain and publishing individual keys. 1438 8.4. Email Infrastructure Agents 1440 It is expected that the most common venue for a DKIM implementation 1441 will be within the infrastructure of an organization's email service, 1442 such as a department or a boundary MTA. What follows are some 1443 general recommendations for the Email Infrastructure. 1445 Outbound: An MSA or an Outbound MTA used for mail submission 1446 SHOULD ensure that the message sent is in compliance with the 1447 advertised email sending policy. It SHOULD also be able to 1448 generate an operator alert if it determines that the email 1449 messages do not comply with the published DKIM sending policy. 1451 An MSA SHOULD be aware that some MUAs may add their own 1452 signatures. If the MSA needs to perform operations on a 1453 message to make it comply with its email sending policy, if at 1454 all possible, it SHOULD do so in a way that would not break 1455 those signatures. 1457 [[anchor38: MSK: MUAs being able to sign is a security 1458 consideration; MUAs are more prone to vulnerabilities, so an 1459 MUA having direct access to signing keys is a security concern; 1460 general MUA vulnerability came up during the IETF Security 1461 Directorate review of draft-kucherawy-sender-auth-header]] 1463 Inbound: When an organization deploys DKIM, it needs to make 1464 sure that it email infrastructure components that do not have 1465 primary roles in DKIM handling do not modify message in ways 1466 that prevent subsequent verification. 1468 An inbound MTA or an MDA may incorporate an indication of the 1469 verification results into the message, such as using an 1470 Authentication-Results header field. 1471 [I-D.kucherawy-sender-auth-header] 1473 Intermediaries: An email intermediary is both an inbound and 1474 outbound MTA. Each of the requirements outlined in the 1475 sections relating to MTAs apply. If the intermediary modifies 1476 a message in a way that breaks the signature, the intermediary 1478 + SHOULD deploy abuse filtering measures on the inbound mail, 1479 and 1481 + MAY remove all signatures that will be broken 1483 In addition the intermediary MAY: 1485 + Verify the message signature prior to modification. 1487 + Incorporate an indication of the verification results into 1488 the message, such as using an Authentication-Results header 1489 field. [I-D.kucherawy-sender-auth-header] 1491 + Sign the modified message including the verification results 1492 (e.g., the Authentication-Results header field). 1494 8.5. Mail User Agent 1496 The DKIM specification is expected to be used primarily between 1497 Boundary MTAs, or other infrastructure components of the originating 1498 and receiving ADMDs. However there is nothing in DKIM that is 1499 specific to those venues. In particular, MUAs MAY also support DKIM 1500 signing and verifying directly. 1502 Outbound: An MUA MAY support signing even if mail is to be 1503 relayed through an outbound MSA. In this case the signature 1504 applied by the MUA will be in addition to any signature added 1505 by the MSA. 1507 Some user software goes beyond simple user functionality and 1508 also perform MSA and MTA functions. When this is employed for 1509 sending directly to a receiving ADMD, the user software SHOULD 1510 be considered an outbound MTA. 1512 Inbound: An MUA MAY rely on a report of a DKIM signature 1513 verification that took place at some point in the inbound MTA/ 1514 MDA path (e.g., an Authentication-Results header field), or an 1515 MUA MAY perform DKIM signature verification directly. A 1516 verifying MUA SHOULD allow for the case where mail has modified 1517 in the inbound MTA path; if a signature fails, the message 1518 SHOULD NOT be treated any different than if it did not have a 1519 signature. 1521 An MUA that looks for an Authentication-Results header field 1522 MUST be configurable to choose which Authentication-Results are 1523 considered trustable. 1525 DKIM requires that all verifiers treat messages with signatures 1526 that do not verify as if they are unsigned. 1528 If verification in the client is to be acceptable to users, it 1529 is essential that successful verification of a signature not 1530 result in a less than satisfactory user experience compared to 1531 leaving the message unsigned. The mere presence of a verified 1532 DKIM signature MUST NOT by itself be used by an MUA to indicate 1533 that a message is to be treated better than a message without a 1534 verified DKIM signature. However, the fact that a DKIM 1535 signature was verified MAY be used as input into a reputation 1536 system (i.e., a whitelist of domains and users) for 1537 presentation of such indicators. 1539 It is common for components of an ADMD's email infrastructure to do 1540 violence to a message, such that a DKIM signature might be rendered 1541 invalid. Hence, users of MUAs that support DKIM signing and/or 1542 verifying need a basis for knowing that their associated email 1543 infrastructure will not break a signature. 1545 9. Other Considerations 1547 9.1. Security Considerations 1549 The security considerations of the DKIM protocol are described in the 1550 DKIM base specification [RFC4871]. 1552 9.2. IANA Considerations 1554 This document has no considerations for IANA. 1556 10. Acknowledgements 1558 TBD 1560 11. Informative References 1562 [I-D.ietf-dkim-overview] 1563 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1564 Identified Mail (DKIM) Service Overview", 1565 draft-ietf-dkim-overview-10 (work in progress), July 2008. 1567 [I-D.ietf-dkim-ssp] 1568 Local-part, a., Domain, A., error, r., Allman, E., Fenton, 1569 J., Delany, M., and J. Levine, "DomainKeys Identified Mail 1570 (DKIM) Author Domain Signing Practices (ADSP)", 1571 draft-ietf-dkim-ssp-09 (work in progress), February 2009. 1573 [I-D.ietf-openpgp-rfc2440bis] 1574 Callas, J., "OpenPGP Message Format", 1575 draft-ietf-openpgp-rfc2440bis-22 (work in progress), 1576 April 2007. 1578 [I-D.kucherawy-sender-auth-header] 1579 Kucherawy, M., "Message Header Field for Indicating 1580 Message Authentication Status", 1581 draft-kucherawy-sender-auth-header-20 (work in progress), 1582 January 2009. 1584 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 1585 for Internet electronic mail: Part I: Message encipherment 1586 and authentication procedures", RFC 989, February 1987. 1588 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1589 STD 13, RFC 1034, November 1987. 1591 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 1592 Object Security Services", RFC 1848, October 1995. 1594 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1595 Exchange Formats", RFC 1991, August 1996. 1597 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1598 "OpenPGP Message Format", RFC 2440, November 1998. 1600 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1601 "MIME Security with OpenPGP", RFC 3156, August 2001. 1603 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 1604 August 2001. 1606 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1607 Extensions (S/MIME) Version 3.1 Message Specification", 1608 RFC 3851, July 2004. 1610 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1611 Identified Mail (DKIM)", RFC 4686, September 2006. 1613 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 1614 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1615 May 2007. 1617 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1618 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1619 Signatures", RFC 4871, May 2007. 1621 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1622 Security (DNSSEC) Hashed Authenticated Denial of 1623 Existence", RFC 5155, March 2008. 1625 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1626 October 2008. 1628 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1629 October 2008. 1631 Appendix A. Migrating from DomainKeys 1633 As with any migration, the steps required will be determined by who 1634 is doing the migration and their assessment of 1636 o the users of what they are generating, or 1638 o the providers of what they are consuming. 1640 A.1. Signers 1642 A signer that currently signs with DomainKeys (DK) will go through 1643 various stages as they migrate to using DKIM, not all of which are 1644 required for all signers. The real questions that a signer must ask 1645 are: 1647 1. how many receivers or what types of receivers are *only* looking 1648 at the DK signatures and not the DKIM signatures, 1650 2. and how much does the signer care about those receivers? 1652 If no one is looking at the DK signature any more, then it's no 1653 longer necessary to sign with DK. Or if there are no more "large 1654 players" looking only at the DK signatures, a signer may choose to 1655 stop signing with DK. 1657 With respect to signing policies, a reasonable, initial approach is 1658 to use DKIM signatures in the same way as DomainKeys signatures are 1659 already being used. In particular, the same selectors and DNS Key 1660 Records may be used for both, after verifying that they are 1661 compatible as discussed below. 1663 Each secondary step in all of the following scenarios is to be 1664 prefaced with the gating factor "test, then when comfortable with the 1665 previous step's results, continue". 1667 One migration strategy is to: 1669 o ensure that the current selector DNS key record is compatible with 1670 both DK and DKIM 1672 o sign messages with both DK and DKIM signatures 1673 o when it's decided that DK signatures are no longer necessary, stop 1674 signing with DK 1676 Another migration strategy is to: 1678 o add a new selector DNS key record only for DKIM signatures 1680 o sign messages with both DK (using the old DNS key record) and DKIM 1681 signatures (using the new DNS key record) 1683 o when it's decided that DK signatures are no longer necessary, stop 1684 signing with DK 1686 o eventually remove the old DK selector DNS record 1688 A combined migration strategy is to: 1690 o ensure that the current selector DNS key record is compatible with 1691 both DK and DKIM 1693 o start signing messages with both DK and DKIM signatures 1695 o add a new selector DNS key record for DKIM signatures 1697 o switch the DKIM signatures to use the new selector 1699 o when it's decided that DK signatures are no longer necessary, stop 1700 signing with DK 1702 o eventually remove the old DK selector DNS record 1704 Another migration strategy is to: 1706 o add a new selector DNS key record for DKIM signatures 1708 o do a flash cut and replace the DK signatures with DKIM signatures 1710 o eventually remove the old DK selector DNS record 1712 Another migration strategy is to: 1714 o ensure that the current selector DNS key record is compatible with 1715 both DK and DKIM 1717 o do a flash cut and replace the DK signatures with DKIM signatures 1719 Note that when you have separate key records for DK and DKIM, you can 1720 use the same public key for both. 1722 A.1.1. DNS Selector Key Records 1724 The first step in some of the above scenarios is ensuring that the 1725 selector DNS key records are compatible for both DK and DKIM. The 1726 format of the DNS key record was intentionally meant to be backwardly 1727 compatible between the two systems, but not necessarily upwardly 1728 compatible. DKIM has enhanced the DK DNS key record format by adding 1729 several optional parameters, which DK must ignore. However, there is 1730 one critical difference between DK and DKIM DNS key records: the 1731 definitions of the g fields: 1733 g= granularity of the key In both DK and DKIM, this is an optional 1734 field that is used to constrain which sending address(es) can 1735 legitimately use this selector. Unfortunately, the treatment of 1736 an empty field ("g=;") is different. DKIM allows wildcards where 1737 DK does not. For DK, an empty field is the same as a missing 1738 value, and is treated as allowing any sending address. For DKIM, 1739 an empty field only matches an empty local part. In DKIM, both a 1740 missing value and "g=*;" mean to allow any sending address. 1742 If your DK DNS key record has an empty g= field in it ("g=;"), 1743 your best course of action is to modify the record to remove the 1744 empty field. In that way, the DK semantics will remain the same, 1745 and the DKIM semantics will match. 1747 If your DNS key record does not have an empty g= field in it ("g=;"), 1748 it's probable that the record can be left alone. But your best 1749 course of action would still be to make sure it has a v= field. When 1750 the decision is made to stop supporting DomainKeys and to only 1751 support DKIM, you MUST verify that the "g" field is compatible with 1752 DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED 1753 that if you want to use an empty g= field in your DKIM selector, you 1754 also include the v= field. 1756 A.1.2. Removing DomainKeys Signatures 1758 The principal use of DomainKeys is at Boundary MTAs. Because no 1759 operational transition is ever instantaneous, it is advisable to 1760 continue performing DomainKeys signing until it is determined that 1761 DomainKeys receive-side support is no longer used, or is sufficiently 1762 reduced. That is, a signer SHOULD add a DKIM signature to a message 1763 that also has a DomainKeys signature and keep it there until you 1764 decide it can go away. The signer may do its transitions in a 1765 straightforward manner, or more gradually. Note that because digital 1766 signatures are not free, there is a cost to performing both signing 1767 algorithms, so you don't want to be signing with both algorithms for 1768 too long a period. 1770 The tricky part is deciding when DK signatures are no longer 1771 necessary. The real questions are: how many DomainKeys verifiers are 1772 there that do *not* also do DKIM verification, which ones of them do 1773 you care about, and how can you track their usage? Most of the early 1774 adopters of DK verification have added DKIM verification, but not all 1775 yet. If a verifier finds a message with both DK and DKIM, it may 1776 choose to verify both signatures, or just one or the other. 1778 Many DNS services offer tracking statistics so you can find out how 1779 often a DNS record has been accessed. By using separate DNS selector 1780 key records for your signatures, you can chart the usage of your 1781 records over time, and watch the trends. An additional 1782 distinguishing factor to track would take into account the verifiers 1783 that verify both the DK and DKIM signatures, and discount those from 1784 your counts of DK selector usage. When the number for DK selector 1785 access reaches a low-enough level, that's the time to consider 1786 stopping your DK signing. 1788 Note, this level of rigor is not required. It is perfectly 1789 reasonable for a DK signer to decide to follow the "flash cut" 1790 scenario described above. 1792 A.2. Verifiers 1794 As a verifier, you are faced with several issues: 1796 A.2.1. Do you verify DK signatures? 1798 At the time of writing, there is still a significant number of sites 1799 that are only producing DK signatures. Over time, it is expected 1800 that this number will go to zero, but it may take several years. So 1801 it would be prudent for the foreseeable future for a verifier to look 1802 for and verify both DKIM and DK signatures. 1804 A.2.2. Do you verify both DK and DKIM signatures within a single 1805 message? 1807 For a period of time, there will be sites that sign with both DK and 1808 DKIM. A verifier receiving a message that has both types of 1809 signatures may verify both signatures, or just one. One disadvantage 1810 of verifying both signatures is that signers will have a more 1811 difficult time deciding how many verifiers are still using their DK 1812 selectors. One transition strategy is to verify the DKIM signature, 1813 then only verify the DK signature if the DKIM verification fails. 1815 A.2.3. DNS Selector Key Records 1817 The format of the DNS key record was intentionally meant to be 1818 backwardly compatible between DK and DKIM, but not necessarily 1819 upwardly compatible. DKIM has enhanced the DK DNS key record format 1820 by adding several optional parameters, which DK must ignore. 1821 However, there is one key difference between DK and DKIM DNS key 1822 records: the definitions of the g fields: 1824 g= granularity of the key In both DK and DKIM, this is an optional 1825 field that is used to constrain which sending address(es) can 1826 legitimately use this selector. Unfortunately, the treatment of 1827 an empty field ("g=;") is different. For DK, an empty field is 1828 the same as a missing value, and is treated as allowing any 1829 sending address. For DKIM, an empty field only matches an empty 1830 local part. 1832 v= version of the selector It is recommended that a DKIM selector 1833 have v=DKIM1; at its beginning, but it is not required. 1835 If a DKIM verifier finds a selector record that has an empty g= field 1836 ("g=;") and it does not have a v= field ("v=DKIM1;") at its 1837 beginning, it is faced with deciding if this record was 1839 1. from a DK signer that transitioned to supporting DKIM but forgot 1840 to remove the g= field (so that it could be used by both DK and 1841 DKIM verifiers), or 1843 2. from a DKIM signer that truly meant to use the empty g= field but 1844 forgot to put in the v= field. It is RECOMMENDED that you treat 1845 such records using the first interpretation, and treat such 1846 records as if the signer did not have a g= field in the record. 1848 Appendix B. General Coding Criteria for Cryptographic Applications 1850 NOTE: This section could possibly be changed into a reference to 1851 something else, such as another rfc. 1853 Correct implementation of a cryptographic algorithm is a necessary 1854 but not a sufficient condition for the coding of cryptographic 1855 applications. Coding of cryptographic libraries requires close 1856 attention to security considerations that are unique to cryptographic 1857 applications. 1859 In addition to the usual security coding considerations, such as 1860 avoiding buffer or integer overflow and underflow, implementers 1861 should pay close attention to management of cryptographic private 1862 keys and session keys, ensuring that these are correctly initialized 1863 and disposed of. 1865 Operating system mechanisms that permit the confidentiality of 1866 private keys to be protected against other processes should be used 1867 when available. In particular, great care must be taken when 1868 releasing memory pages to the operating system to ensure that private 1869 key information is not disclosed to other processes. 1871 Certain implementations of public key algorithms such as RSA may be 1872 vulnerable to a timing analysis attack. 1874 Support for cryptographic hardware providing key management 1875 capabilities is strongly encouraged. In addition to offering 1876 performance benefits, many cryptographic hardware devices provide 1877 robust and verifiable management of private keys. 1879 Fortunately appropriately designed and coded cryptographic libraries 1880 are available for most operating system platforms under license terms 1881 compatible with commercial, open source and free software license 1882 terms. Use of standard cryptographic libraries is strongly 1883 encouraged. These have been extensively tested, reduce development 1884 time and support a wide range of cryptographic hardware. 1886 Authors' Addresses 1888 Tony Hansen 1889 AT&T Laboratories 1890 200 Laurel Ave. South 1891 Middletown, NJ 07748 1892 USA 1894 Email: tony+dkimov@maillennium.att.com 1896 Ellen Siegel 1897 Constant Contact, Inc. 1898 1601 Trapelo Rd, Ste 329 1899 Waltham, MA 02451 1900 USA 1902 Email: esiegel@constantcontact.com 1903 Phillip Hallam-Baker 1904 VeriSign Inc. 1906 Email: pbaker@verisign.com 1908 Dave Crocker 1909 Brandenburg InternetWorking 1910 675 Spruce Dr. 1911 Sunnyvale, CA 94086 1912 USA 1914 Email: dcrocker@bbiw.net