idnits 2.17.1 draft-ietf-dkim-deployment-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2010) is 5202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LEGEND' is mentioned on line 589, but not defined ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 5451 (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 5672 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: July 31, 2010 6 P. Hallam-Baker 7 Default Deny Security, Inc. 8 D. Crocker 9 Brandenburg InternetWorking 10 January 27, 2010 12 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations 13 draft-ietf-dkim-deployment-11 15 Abstract 17 DomainKeys Identified Mail (DKIM) allows an organization to claim 18 responsibility for transmitting a message, in a way that can be 19 validated by a recipient. The organization can be the author's, the 20 originating sending site, an intermediary, or one of their agents. A 21 message can contain multiple signatures, from the same or different 22 organizations involved with the message. DKIM defines a domain-level 23 digital signature authentication framework for email, using public 24 key cryptography, using the domain name service as its key server 25 technology. This permits verification of a responsible organization, 26 as well as the integrity of the message contents. DKIM will also 27 provide a mechanism that permits potential email signers to publish 28 information about their email signing practices; this will permit 29 email receivers to make additional assessments about messages. 30 DKIM's authentication of email identity can assist in the global 31 control of "spam" and "phishing". This document provides 32 implementation, deployment, operational and migration considerations 33 for DKIM. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on July 31, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5 88 2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5 89 2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7 90 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9 91 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11 92 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 13 93 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 16 94 3.1. Private Key Management: Deployment and Ongoing 95 Operations . . . . . . . . . . . . . . . . . . . . . . . . 17 96 3.2. Storing Public Keys: DNS Server Software Considerations . 18 97 3.3. Per User Signing Key Management Issues . . . . . . . . . . 19 98 3.4. Third Party Signer Key Management and Selector 99 Administration . . . . . . . . . . . . . . . . . . . . . . 19 100 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 20 101 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 22 103 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 22 104 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 23 105 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 24 107 5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 24 108 5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 24 109 5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 25 110 5.5. Messages sent through Mailing Lists and other 111 Intermediaries . . . . . . . . . . . . . . . . . . . . . . 25 112 5.6. Generation, Transmission and Use of Results Headers . . . 26 113 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 26 114 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 27 115 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 27 116 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 28 117 6.4. Using Trusted Third Party Senders . . . . . . . . . . . . 30 118 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 30 119 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 32 120 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 32 121 7.2. Author's Organization - Differentiated Types of Mail . . . 33 122 7.3. Author Domain Signing Practices . . . . . . . . . . . . . 33 123 7.4. Delegated Signing . . . . . . . . . . . . . . . . . . . . 35 124 7.5. Independent Third Party Service Providers . . . . . . . . 35 125 7.6. Mail Streams Based on Behavioral Assessment . . . . . . . 36 126 7.7. Agent or Mediator Signatures . . . . . . . . . . . . . . . 37 127 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 37 128 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 37 129 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 38 130 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 38 131 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 40 132 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 41 133 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 42 134 9.1. Security Considerations . . . . . . . . . . . . . . . . . 42 135 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 42 136 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 137 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 138 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43 139 11.2. Informative References . . . . . . . . . . . . . . . . . . 43 140 Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 43 141 A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 44 142 A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 48 143 A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 49 144 Appendix B. General Coding Criteria for Cryptographic 145 Applications . . . . . . . . . . . . . . . . . . . . 50 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 148 1. Introduction 150 DomainKeys Identified Mail (DKIM) allows an organization to claim 151 responsibility for transmitting a message, in a way that can be 152 validated by a recipient. This document provides practical tips for: 153 those who are developing DKIM software, mailing list managers, 154 filtering strategies based on the output from DKIM verification, and 155 DNS servers; those who are deploying DKIM software, keys, mailing 156 list software, and migrating from DomainKeys [RFC4870]; and those who 157 are responsible for the on-going operations of an email 158 infrastructure that has deployed DKIM. 160 The document is organized around the key concepts related to DKIM. 161 Within each section, additional considerations specific to 162 development, deployment, or ongoing operations are highlighted where 163 appropriate. The possibility of use of DKIM results as input to a 164 local reputation database is also discussed. 166 2. Using DKIM as Part of Trust Assessment 168 2.1. A Systems View of Email Trust Assessment 170 DKIM participates in a trust-oriented enhancement to the Internet's 171 email service, to facilitate message handling decisions, such as for 172 delivery and for content display. Trust-oriented message handling 173 has substantial differences from the more established approaches that 174 consider messages in terms of risk and abuse. With trust, there is a 175 collaborative exchange between a willing participant along the 176 sending path and a willing participant at a recipient site. In 177 contrast, the risk model entails independent, unilateral action by 178 the recipient site, in the face of a potentially unknown, hostile and 179 deceptive sender. This translates into a very basic technical 180 difference: In the face of unilateral action by the recipient and 181 even antagonistic efforts by the sender, risk-oriented mechanisms are 182 be based on heuristics, that is, on guessing. Guessing produces 183 statistical results with some false negatives and some false 184 positives. For trust-based exchanges, the goal is the deterministic 185 exchange of information. For DKIM, that information is the one 186 identifier that represents a stream of mail for which an independent 187 assessment is sought (by the signer.) 189 A trust-based service is built upon a validated Responsible 190 Identifier that labels a stream of mail and is controlled by an 191 identity (role, person or organization). The identity is 192 acknowledging some degree of responsibility for the message stream. 193 Given a basis for believing that an identifier is being used in an 194 authorized manner, the recipient site can make and use an assessment 195 of the associated identity. An identity can use different 196 identifiers, on the assumption that the different streams might 197 produce different assessments. For example, even the best-run 198 marketing campaigns will tend to produce some complaints that can 199 affect the reputation of the associated identifier, whereas a stream 200 of transactional messages is likely to have a more pristine 201 reputation. 203 Determining that the identifier's use is valid is quite different 204 from determining that the content of a message is valid. The former 205 means only that the identifier for the responsible role, person or 206 organization has been legitimately associated with a message. The 207 latter means that the content of the message can be believed and, 208 typically, that the claimed author of the content is correct. DKIM 209 validates only the presence of the identifier used to sign the 210 message. Even when this identifier is validated, DKIM carries no 211 implication that any of the message content, including the 212 RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to 213 the semantics of a DKIM signature applies even when the validated 214 signing identifier is the same domain name as is used in the 215 RFC5322.From field! DKIM's only claim about message content is that 216 the content cited in the DKIM-Signature: field's h= tag has been 217 delivered without modification. That is, it asserts message content 218 integrity -- between signing and verifying -- not message content 219 validity. 221 As shown in Figure 1, this enhancement is a communication between a 222 responsible role, person or organization that signs the message and a 223 recipient organization that assesses its trust in the signer. The 224 recipient then makes handling decisions based on a collection of 225 assessments, of which the DKIM mechanism is only a part. In this 226 model, as shown in Figure 1, validation is an intermediary step, 227 having the sole task of passing a validated Responsible Identifier to 228 the Identity Assessor. The communication is of a single Responsible 229 Identifier that the Responsible Identity wishes to have used by the 230 Identity Assessor. The Identifier is the sole, formal input and 231 output value of DKIM signing. The Identity Assessor uses this 232 single, provided Identifier for consulting whatever assessment data 233 bases are deemed appropriate by the assessing entity. In turn, 234 output from the Identity Assessor is fed into a Handling Filter 235 engine that considers a range of factors, along with this single 236 output value. The range of factors can include ancillary information 237 from the DKIM validation. 239 Identity Assessment covers a range of possible functions. It can be 240 as simple as determining whether the identifier is a member of some 241 list, such as authorized operators or participants in a group that 242 might be of interest for recipient assessment. Equally, it can 243 indicate a degree of trust (reputation) that is to be afforded the 244 actor using that identifier. The extent to which the assessment 245 affects handling of the message is, of course, determined later, by 246 the Handling Filter. 248 +------+------+ +------+------+ 249 | Author | | Recipient | 250 +------+------+ +------+------+ 251 | ^ 252 | | 253 | +------+------+ 254 | -->| Handling |<-- 255 | -->| Filter |<-- 256 | +-------------+ 257 | ^ 258 V Responsible | 259 +-------------+ Identifier +------+------+ 260 | Responsible |. . . . . . . . . . .>| Identity | 261 | Identity | . . | Assessor | 262 +------+------+ . . +-------------+ 263 | V . ^ ^ 264 V . . | | 265 +------------------.-------.--------------------+ | | 266 | +------+------+ . . . > . +-------------+ | | | +-----------+ 267 | | Identifier | | Identifier +--|--+ +--+ Assessment| 268 | | Signer +------------->| Validator | | | Databases | 269 | +-------------+ +-------------+ | +-----------+ 270 | DKIM Service | 271 +-----------------------------------------------+ 273 Figure 1: Actors in a Trust Sequence using DKIM 275 2.2. Choosing a DKIM Tag for the Assessment Identifier 277 The signer of a message needs to be able to provide precise data and 278 know what that data will mean upon delivery to the Assessor. If 279 there is ambiguity in the choice that will be made on the receive 280 side, then the sender cannot know what basis for assessment will be 281 used. DKIM has three values that specify identification information 282 and it is easy to confuse their use, although only one defines the 283 formal input and output of DKIM, with the other two being used for 284 internal protocol functioning and adjunct purposes, such as auditing 285 and debugging. 287 The salient values include the s=, d= and i= parameters in the DKIM- 288 Signature: header field. In order to achieve the end-to-end 289 determinism needed for this collaborative exchange from the signer to 290 the assessor, the core model needs to specify what the signer is 291 required to provide to the assessor. The Update to RFC4871 [RFC5672] 292 now specifies: 294 DKIM's primary task is to communicate from the Signer to a 295 recipient-side Identity Assessor a single Signing Domain 296 Identifier (SDID) that refers to a responsible identity. DKIM can 297 optionally provide a single responsible Agent or User Identifier 298 (AUID)... A receive-side DKIM verifier needs to communicate the 299 Signing Domain Identifier (d=) to a consuming Identity Assessor 300 module and can also communicate the User Agent Identifier (i=) if 301 present.... To the extent that a receiver attempts to intuit any 302 structured semantics for either of the identifiers, this is a 303 heuristic function that is outside the scope of DKIM's 304 specification and semantics. 306 The single, mandatory value that DKIM supplies as its output is: 308 d= This specifies the "domain of the signing entity." It is a 309 domain name and is combined with the Selector to form a DNS 310 query... A receive-side DKIM verifier needs to communicate the 311 Signing Domain Identifier (d=) to a consuming Identity Assessor 312 module and can also communicate the User Agent Identifier (i=) 313 if present. 315 The adjunct values are: 317 s= This tag specifies the Selector. It is used to discriminate 318 among different keys that can be used for the same d= domain 319 name. As discussed in Section 4.3 of [RFC5585]: "If verifiers 320 were to employ the selector as part of a name assessment 321 mechanism, then there would be no remaining mechanism for 322 making a transition from an old, or compromised, key to a new 323 one." Consequently, the Selector is not appropriate for use as 324 part or all of the identifier used to make assessments. 326 i= This tag is optional and provides the "[i]dentity of the 327 user or agent (e.g., a mailing list manager) on behalf of which 328 this message is signed." The identity can be in the syntax of 329 an entire email address or only a domain name. The domain name 330 can be the same as for d= or it can be a sub-name of the d= 331 name. 333 NOTE: Although the i= identity has the syntax of an email 334 address, it is not required to have that semantics. That is, 335 "the identity of the user" need not be the same as the user's 336 mailbox. For example the signer might wish to use i= to encode 337 user-related audit information, such as how they were accessing 338 the service at the time of message posting. Therefore it is 339 not possible to conclude anything from the i= string's 340 (dis)similarity to email addresses elsewhere in the header 342 So, i= can have any of these properties: 344 * Be a valid domain when it is the same as d= 346 * Appear to be a sub-domain of d= but might not even exist 348 * Look like a mailbox address but might have different semantics 349 and therefore not function as a valid email address 351 * Be unique for each message, such as indicating access details 352 of the user for the specific posting 354 This underscores why the tag needs to be treated as being opaque, 355 since it can represent any semantics, known only to the signer. 357 Hence, i= serves well as a token that is usable like a Web cookie, 358 for return to the signing ADMD -- such as for auditing and debugging. 359 Of course in some scenarios the i= string might provide a useful 360 adjunct value for additional (heuristic) processing by the Handling 361 Filter. 363 2.3. Choosing the Signing Domain Name 365 A DKIM signing entity can serve different roles, such as being the 366 author of content, or the operator of the mail service, or the 367 operator of a reputation service that also provides signing services 368 on behalf of its customers. In these different roles, the basis for 369 distinguishing among portions of email traffic can vary. For an 370 entity creating DKIM signatures it is likely that different portions 371 of its mail will warrant different levels of trust. For example: 373 * Mail is sent for different purposes, such as marketing vs. 374 transactional, and recipients demonstrate different patterns of 375 acceptance between these. 377 * For an operator of an email service, there often are distinct 378 sub-populations of users warranting different levels of trust 379 or privilege, such as paid vs. free users, or users engaged in 380 direct correspondence vs. users sending bulk mail. 382 * Mail originating outside an operator's system, such as when it 383 is redistributed by a mailing list service run by the operator, 384 will warrant a different reputation from mail submitted by 385 users authenticated with the operator. 387 It is therefore likely to be useful for a signer to use different d= 388 sub-domain names, for different message traffic streams, so that 389 receivers can make differential assessments. However, too much 390 differentiation -- that is, too fine a granularity of signing domains 391 -- makes it difficult for the receiver to discern a sufficiently 392 stable pattern of traffic for developing an accurate and reliable 393 assessment. So the differentiation needs to achieve a balance. 394 Generally in a trust system, legitimate signers have an incentive to 395 pick a small stable set of identities, so that recipients and others 396 can attribute reputations to them. The set of these identities a 397 receiver trusts is likely to be quite a bit smaller than the set it 398 views as risky. 400 The challenge in using additional layers of sub-domains is whether 401 the extra granularity will be useful for the assessor. In fact, 402 excessive levels invite ambiguity: if the assessor does not take 403 advantage of the added granularity in the entire domain name that is 404 provided, they might unilaterally decide to use only some rightmost 405 part of the identifier. The signer cannot know what portion will be 406 used. That ambiguity would move the use of DKIM back to the realm of 407 heuristics, rather than the deterministic processing that is its 408 goal. 410 Hence the challenge is to determine a useful scheme for labeling 411 different traffic streams. The most obvious choices are among 412 different types of content and/or different types of authors. 413 Although stability is essential, it is likely that the choices will 414 change, over time, so the scheme needs to be flexible. 416 For those originating message content, the most likely choice of sub- 417 domain naming scheme will by based upon type of content, which can 418 use content-oriented labels or service-oriented labels. For example: 420 transaction.example.com 421 newsletter.example.com 422 bugreport.example.com 423 support.example.com 424 sales.example.com 425 marketing.example.com 427 where the choices are best dictated by whether they provide the 428 Identity Assessor with the ability to discriminate usefully among 429 streams of mail that demonstrate significantly different degrees of 430 recipient acceptance or safety. Again, the danger in providing too 431 fine a granularity is that related message streams that are labeled 432 separately will not benefit from an aggregate reputation. 434 For those operating messaging services on behalf of a variety of 435 customers, an obvious scheme to use has a different sub-domain label 436 for each customer. For example: 438 widgetco.example.net 439 moviestudio.example.net 440 bigbank.example.net 442 However it can also be appropriate to label by the class of service 443 or class of customer, such as: 445 premier.example.net 446 free.example.net 447 certified.example.net 449 Prior to using domain names for distinguishing among sources of data, 450 IP Addresses have been the basis for distinction. Service operators 451 typically have done this by dedicating specific outbound IP Addresses 452 to specific mail streams -- typically to specific customers. For 453 example, a university might want to distinguish mail from the 454 Administration, versus mail from the student dorms. In order to make 455 adoption of a DKIM-based service easier, it can be reasonable to 456 translate the same partitioning of traffic, using domain names in 457 place of the different IP Addresses. 459 2.4. Recipient-based Assessments 461 DKIM gives the recipient site's Identity Assessor a verifiable 462 identifier to use for analysis. Although the mechanism does not make 463 claims that the signer is a Good Actor or a Bad Actor, it does make 464 it possible to know that use of the identifier is valid. This is in 465 marked contrast with schemes that do not have authentication. 467 Without verification, it is not possible to know whether the 468 identifier -- whether taken from the RFC5322.From field, 469 RFC5321.MailFrom command, or the like -- is being used by an 470 authorized agent. DKIM solves this problem. Hence with DKIM, the 471 Assessor can know that two messages with the same DKIM d= identifier 472 are, in fact, signed by the same person or organization. This 473 permits a far more stable and accurate assessment of mail traffic 474 using that identifier. 476 DKIM is distinctive, in that it provides an identifier which is not 477 necessarily related to any other identifier in the message. Hence, 478 the signer might be the author's ADMD, one of the operators along the 479 transit path, or a reputation service being used by one of those 480 handling services. In fact, a message can have multiple signatures, 481 possibly by any number of these actors. 483 As discussed above, the choice of identifiers needs to be based on 484 differences that the signer thinks will be useful for the recipient 485 Assessor. Over time, industry practices establish norms for these 486 choices. 488 Absent such norms, it is best for signers to distinguish among 489 streams that have significant differences, while consuming the 490 smallest number of identifiers possible. This will limit the 491 burden on recipient Assessors. 493 A common view about a DKIM signature is that it carries a degree of 494 assurance about some or all of the message contents, and in 495 particular that the RFC5322.From field is likely to be valid. In 496 fact, DKIM makes assurances only about the integrity of the data and 497 not about its validity. Still, presumptions of RFC5322.From field 498 validity remain a concern. Hence a signer using a domain name that 499 is unrelated to the domain name in the RFC5322.From field can 500 reasonably expect that the disparity will warrant some curiosity, at 501 least until signing by independent operators has produced some 502 established practice among recipient Assessors. 504 With the identifier(s) supplied by DKIM, the Assessor can consult an 505 independent assessment service about the entity associated with the 506 identifier(s). Another possibility is that the Assessor can develop 507 its own reputation rating for the identifier(s). That is, over time, 508 the Assessor can observe the stream of messages associated with the 509 identifier(s) developing a reaction to associated content. For 510 example, if there is a high percentage of user complaints regarding 511 signed mail with a "d=" value of "widgetco.example.net", the Assessor 512 might include that fact in the vector of data it provides to the 513 Handling Filter. This is also discussed briefly in Section 5.4. 515 2.5. Filtering 517 The assessment of the signing identifier is given to a Handling 518 Filter that is defined by local policies, according to a potentially 519 wide range of different factors and weightings. This section 520 discusses some of the kinds of choices and weightings that are 521 plausible, and the differential actions that might be performed. 522 Because authenticated domain names represent a collaborative sequence 523 between signer and assessor, actions can sometimes reasonably include 524 contacting the signer. 526 The discussion focuses on variations in Organizational Trust versus 527 Message Stream Risk, that is, the degree of positive assessment of a 528 DKIM-signing organization, and the potential danger present in the 529 message stream signed by that organization. While it might seem that 530 higher trust automatically means lower risk, the experience with 531 real-world operations provides examples of every combination of the 532 two factors, as shown in Figure 2. For each axis, only three levels 533 of granularity are listed, in order to keep discussion manageable. 534 In real-world filtering engines, finer-grained distinctions are 535 typically needed, and there typically are more axes. For example, 536 there are different types of risk, so that an engine might 537 distinguish between spam risk versus virus risk and take different 538 actions based on which type of problematic content is present. For 539 spam, the potential damage from a false negative is small, whereas 540 the damage from a false positive is high. For a virus, the potential 541 danger from a false negative is extremely high, while the likelihood 542 of a false positive when using modern detection tools is extremely 543 low. However for the discussion here, "risk" is taken as a single 544 construct. 546 The DKIM d= identifier is independent of any other identifier in a 547 message and can be a sub-domain of the name owned by the signer. 548 This permits use of fine-grained and stable distinctions between 549 different types of message streams, such as between transactional 550 messages and marketing messages from the same organization. Hence, 551 use of DKIM might permit a richer filtering model than has typically 552 been possible for mail receiving engines. 554 Note that the realities of today's public Internet Mail environment 555 necessitate having a baseline handling model that is quite 556 suspicious. Hence, "strong" filtering rules really are the starting 557 point, as indicated for the UNKNOWN cell. 559 The table indicates differential handling for each combination, such 560 as how aggressive or broad-based the filtering could be. 561 Aggressiveness affects the types of incorrect assessments that are 562 likely. So the table distinguishes various characteristics, 563 including: 1) whether an organization is unknown, known to be good 564 actors and known to be bad actors; and 2) the assessment of messages. 565 It includes advice about the degree of filtering that might be done, 566 and other message disposition. Perhaps unexpectedly, it also lists a 567 case in which the receiving site might wish to deliver problematic 568 mail, rather than redirecting or deleting it, but also contacting the 569 signing organization and seeking 570 +-------------+-----------------------------------------------+ 571 | S T R E A M * O R G A N I Z A T I O N A L T R U S T | 572 | R I S K * Low Medium High | 573 | +***************+***************+***************+ 574 | Low * BENIGN: | DILIGENT: | PRISTINE | 575 | * Moderate | Mild | Accept | 576 | * filter | filter | | 577 | +---------------+---------------+---------------+ 578 | Medium * UNKNOWN: | TYPICAL: | PROTECTED: | 579 | * Strong | Targeted | Accept & | 580 | * filter | filter | Contact | 581 | +---------------+---------------+---------------+ 582 | High * MALICIOUS: | NEGLIGENT: | COMPROMISED: | 583 | * Block & | Block | Block & | 584 | * Counter | | Contact | 585 +-------------+---------------+---------------+---------------+ 587 Figure 2: Trust vs. Risk Handling Tradeoffs Example 589 [LEGEND] 591 AXES 593 Stream Risk: This is a measure of the recent history of a 594 message stream and the severity of problems it has presented. 596 Organizational Trust: This combines longer-term history about 597 possible stream problems from that organization, and its 598 responsiveness to problem handling. 600 CELLS (indicating reasonable responses) 602 Labels for the cells are meant as a general assessment of an 603 organization producing that type of mail stream under that 604 circumstance. 606 Benign: There is some history of sending good messages, with 607 very few harmful messages having been received. This stream 608 warrants filtering that does not search for problems very 609 aggressively, in order to reduce the likelihood of False 610 Positives. 612 Diligent: The stream has had a limited degree of problems and 613 the Organization is consistently successful at controlling 614 their abuse issues and in a timely manner. 616 Pristine: There is a history of a clean message stream with no 617 problems, from an Organization with an excellent reputation. 618 So, the filter primarily needs to ensure that messages are 619 delivered; catching stray problem messages is a lesser concern. 620 In other words, the paramount concern, here, is False 621 Positives. 623 ----- 625 Unknown: There is no history with the Organization. Apply an 626 aggressive level of "naive" filtering, given the nature of the 627 public email environment. 629 Typical: The stream suffers significant abuse issues and the 630 Organization has demonstrated a record of having difficulties 631 resolving them in a timely manner, in spite of legitimate 632 efforts. Unfortunately, this is the typical case for service 633 providers with an easy and open subscription policy. 635 Protected: An Organization with a good history and/or providing 636 an important message stream for the receiving site is subject 637 to a local policy that messages are not allowed to be blocked, 638 but the stream is producing a problematic stream. The receiver 639 delivers messages, but works quickly with the Organization to 640 resolve the matter. 642 ----- 644 Malicious: A persistently problematic message stream is coming 645 from an Organization that appears to contribute to the problem. 646 The stream will be blocked, but the Organization's role is 647 sufficiently troubling to warrant following up with others in 648 the anti-abuse or legal communities, to constrain or end their 649 impact. 651 Negligent: A persistently problematic message stream is coming 652 from an Organization that does not appear to be contributing to 653 the problem, but also does not appear to be working to 654 eliminate it. At the least, the stream needs to be blocked. 656 Compromised: An Organization with a good history has a stream 657 that changes and becomes too problematic to be delivered. The 658 receiver blocks the stream and works quickly with the 659 Organization to resolve the matter. 661 3. DKIM Key Generation, Storage, and Management 663 By itself, verification of a digital signature only allows the 664 verifier to conclude with a very high degree of certainty that the 665 signature was created by a party with access to the corresponding 666 private signing key. It follows that a verifier requires means to 667 (1) obtain the public key for the purpose of verification and (2) 668 infer useful attributes of the key holder. 670 In a traditional Public Key Infrastructure (PKI), the functions of 671 key distribution and key accreditation are separated. In DKIM 672 [RFC4871], these functions are both performed through the DNS. 674 In either case, the ability to infer semantics from a digital 675 signature depends on the assumption that the corresponding private 676 key is only accessible to a party with a particular set of 677 attributes. In traditional PKI, a Trusted Third Party (TTP) vouches 678 that the key holder has been validated with respect to a specified 679 set of attributes. The range of attributes that can be attested in 680 such a scheme is thus limited only to the type of attributes that a 681 TTP can establish effective processes for validating. In DKIM, 682 Trusted Third parties are not employed and the functions of key 683 distribution and accreditation are combined. 685 Consequently there are only two types of inference that a signer can 686 make from a key published in a DKIM Key Record: 688 1. That a party with the ability to control DNS records within a DNS 689 zone intends to claim responsibility for messages signed using 690 the corresponding private signature key. 692 2. That use of a specific key is restricted to the particular subset 693 of messages identified by the selector. 695 The ability to draw any useful conclusion from verification of a 696 digital signature relies on the assumption that the corresponding 697 private key is only accessible to a party with a particular set of 698 attributes. In the case of DKIM, this means that the party that 699 created the corresponding DKIM key record in the specific zone 700 intended to claim responsibility for the signed message. 702 Ideally we would like to draw a stronger conclusion, that if we 703 obtain a DKIM key record from the DNS zone example.com, that the 704 legitimate holder of the DNS zone example.com claims responsibility 705 for the signed message. In order for this conclusion to be drawn it 706 is necessary for the verifier to assume that the operational security 707 of the DNS zone and corresponding private key are adequate. 709 3.1. Private Key Management: Deployment and Ongoing Operations 711 Access to signing keys needs to be carefully managed to prevent use 712 by unauthorized parties and to minimize the consequences if a 713 compromise were to occur. 715 While a DKIM signing key is used to sign messages on behalf of many 716 mail users, the signing key itself needs to be under direct control 717 of as few key holders as possible. If a key holder were to leave the 718 organization, all signing keys held by that key holder needs to be 719 withdrawn from service and if appropriate, replaced. 721 If key management hardware support is available, it needs to be used. 722 If keys are stored in software, appropriate file control protections 723 needs to be employed, and any location in which the private key is 724 stored in plaintext form needs to be excluded from regular backup 725 processes and is best not accessible through any form of network 726 including private local area networks. Auditing software needs to be 727 used periodically to verify that the permissions on the private key 728 files remain secure. 730 Wherever possible a signature key needs to exist in exactly one 731 location and be erased when no longer used. Ideally a signature key 732 pair needs to be generated as close to the signing point as possible 733 and only the public key component transferred to another party. If 734 this is not possible, the private key needs to be transported in an 735 encrypted format that protects the confidentiality of the signing 736 key. A shared directory on a local file system does not provide 737 adequate security for distribution of signing keys in plaintext form. 739 Key escrow schemes are not necessary and are best not used. In the 740 unlikely event of a signing key becoming lost, a new signature key 741 pair can be generated as easily as recovery from a key escrow scheme. 743 To enable accountability and auditing: 745 o Responsibility for the security of a signing key needs to 746 ultimately vest in a single named individual. 748 o Where multiple parties are authorized to sign messages, each 749 signer needs to use a different key to enable accountability and 750 auditing. 752 Best practices for management of cryptographic keying material 753 require keying material to be refreshed at regular intervals, 754 particularly where key management is achieved through software. 755 While this practice is highly desirable it is of considerably less 756 importance than the requirement to maintain the secrecy of the 757 corresponding private key. An operational practice in which the 758 private key is stored in tamper proof hardware and changed once a 759 year is considerably more desirable than one in which the signature 760 key is changed on an hourly basis but maintained in software. 762 3.2. Storing Public Keys: DNS Server Software Considerations 764 In order to use DKIM a DNS domain holder requires (1) the ability to 765 create the necessary DKIM DNS records and (2) sufficient operational 766 security controls to prevent insertion of spurious DNS records by an 767 attacker. 769 DNS record management is often operated by an administrative staff 770 that is different from those who operate an organization's email 771 service. In order to ensure that DKIM DNS records are accurate, this 772 imposes a requirement for careful coordination between the two 773 operations groups. If the best practices for private key management 774 described above are observed, such deployment is not a onetime event; 775 DNS DKIM selectors will be changed over time signing keys are 776 terminated and replaced. 778 At a minimum, a DNS server that handles queries for DKIM key records 779 needs to allow the server administrators to add free-form TXT 780 records. It would be better if the DKIM records could be entered 781 using a structured form, supporting the DKIM-specific fields. 783 Ideally DNSSEC [RFC4034] needs to be employed in a configuration that 784 provides protection against record insertion attacks and zone 785 enumeration. In the case that NSEC3 [RFC5155] records are employed 786 to prevent insertion attack, the OPT-OUT flag needs to be set clear. 788 3.2.1. Assignment of Selectors 790 Selectors are assigned according to the administrative needs of the 791 signing domain, such as for rolling over to a new key or for 792 delegating of the right to authenticate a portion of the namespace to 793 a trusted third party. Examples include: 795 jun2005.eng._domainkey.example.com 797 widget.promotion._domainkey.example.com 799 It is intended that assessments of DKIM identities be based on the 800 domain name, and not include the selector. While past practice of a 801 signer can permit a verifier to infer additional properties of 802 particular messages from the structure DKIM key selector, unannounced 803 administrative changes such as a change of signing software can cause 804 such heuristics to fail at any time. 806 3.3. Per User Signing Key Management Issues 808 While a signer can establish business rules, such as issue of 809 individual signature keys for each end-user, DKIM makes no provision 810 for communicating these to other parties. Out of band distribution 811 of such business rules is outside the scope of DKIM. Consequently 812 there is no means by which external parties can make use of such keys 813 to attribute messages with any greater granularity than a DNS domain. 815 If per-user signing keys are assigned for internal purposes (e.g. 816 authenticating messages sent to an MTA for distribution), the 817 following issues need to be considered before using such signatures 818 as an alternative to traditional edge signing at the outbound MTA: 820 External verifiers will be unable to make use of the additional 821 signature granularity without access to additional information 822 passed out of band with respect to [RFC4871]. 824 If the number of user keys is large, the efficiency of local 825 caching of key records by verifiers will be lower. 827 A large number of end users is be less likely to do an adequate 828 job of managing private key data securely on their personal 829 computers than is an administrator running an edge MTA. 831 3.4. Third Party Signer Key Management and Selector Administration 833 A DKIM key record only asserts that the holder of the corresponding 834 domain name makes a claim of responsibility for messages signed under 835 the corresponding key. In some applications, such as bulk mail 836 delivery, it is desirable to delegate use of the key. That is, to 837 allow a third party to sign on behalf of the domain holder. The 838 trust relationship is still established between the domain holder and 839 the verifier but the private signature key is held by a third party. 841 Signature keys used by a third party signer needs to be kept entirely 842 separate from those used by the domain holder and other third party 843 signers. To limit potential exposure of the private key, the 844 signature key pair needs to be generated by the third party signer 845 and the public component of the key transmitted to the domain holder, 846 rather than have the domain holder generate the key pair and transmit 847 the private component to the third party signer. 849 Domain holders needs to adopt a least privilege approach and grant 850 third party signers the minimum access necessary to perform the 851 desired function. Limiting the access granted to Third Party Signers 852 serves to protect the interests of both parties. The domain holder 853 minimizes its security risk and the Trusted Third Party Signer avoids 854 unnecessary liability. 856 In the most restrictive case a domain holder maintains full control 857 over the creation of key records and employs appropriate key record 858 restrictions to enforce restrictions on the messages for which the 859 third party signer is able to sign. If such restrictions are 860 impractical, the domain holder needs to delegate a DNS subzone for 861 publishing key records to the third party signer. It is best that 862 the domain holder NOT allow a third party signer unrestricted access 863 to its DNS service for the purpose of publishing key records. 865 3.5. Key Pair / Selector Lifecycle Management 867 Deployments need to establish, document and observe processes for 868 managing the entire lifecycle of an asymmetric key pair. 870 3.5.1. Example Key Deployment Process 872 When it is determined that a new key pair is required: 874 1. A Key Pair is generated by the signing device. 876 2. A proposed key selector record is generated and transmitted to 877 the DNS administration infrastructure. 879 3. The DNS administration infrastructure verifies the authenticity 880 of the key selector registration request. If accepted 882 1. A key selector is assigned. 884 2. The corresponding key record published in the DNS. 886 3. Wait for DNS updates to propagate (if necessary). 888 4. Report assigned key selector to signing device. 890 4. Signer verifies correct registration of the key record. 892 5. Signer begins generating signatures using the new key pair. 894 6. Signer terminates any private keys that are no longer required 895 due to issue of replacement. 897 3.5.2. Example Key Termination Process 899 When it is determined that a private signature key is no longer 900 required: 902 1. Signer stops using the private key for signature operations. 904 2. Signer deletes all records of the private key, including in- 905 memory copies at the signing device. 907 3. Signer notifies the DNS administration infrastructure that the 908 signing key is withdrawn from service and that the corresponding 909 key records can be withdrawn from service at a specified future 910 date. 912 4. The DNS administration infrastructure verifies the authenticity 913 of the key selector termination request. If accepted, 915 1. The key selector is scheduled for deletion at a future time 916 determined by site policy. 918 2. Wait for deletion time to arrive. 920 3. The signer either publishes a revocation key selector with an 921 empty public-key data ("p=") field, or deletes the key 922 selector record entirely. 924 5. As far as the verifier is concerned, there is no functional 925 difference between verifying against a key selector with an empty 926 "p=" field, and verifying against a missing key selector: both 927 result in a failed signature and the signature needs to be 928 treated as if it had not been there. However, there is a minor 929 semantic difference: with the empty "p=" field, the signer is 930 explicitly stating that the key has been revoked. The empty "p=" 931 record provides a gravestone for an old selector, making it less 932 likely that the selector might be accidentally reused with a 933 different public key. 935 4. Signing 937 Creating messages that have one or more DKIM signatures, requires 938 support in only two outbound email service components: 940 o A DNS Administrative interface that can create and maintain the 941 relevant DNS names -- including names with underscores -- and 942 resource records (RR). 944 o A trusted module, called the Signing Module, which is within the 945 organization's outbound email handling service and which creates 946 and adds the DKIM-Signature: header field(s) to the message. 948 If the module creates more than one signature, there needs to be the 949 appropriate means of telling it which one(s) to use. If a large 950 number of names are used for signing, it will help to have the 951 administrative tool support a batch processing mode. 953 4.1. DNS Records 955 A receiver attempting to verify a DKIM signature obtains the public 956 key that is associated with the signature for that message. The 957 DKIM-Signature: header in the message contains the d= tag with the 958 basic domain name doing the signing and serving as output to the 959 Identity Assessor, and the s= tag with the selector that is added to 960 the name, for finding the specific public key. Hence, the relevant 961 ._domainkey. DNS record needs to contain a 962 DKIM-related RR that provides the public key information. 964 The administrator of the zone containing the relevant domain name 965 adds this information. Initial DKIM DNS information is contained 966 within TXT RRs. DNS administrative software varies considerably in 967 its abilities to support DKIM names, such as with underscores, and to 968 add new types of DNS information. 970 4.2. Signing Module 972 The module doing signing can be placed anywhere within an 973 organization's trusted Administrative Management Domain (ADMD); 974 obvious choices include department-level posting agents, as well as 975 outbound boundary MTAs to the open Internet. However any other 976 module, including the author's MUA, is potentially acceptable, as 977 long as the signature survives any remaining handling within the 978 ADMD. Hence the choice among the modules depends upon software 979 development, administrative overhead, security exposures and transit 980 handling tradeoffs. One perspective that helps to resolve this 981 choice is the difference between the increased flexibility, from 982 placement at (or close to) the MUA, versus the streamlined 983 administration and operation, that is more easily obtained by 984 implementing the mechanism "deeper" into the organization's email 985 infrastructure, such as at its boundary MTA. 987 Note the discussion in Section 2.2, concerning use of the i= tag. 989 The signing module uses the appropriate private key to create one or 990 more signatures. (See Section 6.5 for a discussion of multiple 991 signatures.) The means by which the signing module obtains the 992 private key(s) is not specified by DKIM. Given that DKIM is intended 993 for use during email transit, rather than for long-term storage, it 994 is expected that keys will be changed regularly. For administrative 995 convenience, it is best not to hard-code key information into 996 software. 998 4.3. Signing Policies and Practices 1000 Every organization (ADMD) will have its own policies and practices 1001 for deciding when to sign messages (message stream) and with what 1002 domain name, selector and key. Examples of particular message 1003 streams include all mail sent from the ADMD, versus mail from 1004 particular types of user accounts, versus mail having particular 1005 types of content. Given this variability, and the likelihood that 1006 signing practices will change over time, it will be useful to have 1007 these decisions represented through run-time configuration 1008 information, rather than being hard-coded into the signing software. 1010 As noted in Section 2.3, the choice of signing name granularity 1011 requires balancing administrative convenience and utility for 1012 recipients. Too much granularity is higher administrative overhead 1013 and well might attempt to impose more differential analysis on the 1014 recipient than they wish to support. In such cases, they are likely 1015 to use only a super-name -- right-hand substring -- of the signing 1016 name. When this occurs, the signer will not know what portion is 1017 being used; this then moves DKIM back to the non-deterministic world 1018 of heuristics, rather than the mechanistic world of signer/recipient 1019 collaboration that DKIM seeks. 1021 5. Verifying 1023 A message recipient can verify a DKIM signature to determine if a 1024 claim of responsibility has been made for the message by a trusted 1025 domain. 1027 Access control requires two components: authentication and 1028 authorization. By design, verification of a DKIM signature only 1029 provides the authentication component of an access control decision 1030 and needs to be combined with additional sources of information such 1031 as reputation data to arrive at an access control decision. 1033 5.1. Intended Scope of Use 1035 DKIM requires that a message with a signature that is found to be 1036 invalid is to be treated as if the message had not been signed at 1037 all. 1039 If a DKIM signature fails to verify, it is entirely possible that the 1040 message is valid and that either there is a configuration error in 1041 the signer's system (e.g. a missing key record) or that the message 1042 was inadvertently modified in transit. It is thus undesirable for 1043 mail infrastructure to treat messages with invalid signatures less 1044 favorably than those with no signatures whatsoever. Contrariwise, 1045 creation of an invalid signature requires a trivial amount of effort 1046 on the part of an attacker. If messages with invalid signatures were 1047 to be treated preferentially to messages with no signatures 1048 whatsoever, attackers will simply add invalid signature blocks to 1049 gain the preferential treatment. It follows that messages with 1050 invalid signatures need to be treated no better and no worse than 1051 those with no signature at all. 1053 5.2. Signature Scope 1055 As with any other digital signature scheme, verifiers need to 1056 consider only the part of the message that is inside the scope of the 1057 message as being authenticated by the signature. 1059 For example, if the l= option is employed to specify a content length 1060 for the scope of the signature, only the part of the message that is 1061 within the scope of the content signature would be considered 1062 authentic. 1064 5.3. Design Scope of Use 1066 Public Key cryptography provides an exceptionally high degree of 1067 assurance, bordering on absolute certainty, that the party that 1068 created a valid digital signature had access to the private key 1069 corresponding to the public key indicated in the signature. 1071 In order to make useful conclusions from the verification of a valid 1072 digital signature, the verifier is obliged to make assumptions that 1073 fall far short of absolute certainty. Consequently, mere validation 1074 of a DKIM signature does not represent proof positive that a valid 1075 claim of responsibility was made for it by the indicated party, that 1076 the message is authentic, or that the message is not abusive. In 1077 particular: 1079 o The legitimate private key holder might have lost control of its 1080 private key. 1082 o The legitimate domain holder might have lost control of the DNS 1083 server for the zone from which the key record was retrieved. 1085 o The key record might not have been delivered from the legitimate 1086 DNS server for the zone from which the key record was retrieved. 1088 o Ownership of the DNS zone might have changed. 1090 In practice these limitations have little or no impact on the field 1091 of use for which DKIM is designed but can have a bearing if use is 1092 made of the DKIM message signature format or key retrieval mechanism 1093 in other specifications. 1095 In particular the DKIM key retrieval mechanism is designed for ease 1096 of use and deployment rather than to provide a high assurance Public 1097 Key Infrastructure suitable for purposes that require robust non- 1098 repudiation such as establishing legally binding contracts. 1099 Developers seeking to extend DKIM beyond its design application needs 1100 to consider replacing or supplementing the DNS key retrieval 1101 mechanism with one that is designed to meet the intended purposes. 1103 5.4. Inbound Mail Filtering 1105 DKIM is frequently employed in a mail filtering strategy to avoid 1106 performing content analysis on email originating from trusted 1107 sources. Messages that carry a valid DKIM signature from a trusted 1108 source can be whitelisted, avoiding the need to perform computation 1109 and hence energy intensive content analysis to determine the 1110 disposition of the message. 1112 Mail sources can be determined to be trusted by means of previously 1113 observed behavior and/or reference to external reputation or 1114 accreditation services. The precise means by which this is 1115 accomplished is outside the scope of DKIM. 1117 5.4.1. Non-Verifying Adaptive Spam Filtering Systems 1119 Adaptive (or learning) spam filtering mechanisms that are not capable 1120 of verifying DKIM signatures need to, at minimum, be configured to 1121 ignore DKIM header data entirely. 1123 5.5. Messages sent through Mailing Lists and other Intermediaries 1125 Intermediaries such as mailing lists pose a particular challenge for 1126 DKIM implementations, as the message processing steps performed by 1127 the intermediary can cause the message content to change in ways that 1128 prevent the signature passing verification. 1130 Such intermediaries are strongly encouraged to deploy DKIM signing so 1131 that a verifiable claim of responsibility remains available to 1132 parties attempting to verify the modified message. 1134 5.6. Generation, Transmission and Use of Results Headers 1136 In many deployments it is desirable to separate signature 1137 verification from the application relying on the verification. A 1138 system can choose to relay information indicating the results of its 1139 message authentication efforts using various means; adding a "results 1140 header" to the message is one such mechanism. [RFC5451] For example, 1141 consider the cases where: 1143 o The application relying on DKIM signature verification is not 1144 capable of performing the verification. 1146 o The message can be modified after the signature verification is 1147 performed. 1149 o The signature key can not be available by the time that the 1150 message is read. 1152 In such cases it is important that the communication link between the 1153 signature verifier and the relying application be sufficiently secure 1154 to prevent insertion of a message that carries a bogus results 1155 header. 1157 An intermediary that generates results headers need to ensure that 1158 relying applications are able to distinguish valid results headers 1159 issued by the intermediary from those introduced by an attacker. For 1160 example, this can be accomplished by signing the results header. At 1161 a minimum, results headers on incoming messages need to be removed if 1162 they purport to have been issued by the intermediary but cannot be 1163 verified as authentic. 1165 Further discussion on trusting the results as relayed from a verifier 1166 to something downstream can be found in [RFC5451] 1168 6. Taxonomy of Signatures 1170 As described in section Section 2.1, a DKIM signature tells the 1171 signature verifier that the owner of a particular domain name accepts 1172 some responsibility for the message. It does not, in and of itself, 1173 provide any information about the trustworthiness or behavior of that 1174 identity. What it does provide is a verified identity to which such 1175 behavioral information can be associated, so that those who collect 1176 and use such information can be assured that it truly pertains to the 1177 identity in question. 1179 This section lays out a taxonomy of some of the different identities, 1180 or combinations of identities, that might usefully be represented by 1181 a DKIM signature. 1183 6.1. Single Domain Signature 1185 Perhaps the simplest case is when an organization signs its own 1186 outbound email using its own domain in the SDID [RFC5672] of the 1187 signature. For example, Company A would sign the outbound mail from 1188 its employees with d=companyA.example. 1190 In the most straightforward configuration, the addresses in the 1191 RFC5322.From would also be in the companyA.example domain, but that 1192 direct correlation is not required. 1194 A special case of the Single Domain Signature is an Author Signature 1195 as defined by the Author Domain Signing Practices specification 1196 [RFC5617]. Author signatures are signatures from an author's 1197 organization that have an SDID value that matches that of an 1198 RFC5322.From address of the signed message. 1200 Although an author signature might in some cases be proof against 1201 spoofing the domain name of the RFC5322.From address, it is important 1202 to note that the DKIM and ADSP validation apply only to the exact 1203 address string and not to look-alike addresses nor to the human- 1204 friendly "display-name" or names and addresses used within the body 1205 of the message. That is, it protects only against the misuse of a 1206 precise address string within the RFC5322.From field and nothing 1207 else. For example, a message from bob@domain.example with a valid 1208 signature where d=d0main.example would fail an ADSP check because the 1209 signature domain, however similar, is distinct; however a message 1210 from bob@d0main.example with a valid signature where d=d0main.example 1211 would pass an ADSP check, even though to a human it might be obvious 1212 that d0main.example is likely a malicious attempt to spoof the domain 1213 domain.example. This example highlights that ADSP, like DKIM, is 1214 only able to validate a signing identifier: it still requires some 1215 external process to attach a meaningful reputation to that 1216 identifier. 1218 6.2. Parent Domain Signature 1220 Another approach that might be taken by an organization with multiple 1221 active subdomains is to apply the same (single) signature domain to 1222 mail from all subdomains. In this case, the signature chosen would 1223 usually be the signature of a parent domain common to all subdomains. 1224 For example, mail from marketing.domain.example, 1225 sales.domain.example, and engineering.domain.example might all use a 1226 signature where d=domain.example. 1228 This approach has the virtue of simplicity, but it is important to 1229 consider the implications of such a choice. As discussed in 1230 Section 2.3, if the type of mail sent from the different subdomains 1231 is significantly different or if there is reason to believe that the 1232 reputation of the subdomains would differ, then it can be a good idea 1233 to acknowledge this and provide distinct signatures for each of the 1234 subdomains (d=marketing.domain.example, sales.domain.example, etc.). 1235 However, if the mail and reputations are likely to be similar, then 1236 the simpler approach of using a single common parent domain in the 1237 signature can work well. 1239 Another approach to distinguishing the streams using a single DKIM 1240 key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM 1241 signature to differentiate the mail streams. For example, marketing 1242 email would be signed with i=@marketing.domain.example and 1243 d=domain.example. 1245 It's important to remember, however, that under core DKIM semantics 1246 the AUID is opaque to receivers. That means that it will only be an 1247 effective differentiator if there is an out of band agreement about 1248 the i= semantics. 1250 6.3. Third Party Signature 1252 A signature whose domain does not match the domain of the 1253 RFC5322.From address is sometimes referred to as a third party 1254 signature. In certain cases even the parent domain signature 1255 described above would be considered a third party signature because 1256 it would not be an exact match for the domain in the RFC5322.From 1257 address. 1259 Although there is often heated debate about the value of third party 1260 signatures, it is important to note that the DKIM specification 1261 attaches no particular significance to the identity in a DKIM 1262 signature. The identity specified within the signature is the 1263 identity that is taking responsibility for the message, and it is 1264 only the interpretation of a given receiver that gives one identity 1265 more or less significance than another. In particular, most 1266 independent reputation services assign trust based on the specific 1267 identifier string, not its "role": in general they make no 1268 distinction between, for example, an author signature and a third 1269 party signature. 1271 For some, a signature unrelated to the author domain (the domain in 1272 the RFC5322.From address) is less valuable because there is an 1273 assumption that the presence of an author signature guarantees that 1274 the use of the address in the RFC5322.From header is authorized. 1276 For others, that relevance is tied strictly to the recorded 1277 behavioral data assigned to the identity in question, i.e. its trust 1278 assessment or reputation. The reasoning here is that an identity 1279 with a good reputation is unlikely to maintain that good reputation 1280 if it is in the habit of vouching for messages that are unwanted or 1281 abusive; in fact, doing so will rapidly degrade its reputation so 1282 that future messages will no longer benefit from it. It is therefore 1283 low risk to facilitate the delivery of messages that contain a valid 1284 signature of a domain with a strong positive reputation, independent 1285 of whether or not that domain is associated with the address in the 1286 RFC5322.From header field of the message. 1288 Third party signatures encompass a wide range of identities. Some of 1289 the more common are: 1291 Service Provider: In cases where email is outsourced to an Email 1292 Service Provider (ESP), Internet Service Provider (ISP), or other 1293 type of service provider, that service provider can choose to DKIM 1294 sign outbound mail with either its own identifier -- relying on 1295 its own, aggregate reputation -- or with a subdomain of the 1296 provider that is unique to the message author but still part of 1297 the provider's aggregate reputation. Such service providers can 1298 also encompass delegated business functions such as benefit 1299 management, although these will more often be treated as trusted 1300 third party senders (see below). 1302 Parent Domain. As discussed above, organizations choosing to apply a 1303 parent domain signature to mail originating from subdomains can 1304 have their signatures treated as third party by some verifiers, 1305 depending on whether or not the "t=s" tag is used to constrain the 1306 parent signature to apply only to its own specific domain. The 1307 default is to consider a parent domain signature valid for its 1308 subdomains. 1310 Reputation Provider: Another possible category of third party 1311 signature would be the identity of a third party reputation 1312 provider. Such a signature would indicate to receivers that the 1313 message was being vouched for by that third party. 1315 6.4. Using Trusted Third Party Senders 1317 For most of the cases described so far, there has been an assumption 1318 that the signing agent was responsible for creating and maintaining 1319 its own DKIM signing infrastructure, including its own keys, and 1320 signing with its own identity. 1322 A different model arises when an organization uses a trusted third 1323 party sender for certain key business functions, but still wants that 1324 email to benefit from the organization's own identity and reputation: 1325 in other words, the mail would come out of the trusted third party's 1326 mail servers, but the signature applied would be that of the 1327 controlling organization. 1329 This can be done by having the third party generate a key pair that 1330 is designated uniquely for use by that trusted third party and 1331 publishing the public key in the controlling organization's DNS 1332 domain, thus enabling the third party to sign mail using the 1333 signature of the controlling organization. For example, if Company A 1334 outsources its employee benefits to a third party, it can use a 1335 special key pair that enables the benefits company to sign mail as 1336 "companyA.example". Because the key pair is unique to that trusted 1337 third party, it is easy for Company A to revoke the authorization if 1338 necessary by simply removing the public key from the companyA.example 1339 DNS. 1341 A more cautious approach would be to create a dedicated subdomain 1342 (e.g. benefits.companyA.example) to segment the outsourced mail 1343 stream, and to publish the public key there; the signature would then 1344 use d=benefits.companyA.example. 1346 6.4.1. DNS Delegation 1348 Another possibility for configuring trusted third party access, as 1349 discussed in section 3.4, is to have Company A use DNS delegation and 1350 have the designated subdomain managed directly by the trusted third 1351 party. In this case, Company A would create a subdomain 1352 benefits.companya.example, and delegate the DNS management of that 1353 subdomain to the benefits company so it could maintain its own key 1354 records. When revocation becomes necessary, Company A could simply 1355 remove the DNS delegation record. 1357 6.5. Multiple Signatures 1359 A simple configuration for DKIM-signed mail is to have a single 1360 signature on a given message. This works well for domains that 1361 manage and send all of their own email from single sources, or for 1362 cases where multiple email streams exist but each has its own unique 1363 key pair. It also represents the case in which only one of the 1364 participants in an email sequence is able to sign, no matter whether 1365 it represents the author or one of the operators. 1367 The examples thus far have considered the implications of using 1368 different identities in DKIM signatures, but have used only one such 1369 identity for any given message. In some cases, it can make sense to 1370 have more than one identity claiming responsibility for the same 1371 message. 1373 There are a number of situations where applying more than one DKIM 1374 signature to the same message might make sense. A few examples are: 1376 Companies with multiple subdomain identities: A company that has 1377 multiple subdomains sending distinct categories of mail might 1378 choose to sign with distinct subdomain identities to enable each 1379 subdomain to manage its own identity. However, it might also want 1380 to provide a common identity that cuts across all of the distinct 1381 subdomains. For example, Company A can sign mail for its sales 1382 department with a signature where d=sales.companya.example, and a 1383 second signature where d=companya.example 1385 Service Providers: Service providers can, as described above, choose 1386 to sign outbound messages with either its own identity or with an 1387 identity unique to each of its clients (possibly delegated). 1388 However, it can also do both: sign each outbound message with its 1389 own identity as well as with the identity of each individual 1390 client. For example, ESP A might sign mail for its client Company 1391 B with its service provider signature d=espa.example, and a second 1392 client-specific signature where d= either companyb.example, or 1393 companyb.espa.example. The existence of the service provider 1394 signature could, for example, help cover a new client while it 1395 establishes its own reputation, or help a very small volume client 1396 who might never reach a volume threshold sufficient to establish 1397 an individual reputation. 1399 Forwarders Forwarded mail poses a number of challenges to email 1400 authentication. DKIM is relatively robust in the presence of 1401 forwarders as long as the signature is designed to avoid message 1402 parts that are likely to be modified; however, some forwarders do 1403 make modifications that can invalidate a DKIM signature. 1405 Some forwarders such as mailing lists or "forward article to a 1406 friend" services might choose to add their own signatures to 1407 outbound messages to vouch for them having legitimately originated 1408 from the designated service. In this case, the signature would be 1409 added even in the presence of a preexisting signature, and both 1410 signatures would be relevant to the verifier. 1412 Any forwarder that modifies messages in ways that will break 1413 preexisting DKIM signatures needs to sign its forwarded messages. 1415 Reputation Providers: Although third party reputation providers 1416 today use a variety of protocols to communicate their information 1417 to receivers, it is possible that they, or other organizations 1418 willing to put their "seal of approval" on an email stream, might 1419 choose to use a DKIM signature to do it. In nearly all cases, 1420 this "reputation" signature would be in addition to the author or 1421 originator signature. 1423 One important caveat to the use of multiple signatures is that there 1424 is currently no clear consensus among receivers on how they plan to 1425 handle them. The opinions range from ignoring all but one signature 1426 (and the specification of which of them is verified differs from 1427 receiver to receiver), to verifying all signatures present and 1428 applying a weighted blend of the trust assessments for those 1429 identifiers, to verifying all signatures present and simply using the 1430 identifier that represents the most positive trust assessment. It is 1431 likely that the industry will evolve to accept multiple signatures 1432 using either the second or third of these, but it can take some time 1433 before one approach becomes pervasive. 1435 7. Example Usage Scenarios 1437 Signatures are created by different types of email actors, based on 1438 different criteria, such as where the actor operates in the sequence 1439 from author to recipient, whether they want different messages to be 1440 evaluated under the same reputation or a different one, and so on. 1441 This section provides some examples of usage scenarios for DKIM 1442 deployments; the selection is not intended to be exhaustive, but to 1443 illustrate a set of key deployment considerations. 1445 7.1. Author's Organization - Simple 1447 The simplest DKIM configuration is to have some mail from a given 1448 organization (Company A) be signed with the same d= value (e.g. 1449 d=companya.example). If there is a desire to associate additional 1450 information, the AUID [RFC5672] value can become 1451 uniqueID@companya.example, or @uniqueID.companya.example. 1453 In this scenario, Company A need only generate a single signing key 1454 and publish it under their top level domain (companya.example); the 1455 signing module would then tailor the AUID value as needed at signing 1456 time. 1458 7.2. Author's Organization - Differentiated Types of Mail 1460 A slight variation of the one signature case is where Company A signs 1461 some of its mail, but it wants to differentiate different categories 1462 of its outbound mail by using different identifiers. For example, it 1463 might choose to distinguish marketing mail, billing or transactional 1464 mail, and individual corporate email into marketing.companya.example, 1465 billing.companya.example, and companya.example, where each category 1466 is assigned a unique subdomain and unique signing keys. 1468 7.3. Author Domain Signing Practices 1470 7.3.1. Introduction 1472 Some domains might decide to sign all of their outgoing mail. If all 1473 of the legitimate mail for a domain is signed, recipients can be more 1474 aggressive in their filtering of mail that uses the domain but does 1475 not have a valid signature from the domain; in such a configuration, 1476 the absence of a signature would be more significant than for the 1477 general case. It might be desirable for such domains to be able to 1478 advertise their intent to other receivers: this is the topic of 1479 Author Domain Signing Practices (ADSP). 1481 Note that ADSP is not for everyone. Sending domains that do not 1482 control all legitimate outbound mail purporting to be from their 1483 domain (i.e., with an RFC5322.From address in their domain) are 1484 likely to experience delivery problems with some percentage of that 1485 mail. Administrators evaluating ADSP for their domains needs to 1486 carefully weigh the risk of phishing attacks against the likelihood 1487 of undelivered mail. 1489 This section covers some examples of ADSP usage: for the complete 1490 specification, see [RFC5617] 1492 7.3.2. A Few Definitions 1494 In the ADSP specification, an address in the RFC5322.From header 1495 field of a message is defined as an "Author Address", and an "Author 1496 Domain" is defined as anything to the right of the '@' in an Author 1497 Address. 1499 An "Author Signature" is thus any valid signature where the value of 1500 the SDID matches an Author Domain in the message. 1502 It is important to note that unlike the DKIM specification which 1503 makes no correlation between the signature domain and any message 1504 headers, the ADSP specification applies only to the author domain. 1505 In essence, under ADSP, any non-author signatures are ignored 1506 (treated as if they are not present). 1508 Signers wishing to publish an Author Domain Signing Practices (ADSP) 1509 [RFC5617] record describing their signing practices will thus want to 1510 include an author signature on their outbound mail to avoid ADSP 1511 verification failures. 1513 7.3.3. Some ADSP Examples 1515 An organization (Company A) can specify its signing practices by 1516 publishing an ADSP record with "dkim=all" or "dkim=discardable". In 1517 order to avoid misdelivery of its mail at receivers that are 1518 validating ADSP, Company A needs to first have done an exhaustive 1519 analysis to determine all sources of outbound mail from its domain 1520 (companyA.example) and ensure that they all have valid author 1521 signatures from that domain. 1523 For example, email with an RFC5322.From address of bob@ 1524 companyA.example needs to have an author signature where the SDID 1525 value is "companyA.example" or it will fail an ADSP validation. 1527 Note that once an organization publishes an ADSP record using 1528 dkim=all or dkim=discardable, any email with an RFC5322.From address 1529 that uses the domain where the ADSP record is published that does not 1530 have a valid author signature is at risk of being misdelivered or 1531 discarded. For example, if a message with an RFC5322.From address of 1532 newsletter@companyA.example has a signature with 1533 d=marketing.companyA.example, that message will fail the ADSP check 1534 because the signature would not be considered a valid author 1535 signature. 1537 Because the semantics of an ADSP author signature are more 1538 constrained than the semantics of a "pure" DKIM signature, it is 1539 important to make sure the nuances are well understood before 1540 deploying an ADSP record. The ADSP specification [RFC5617] provides 1541 some fairly extensive lookup examples (in Appendix A) and usage 1542 examples (in Appendix B). 1544 In particular, in order to prevent mail from being negatively 1545 impacted or even discarded at the receiver, it is essential to 1546 perform a thorough survey of outbound mail from a domain before 1547 publishing an ADSP policy of anything stronger than "unknown". This 1548 includes mail that might be sent from external sources that might not 1549 be authorized to use the domain signature, as well as mail that risks 1550 modification in transit that might invalidate an otherwise valid 1551 author signature (e.g. mailing lists, courtesy forwarders, and other 1552 paths that could add or modify headers, or modify the message body). 1554 7.4. Delegated Signing 1556 An organization might choose to outsource certain key services to an 1557 independent company. For example, Company A might outsource its 1558 benefits management, or Organization B might outsource its marketing 1559 email. 1561 If Company A wants to ensure that all of the mail sent on its behalf 1562 through the benefits providers email servers shares the Company A 1563 reputation, as discussed in Section 6.4 it can either publish keys 1564 designated for the use of the benefits provider under 1565 companyA.example (preferably under a designated subdomain of 1566 companyA.example), or it can delegate a subdomain (e.g. 1567 benefits.companyA.example) to the provider and enable the provider to 1568 generate the keys and manage the DNS for the designated subdomain. 1570 In both of these cases, mail would be physically going out of the 1571 benefit provider's mail servers with a signature of e.g. 1572 d=benefits.companya.example. Note that the RFC5322.From address is 1573 not constrained: it could either be affiliated with the benefits 1574 company (e.g. benefits-admin@benefitprovider.example, or 1575 benefits-provider@benefits.companya.example), or with the companyA 1576 domain. 1578 Note that in both of the above scenarios, as discussed in 1579 Section 3.4, security concerns dictate that the keys be generated by 1580 the organization that plans to do the signing so that there is no 1581 need to transfer the private key. In other words, the benefits 1582 provider would generate keys for both of the above scenarios. 1584 7.5. Independent Third Party Service Providers 1586 Another way to manage the service provider configuration would be to 1587 have the service provider sign the outgoing mail on behalf of its 1588 client Company A with its own (provider) identifier. For example, an 1589 Email Service Provider (ESP A) might want to share its own mailing 1590 reputation with its clients, and might sign all outgoing mail from 1591 its clients with its own d= domain (e.g. d=espa.example). 1593 When the ESP want to distinguish among its clients, it has two 1594 options: 1596 o Share the SDID domain, and use the AUID value to distinguish among 1597 the clients: e.g. a signature on behalf of client A would have 1598 d=espa.example and i=@clienta.espa.example (or 1599 i=clienta@espa.example) 1601 o Extend the SDID domain, so there is a unique value (and subdomain) 1602 for each client: e.g. a signature on behalf of client A would have 1603 d=clienta.espa.example. 1605 Note that this scenario and the delegation scenario are not mutually 1606 exclusive: in some cases, it can be desirable to sign the same 1607 message with both the ESP and the ESP client identities. 1609 7.6. Mail Streams Based on Behavioral Assessment 1611 An ISP (ISP A) might want to assign signatures to outbound mail from 1612 its users according to each user's past sending behavior 1613 (reputation). In other words, the ISP would segment its outbound 1614 traffic according to its own assessment of message quality, to aid 1615 recipients in differentiating among these different streams. Since 1616 the semantics of behavioral assessments are not valid AUID values, 1617 ISP A (ispa.example) can configure subdomains corresponding to the 1618 assessment categories (e.g. good.ispa.example, neutral.ispa.example, 1619 bad.ispa.example), and use these subdomains in the d= value of the 1620 signature. 1622 The signing module can also set the AUID value to have a unique user 1623 id (distinct from the local-part of the user's email address), for 1624 example user3456@neutral.domain.example. Using a userid that is 1625 distinct from a given email alias is useful in environments where a 1626 single user might register multiple email aliases. 1628 Note that in this case the AUID values are only partially stable. 1629 They are stable in the sense that a given i= value will always 1630 represent the same identity, but they are unstable in the sense that 1631 a given user can migrate among the assessment subdomains depending on 1632 their sending behavior (i.e., the same user might have multiple AUID 1633 values over the lifetime of a single account). 1635 In this scenario, ISP A can generate as many keys as there are 1636 assessment subdomains (SDID values), so that each assessment 1637 subdomain has its own key. The signing module would then choose its 1638 signing key based on the assessment of the user whose mail was being 1639 signed, and if desired include the user id in the AUID of the 1640 signature. As discussed earlier, the per-user granularity of the 1641 AUID can be ignored by verifiers; so organizations choosing to use it 1642 ought not rely on its use for receiver side filtering results. 1643 However, some organizations might also find the information useful 1644 for their own purposes in processing bounces or abuse reports. 1646 7.7. Agent or Mediator Signatures 1648 Another scenario is that of an agent, usually a re-mailer of some 1649 kind, that signs on behalf of the service or organization that it 1650 represents. Some examples of agents might be a mailing list manager, 1651 or the "forward article to a friend" service that many online 1652 publications offer. In most of these cases, the signature is 1653 asserting that the message originated with, or was relayed by, the 1654 service asserting responsibility. In general, if the service is 1655 configured in such a way that its forwarding would break existing 1656 DKIM signatures, it needs to always add its own signature. 1658 8. Usage Considerations 1660 8.1. Non-standard Submission and Delivery Scenarios 1662 The robustness of DKIM's verification mechanism is based on the fact 1663 that only authorized signing modules have access to the designated 1664 private key. This has the side effect that email submission and 1665 delivery scenarios that originate or relay messages from outside the 1666 domain of the authorized signing module will not have access to that 1667 protected private key, and thus will be unable to attach the expected 1668 domain signature to those messages. Such scenarios include mailing 1669 lists, courtesy forwarders, MTAs at hotels, hotspot networks used by 1670 travelling users, and other paths that could add or modify headers, 1671 or modify the message body. 1673 For example, assume Joe works for Company A and has an email address 1674 joe@companya.example. Joe also has an ISP-1 account 1675 joe@isp1.example.com, and he uses ISP-1's multiple address feature to 1676 attach his work email address, joe@companya.example, to email from 1677 his ISP-1 account. When Joe sends email from his ISP-1 account and 1678 uses joe@companya.example as his designated RFC5322.From address, 1679 that email cannot have a signature with d=companya.example because 1680 the ISP-1 servers have no access to Company A's private key. In 1681 ISP-1's case it will have an ISP-1 signature, but for some other mail 1682 clients offering the same multiple address feature there might be no 1683 signature at all on the message. 1685 Another example might be the use of a forward article to a friend 1686 service. Most instances of these services today allow someone to 1687 send an article with their email address in the RFC5322.From to their 1688 designated recipient. If Joe used either of his two addresses 1689 (joe@companya.example or joe@isp1.example.com), the forwarder would 1690 be equally unable to sign with a corresponding domain. As in the 1691 mail client case, the forwarder can either sign as its own domain, or 1692 can put no signature on the message. 1694 A third example is the use of privately configured forwarding. 1695 Assume that Joe has another account at ISP-2, joe@isp-2.example.com, 1696 but he'd prefer to read his ISP-2 mail from his ISP-1 account. He 1697 sets up his ISP-2 account to forward all incoming mail to 1698 joe@isp1.example.com. Assume alice@companyb.example sends 1699 joe@isp-2.example.com an email. Depending on how companyb.example 1700 configured its signature, and depending on whether or not ISP-2 1701 modifies messages that it forwards, it is possible that when Alice's 1702 message is received in Joe's ISP-1 account the original signature 1703 fails verification. 1705 8.2. Protection of Internal Mail 1707 One identity is particularly amenable to easy and accurate 1708 assessment: the organization's own identity. Members of an 1709 organization tend to trust messages that purport to be from within 1710 that organization. However Internet Mail does not provide a 1711 straightforward means of determining whether such mail is, in fact, 1712 from within the organization. DKIM can be used to remedy this 1713 exposure. If the organization signs all of its mail, then its 1714 boundary MTAs can look for mail purporting to be from the 1715 organization that does not contain a verifiable signature. 1717 Such mail can in most cases be presumed to be spurious. However, 1718 domain managers are advised to consider the ways that mail processing 1719 can modify messages in ways that will invalidate an existing DKIM 1720 signature: mailing lists, courtesy forwarders, and other paths that 1721 could add or modify headers or modify the message body (e.g. MTAs at 1722 hotels, hotspot networks used by travelling users, and other 1723 scenarios described in the previous section). Such breakage is 1724 particularly relevant in the presence of Author Domain Signing 1725 Practices. 1727 8.3. Signature Granularity 1729 Although DKIM's use of domain names is optimized for a scope of 1730 organization-level signing, it is possible to administer sub-domains 1731 or otherwise adjust signatures in a way that supports per-user 1732 identification. This user level granularity can be specified in two 1733 ways: either by sharing the signing identity and specifying an 1734 extension to the i= value that has a per-user granularity, or by 1735 creating and signing with unique per-user keys. 1737 A subdomain or local part in the i= tag needs to be treated as an 1738 opaque identifier and thus need not correspond directly to a DNS 1739 subdomain or be a specific user address. 1741 The primary way to sign with per-user keys requires each user to have 1742 a distinct DNS (sub)domain, where each distinct d= value has a key 1743 published. (It is possible, although not advised, to publish the 1744 same key in more than one distinct domain.) 1746 It is technically possible to publish per-user keys within a single 1747 domain or subdomain by utilizing different selector values. This is 1748 not advised and is unlikely to be treated uniquely by Assessors: the 1749 primary purpose of selectors is to facilitate key management, and the 1750 DKIM specification recommends against using them in determining or 1751 assessing identities. 1753 In most cases, it would be impractical to sign email on a per-user 1754 granularity. Such an approach would be 1756 likely to be ignored: In most cases today, if receivers are 1757 verifying DKIM signatures they are in general taking the simplest 1758 possible approach. In many cases maintaining reputation 1759 information at a per-user granularity is not interesting to them, 1760 in large part because the per-user volume is too small to be 1761 useful or interesting. So even if senders take on the complexity 1762 necessary to support per-user signatures, receivers are unlikely 1763 to retain anything more than the base domain reputation. 1765 difficult to manage: Any scheme that involves maintenance of a 1766 significant number of public keys might require infrastructure 1767 enhancements or extensive administrative expertise. For domains 1768 of any size, maintaining a valid per-user keypair, knowing when 1769 keys need to be revoked or added due to user attrition or 1770 onboarding, and the overhead of having the signing engine 1771 constantly swapping keys can create significant and often 1772 unnecessary management complexity. It is also important to note 1773 that there is no way within the scope of the DKIM specification 1774 for a receiver to infer that a sender intends a per-user 1775 granularity. 1777 As mentioned before, what might make sense, however, is to use the 1778 infrastructure that enables finer granularity in signatures to 1779 identify segments smaller than a domain but much larger than a per- 1780 user segmentation. For example, a university might want to segment 1781 student, staff, and faculty mail into three distinct streams with 1782 differing reputations. This can be done by creating separate sub- 1783 domains for the desired segments, and either specifying the 1784 subdomains in the i= tag of the DKIM Signature or by adding 1785 subdomains to the d= tag and assigning and signing with different 1786 keys for each subdomain. 1788 For those who choose to represent user level granularity in 1789 signatures, the performance and management considerations above 1790 suggest that it would be more effective to do it by specifying a 1791 local part or subdomain extension in the i= tag rather than by 1792 extending the d= domain and publishing individual keys. 1794 8.4. Email Infrastructure Agents 1796 It is expected that the most common venue for a DKIM implementation 1797 will be within the infrastructure of an organization's email service, 1798 such as a department or a boundary MTA. What follows are some 1799 general recommendations for the Email Infrastructure. 1801 Outbound: An MSA or an Outbound MTA used for mail submission 1802 needs to ensure that the message sent is in compliance with the 1803 advertised email sending policy. It needs to also be able to 1804 generate an operator alert if it determines that the email 1805 messages do not comply with the published DKIM sending policy. 1807 An MSA needs to be aware that some MUAs might add their own 1808 signatures. If the MSA needs to perform operations on a 1809 message to make it comply with its email sending policy, if at 1810 all possible, it needs to do so in a way that would not break 1811 those signatures. 1813 MUAs equipped with the ability to sign ought not to be 1814 encouraged. In terms of security, MUAs are generally not under 1815 the direct control of those in responsible roles within an 1816 organization and are thus more vulnerable to attack and 1817 compromise, which would expose private signing keys to 1818 intruders and thus jeopardize the integrity and reputation of 1819 the organization. 1821 Inbound: When an organization deploys DKIM, it needs to make 1822 sure that its email infrastructure components that do not have 1823 primary roles in DKIM handling do not modify message in ways 1824 that prevent subsequent verification. 1826 An inbound MTA or an MDA can incorporate an indication of the 1827 verification results into the message, such as using an 1828 Authentication-Results header field. [RFC5451] 1830 Intermediaries: An email intermediary is both an inbound and 1831 outbound MTA. Each of the requirements outlined in the 1832 sections relating to MTAs apply. If the intermediary modifies 1833 a message in a way that breaks the signature, the intermediary 1834 + needs to deploy abuse filtering measures on the inbound 1835 mail, and 1837 + probably also needs to remove all signatures that will be 1838 broken 1840 In addition the intermediary can: 1842 + Verify the message signature prior to modification. 1844 + Incorporate an indication of the verification results into 1845 the message, such as using an Authentication-Results header 1846 field. [RFC5451] 1848 + Sign the modified message including the verification results 1849 (e.g., the Authentication-Results header field). 1851 8.5. Mail User Agent 1853 The DKIM specification is expected to be used primarily between 1854 Boundary MTAs, or other infrastructure components of the originating 1855 and receiving ADMDs. However there is nothing in DKIM that is 1856 specific to those venues. In particular, MUAs can also support DKIM 1857 signing and verifying directly. 1859 Outbound: An MUA can support signing even if mail is to be 1860 relayed through an outbound MSA. In this case the signature 1861 applied by the MUA will be in addition to any signature added 1862 by the MSA. However, the warnings in the previous section need 1863 to be taken into consideration. 1865 Some user software goes beyond simple user functionality and 1866 also performs MSA and MTA functions. When this is employed for 1867 sending directly to a receiving ADMD, the user software needs 1868 to be considered an outbound MTA. 1870 Inbound: An MUA can rely on a report of a DKIM signature 1871 verification that took place at some point in the inbound MTA/ 1872 MDA path (e.g., an Authentication-Results header field), or an 1873 MUA can perform DKIM signature verification directly. A 1874 verifying MUA needs to allow for the case where mail has 1875 modified in the inbound MTA path; if a signature fails, the 1876 message is to be treated the same as a message which does not 1877 have a signature. 1879 An MUA that looks for an Authentication-Results header field 1880 needs to be configurable to choose which Authentication-Results 1881 are considered trustable. The MUA developer is encouraged to 1882 re-read the Security Considerations of [RFC5451]. 1884 DKIM requires that all verifiers treat messages with signatures 1885 that do not verify as if they are unsigned. 1887 If verification in the client is to be acceptable to users, it 1888 is essential that successful verification of a signature not 1889 result in a less than satisfactory user experience compared to 1890 leaving the message unsigned. The mere presence of a verified 1891 DKIM signature cannot be used by itself by an MUA to indicate 1892 that a message is to be treated better than a message without a 1893 verified DKIM signature. However, the fact that a DKIM 1894 signature was verified can be used as input into a reputation 1895 system (i.e., a whitelist of domains and users) for 1896 presentation of such indicators. 1898 It is common for components of an ADMD's email infrastructure to do 1899 violence to a message, such that a DKIM signature might be rendered 1900 invalid. Hence, users of MUAs that support DKIM signing and/or 1901 verifying need a basis for knowing that their associated email 1902 infrastructure will not break a signature. 1904 9. Other Considerations 1906 9.1. Security Considerations 1908 The security considerations of the DKIM protocol are described in the 1909 DKIM base specification [RFC4871]. 1911 9.2. IANA Considerations 1913 This document has no considerations for IANA. 1915 10. Acknowledgements 1917 The effort of the DKIM Working Group is gratefully acknowledged. 1919 11. References 1920 11.1. Normative References 1922 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1923 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1924 Signatures", RFC 4871, May 2007. 1926 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1927 October 2008. 1929 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 1930 Message Authentication Status", RFC 5451, April 2009. 1932 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1933 Identified Mail (DKIM) Service Overview", RFC 5585, 1934 July 2009. 1936 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 1937 "DomainKeys Identified Mail (DKIM) Author Domain Signing 1938 Practices (ADSP)", RFC 5617, August 2009. 1940 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1941 Signatures -- Update", RFC 5672, August 2009. 1943 11.2. Informative References 1945 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1946 Rose, "Resource Records for the DNS Security Extensions", 1947 RFC 4034, March 2005. 1949 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 1950 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1951 May 2007. 1953 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1954 Security (DNSSEC) Hashed Authenticated Denial of 1955 Existence", RFC 5155, March 2008. 1957 Appendix A. Migration Strategies 1959 There are three migration occasions worth noting in particular for 1960 DKIM: 1962 1. Migrating from Domain Keys to DKIM. 1964 2. Migrating from a current hash algorithm to a new standardized 1965 hash algorithm. 1967 3. Migrating from a current signing algorithm to a new standardized 1968 signing algorithm. 1970 The case of deploying a new key selector record is described 1971 elsewhere (Section 3.5). 1973 As with any migration, the steps required will be determined by who 1974 is doing the migration and their assessment of 1976 o the users of what they are generating, or 1978 o the providers of what they are consuming. 1980 Signers and verifiers have different considerations. 1982 A.1. Migrating from DomainKeys 1984 DKIM replaces the earlier DomainKeys (DK) specification. Selector 1985 files are mostly compatible between the two specifications. 1987 A.1.1. Signers 1989 A signer that currently signs with DK will go through various stages 1990 as it migrates to using DKIM, not all of which are required for all 1991 signers. The real questions that a signer needs to ask are: 1993 1. how many receivers or what types of receivers are *only* looking 1994 at the DK signatures and not the DKIM signatures, and 1996 2. how much does the signer care about those receivers? 1998 If no one is looking at the DK signature any more, then it's no 1999 longer necessary to sign with DK. Or if all "large players" are 2000 looking at DKIM in addition to or instead of DK, a signer can choose 2001 to stop signing with DK. 2003 With respect to signing policies, a reasonable, initial approach is 2004 to use DKIM signatures in the same way as DomainKeys signatures are 2005 already being used. In particular, the same selectors and DNS Key 2006 Records can be used for both, after verifying that they are 2007 compatible as discussed below. 2009 Each secondary step in all of the following scenarios is to be 2010 prefaced with the gating factor "test, then when comfortable with the 2011 previous step's results, continue". 2013 One migration strategy is to: 2015 o ensure that the current selector DNS key record is compatible with 2016 both DK and DKIM 2018 o sign messages with both DK and DKIM signatures 2020 o when it's decided that DK signatures are no longer necessary, stop 2021 signing with DK 2023 Another migration strategy is to: 2025 o add a new selector DNS key record only for DKIM signatures 2027 o sign messages with both DK (using the old DNS key record) and DKIM 2028 signatures (using the new DNS key record) 2030 o when it's decided that DK signatures are no longer necessary, stop 2031 signing with DK 2033 o eventually remove the old DK selector DNS record 2035 A combined migration strategy is to: 2037 o ensure that the current selector DNS key record is compatible with 2038 both DK and DKIM 2040 o start signing messages with both DK and DKIM signatures 2042 o add a new selector DNS key record for DKIM signatures 2044 o switch the DKIM signatures to use the new selector 2046 o when it's decided that DK signatures are no longer necessary, stop 2047 signing with DK 2049 o eventually remove the old DK selector DNS record 2051 Another migration strategy is to: 2053 o add a new selector DNS key record for DKIM signatures 2055 o do a flash cut and replace the DK signatures with DKIM signatures 2057 o eventually remove the old DK selector DNS record 2059 Another migration strategy is to: 2061 o ensure that the current selector DNS key record is compatible with 2062 both DK and DKIM 2064 o do a flash cut and replace the DK signatures with DKIM signatures 2066 Note that when you have separate key records for DK and DKIM, you can 2067 use the same public key for both. 2069 A.1.1.1. DNS Selector Key Records 2071 The first step in some of the above scenarios is ensuring that the 2072 selector DNS key records are compatible for both DK and DKIM. The 2073 format of the DNS key record was intentionally meant to be backwardly 2074 compatible between the two systems, but not necessarily upwardly 2075 compatible. DKIM has enhanced the DK DNS key record format by adding 2076 several optional parameters, which DK needs to ignore. However, 2077 there is one critical difference between DK and DKIM DNS key records: 2078 the definitions of the "g" fields: 2080 g= granularity of the key In both DK and DKIM, this is an optional 2081 field that is used to constrain which sending address(es) can 2082 legitimately use this selector. Unfortunately, the treatment of 2083 an empty field ("g=;") is different. DKIM allows wildcards where 2084 DK does not. For DK, an empty field is the same as a missing 2085 value, and is treated as allowing any sending address. For DKIM, 2086 an empty field only matches an empty local part. In DKIM, both a 2087 missing value and "g=*;" mean to allow any sending address. 2089 Also, in DomainKeys, the g= field is required to match the address 2090 in "From:"/"Sender:", while in DKIM, it is required to match i= . 2091 This might or might not affect transition. 2093 If your DK DNS key record has an empty "g" field in it ("g=;"), 2094 your best course of action is to modify the record to remove the 2095 empty field. In that way, the DK semantics will remain the same, 2096 and the DKIM semantics will match. 2098 If your DNS key record does not have an empty "g" field in it 2099 ("g=;"), it's probable that the record can be left alone. But the 2100 best course of action would still be to make sure that it has a 2101 "v" field. When the decision is made to stop supporting 2102 DomainKeys and to only support DKIM, it is important to verify 2103 that the "g" field is compatible with DKIM, and typically having 2104 "v=DKIM1;" in it. It is strongly encouraged that if use of an 2105 empty "g" field in the DKIM selector, include the "v" field. 2107 A.1.1.2. Removing DomainKeys Signatures 2109 The principal use of DomainKeys is at Boundary MTAs. Because no 2110 operational transition is ever instantaneous, it is advisable to 2111 continue performing DomainKeys signing until it is determined that 2112 DomainKeys receive-side support is no longer used, or is sufficiently 2113 reduced. That is, a signer needs to add a DKIM signature to a 2114 message that also has a DomainKeys signature and keep it there until 2115 they decide it is deemed no longer useful. The signer can do its 2116 transitions in a straightforward manner, or more gradually. Note 2117 that because digital signatures are not free, there is a cost to 2118 performing both signing algorithms, so signing with both algorithms 2119 ought not be needlessly prolonged. 2121 The tricky part is deciding when DK signatures are no longer 2122 necessary. The real questions are: how many DomainKeys verifiers are 2123 there that do *not* also do DKIM verification, which of those are 2124 important, and how can you track their usage? Most of the early 2125 adopters of DK verification have added DKIM verification, but not all 2126 yet. If a verifier finds a message with both DK and DKIM, it can 2127 choose to verify both signatures, or just one or the other. 2129 Many DNS services offer tracking statistics so it can be determined 2130 how often a DNS record has been accessed. By using separate DNS 2131 selector key records for your signatures, you can chart the usage of 2132 your records over time, and watch the trends. An additional 2133 distinguishing factor to track would take into account the verifiers 2134 that verify both the DK and DKIM signatures, and discount those from 2135 counts of DK selector usage. When the number for DK selector access 2136 reaches a low-enough level, that's the time to consider discontinuing 2137 signing with DK. 2139 Note, this level of rigor is not required. It is perfectly 2140 reasonable for a DK signer to decide to follow the "flash cut" 2141 scenario described above. 2143 A.1.2. Verifiers 2145 As a verifier, several issues needs to be considered: 2147 A.1.2.1. Ought DK signature verification be performed? 2149 At the time of writing, there is still a significant number of sites 2150 that are only producing DK signatures. Over time, it is expected 2151 that this number will go to zero, but it might take several years. 2152 So it would be prudent for the foreseeable future for a verifier to 2153 look for and verify both DKIM and DK signatures. 2155 A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single 2156 message? 2158 For a period of time, there will be sites that sign with both DK and 2159 DKIM. A verifier receiving a message that has both types of 2160 signatures can verify both signatures, or just one. One disadvantage 2161 of verifying both signatures is that signers will have a more 2162 difficult time deciding how many verifiers are still using their DK 2163 selectors. One transition strategy is to verify the DKIM signature, 2164 then only verify the DK signature if the DKIM verification fails. 2166 A.1.2.3. DNS Selector Key Records 2168 The format of the DNS key record was intentionally meant to be 2169 backwardly compatible between DK and DKIM, but not necessarily 2170 upwardly compatible. DKIM has enhanced the DK DNS key record format 2171 by adding several optional parameters, which DK needs to ignore. 2172 However, there is one key difference between DK and DKIM DNS key 2173 records: the definitions of the g fields: 2175 g= granularity of the key In both DK and DKIM, this is an optional 2176 field that is used to constrain which sending address(es) can 2177 legitimately use this selector. Unfortunately, the treatment of 2178 an empty field ("g=;") is different. For DK, an empty field is 2179 the same as a missing value, and is treated as allowing any 2180 sending address. For DKIM, an empty field only matches an empty 2181 local part. 2183 v= version of the selector It is advised that a DKIM selector have 2184 "v=DKIM1;" at its beginning, but it is not required. 2186 If a DKIM verifier finds a selector record that has an empty "g" 2187 field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its 2188 beginning, it is faced with deciding if this record was 2190 1. from a DK signer that transitioned to supporting DKIM but forgot 2191 to remove the "g" field (so that it could be used by both DK and 2192 DKIM verifiers), or 2194 2. from a DKIM signer that truly meant to use the empty "g" field 2195 but forgot to put in the "v" field. It is advised that you treat 2196 such records using the first interpretation, and treat such 2197 records as if the signer did not have a "g" field in the record. 2199 A.2. Migrating Hash Algorithms 2201 [RFC4871] defines the use of two hash algorithms, SHA-1 and SHA-256. 2202 The security of all hash algorithms is constantly under attack, and 2203 SHA-1 has already shown weaknesses as of this writing. Migrating 2204 from SHA-1 to SHA-256 is not an issue, because all verifiers are 2205 already required to support SHA-256. But when it becomes necessary 2206 to replace SHA-256 with a more secure algorithm, there will be a 2207 migratory period. In the following, "NEWHASH" is used to represent a 2208 new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this 2209 scenario. 2211 A.2.1. Signers 2213 As with migrating from DK to DKIM, migrating hash algorithms is 2214 dependent on the signer's best guess as to the utility of continuing 2215 to sign with the older algorithms and the expected support for the 2216 newer algorithm by verifiers. The utility of continuing to sign with 2217 the older algorithms is also based on how broken the existing hash 2218 algorithms are considered and how important that is to the signers. 2220 One strategy is to wait until it's determined that there is a large 2221 enough base of verifiers available that support NEWHASH, and then 2222 flash cut to the new algorithm. 2224 Another strategy is to sign with both the old and new hash algorithms 2225 for a period of time. This is particularly useful for testing the 2226 new code to support the new hash algorithm, as verifiers will 2227 continue to accept the signature for the older hash algorithm and 2228 ought to ignore any signature that fails because the code is slightly 2229 wrong. Once the signer has determined that the new code is correct 2230 AND it's determined that there is a large enough base of verifiers 2231 available that support NEWHASH, the signer can flash cut to the new 2232 algorithm. 2234 One advantage migrating hash algorithms has is that the selector can 2235 be completely compatible for all hash algorithms. The key selector 2236 has an optional "h=" field that can be used to list the hash 2237 algorithms being used; it also is used to limit the algorithms that a 2238 verifier will accept. If the signer is not currently using the key- 2239 selector "h=" field, no change is required. If the signer is 2240 currently using the key-selector "h=" field, NEWHASH will need to be 2241 added to the list, as in "h=sha256:NEWHASH;". (When the signer is no 2242 longer using sha256, it can be removed from the "h=" list.) 2244 A.2.2. Verifiers 2246 When a new hash algorithm becomes standardized, it is best for a 2247 verifier to start supporting it as quickly as possible. 2249 A.3. Migrating Signing Algorithms 2251 [RFC4871] defines the use of the RSA signing algorithm. Similar to 2252 hashes, signing algorithms are constantly under attack, and when it 2253 becomes necessary to replace RSA with a newer signing algorithm, 2254 there will be a migratory period. In the following, "NEWALG" is used 2255 to represent a new signing algorithm. 2257 A.3.1. Signers 2259 As with the other migration issues discussed above, migrating signing 2260 algorithms is dependent on the signer's best guess as to the utility 2261 of continuing to sign with the older algorithms and the expected 2262 support for the newer algorithm by verifiers. The utility of 2263 continuing to sign with the older algorithms is also based on how 2264 broken the existing signing algorithms are considered and how 2265 important that is to the signers. 2267 As before, the two basic strategies are to 1) wait until there is 2268 sufficient base of verifiers available that support NEWALG and then 2269 do a flash cut to NEWALG, and 2) using a phased approach by signing 2270 with both the old and new algorithms before removing support for the 2271 old algorithm. 2273 It is unlikely that a new algorithm would be able to use the same 2274 public key as "rsa", so using the same selector DNS record for both 2275 algorithms' keys is ruled out. Therefore, in order to use the new 2276 algorithm, a new DNS selector record would need to be deployed in 2277 parallel with the existing DNS selector record for the existing 2278 algorithm. The new DNS selector record would specify a different 2279 "k=" value to reflect the use of NEWALG. 2281 A.3.2. Verifiers 2283 When a new hash algorithm becomes standardized, it is best for a 2284 verifier to start supporting it as quickly as possible. 2286 Appendix B. General Coding Criteria for Cryptographic Applications 2288 NOTE: This section could possibly be changed into a reference to 2289 something else, such as another rfc. 2291 Correct implementation of a cryptographic algorithm is a necessary 2292 but not a sufficient condition for the coding of cryptographic 2293 applications. Coding of cryptographic libraries requires close 2294 attention to security considerations that are unique to cryptographic 2295 applications. 2297 In addition to the usual security coding considerations, such as 2298 avoiding buffer or integer overflow and underflow, implementers need 2299 to pay close attention to management of cryptographic private keys 2300 and session keys, ensuring that these are correctly initialized and 2301 disposed of. 2303 Operating system mechanisms that permit the confidentiality of 2304 private keys to be protected against other processes ought to be used 2305 when available. In particular, great care needs to be taken when 2306 releasing memory pages to the operating system to ensure that private 2307 key information is not disclosed to other processes. 2309 Certain implementations of public key algorithms such as RSA can be 2310 vulnerable to a timing analysis attack. 2312 Support for cryptographic hardware providing key management 2313 capabilities is strongly encouraged. In addition to offering 2314 performance benefits, many cryptographic hardware devices provide 2315 robust and verifiable management of private keys. 2317 Fortunately appropriately designed and coded cryptographic libraries 2318 are available for most operating system platforms under license terms 2319 compatible with commercial, open source and free software license 2320 terms. Use of standard cryptographic libraries is strongly 2321 encouraged. These have been extensively tested, reduce development 2322 time and support a wide range of cryptographic hardware. 2324 Authors' Addresses 2326 Tony Hansen 2327 AT&T Laboratories 2328 200 Laurel Ave. South 2329 Middletown, NJ 07748 2330 USA 2332 Email: tony+dkimov@maillennium.att.com 2334 Ellen Siegel 2336 Email: dkim@esiegel.net 2338 Phillip Hallam-Baker 2339 Default Deny Security, Inc. 2341 Email: phillip@hallambaker.com 2342 Dave Crocker 2343 Brandenburg InternetWorking 2344 675 Spruce Dr. 2345 Sunnyvale, CA 94086 2346 USA 2348 Email: dcrocker@bbiw.net