idnits 2.17.1 draft-ietf-dkim-overview-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2009) is 5417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Internet' is mentioned on line 653, but not defined -- Obsolete informational reference (is this intentional?): RFC 989 (Obsoleted by RFC 1040, RFC 1113) -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 D. Crocker 5 Expires: November 30, 2009 Brandenburg InternetWorking 6 P. Hallam-Baker 7 May 29, 2009 9 DomainKeys Identified Mail (DKIM) Service Overview 10 draft-ietf-dkim-overview-12 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 30, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document provides an overview of the DomainKeys Identified Mail 49 (DKIM) service and describes how it can fit into a messaging service. 50 It also describes how DKIM relates to other IETF message signature 51 technologies. It is intended for those who are adopting, developing, 52 or deploying DKIM. DKIM allows an organization to take 53 responsibility for transmitting a message, in a way that can be 54 verified by a recipient. The organization can be the author's, the 55 originating sending site, an intermediary, or one of their agents. A 56 message can contain multiple signatures, from the same or different 57 organizations involved with the message. DKIM defines a domain-level 58 digital signature authentication framework for email, using public- 59 key cryptography, with the domain name service as its key server 60 technology [RFC4871]. This permits verification of a responsible 61 organization, as well as the integrity of the message contents. DKIM 62 also enables a mechanism that permits potential email signers to 63 publish information about their email signing practices; this will 64 permit email receivers to make additional assessments about messages. 65 DKIM's authentication of email identity can assist in the global 66 control of "spam" and "phishing". 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 7 74 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7 75 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8 76 2.1. Identity Verification . . . . . . . . . . . . . . . . . . 8 77 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 9 78 2.3. Establishing Message Validity . . . . . . . . . . . . . . 10 79 3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10 81 3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11 82 4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.1. Basic Signing . . . . . . . . . . . . . . . . . . . . . . 13 84 4.2. Characteristics of a DKIM Signature . . . . . . . . . . . 14 85 4.3. The Selector Construct . . . . . . . . . . . . . . . . . . 14 86 4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.5. Sub-Domain Assessment . . . . . . . . . . . . . . . . . . 15 88 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15 89 5.1. Administration and Maintenance . . . . . . . . . . . . . . 17 90 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18 92 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 18 93 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 19 95 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19 96 6.1. Security Considerations . . . . . . . . . . . . . . . . . 19 97 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 98 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 99 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 100 Appendix A. Internet Mail Background . . . . . . . . . . . . . . 21 101 A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 21 102 A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21 103 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 This document provides a description of the architecture and 109 functionality for DomainKeys Identified Mail (DKIM), that is, the 110 core mechanism for signing and verifying messages. It is intended 111 for those who are adopting, developing, or deploying DKIM. It will 112 also be helpful for those who are considering extending DKIM, either 113 into other areas of use or to support additional features. This 114 overview does not provide information on threats to DKIM or email, or 115 details on the protocol specifics, which can be found in [RFC4686] 116 and [RFC4871], respectively. Because the scope of this Overview is 117 restricted to the technical details of signing and verifying using 118 DKIM, it does not explore operational issues, the details of services 119 that DKIM uses or that, in turn, use DKIM. Nor does it discuss 120 services that build upon DKIM for enforcement of policies or 121 assessments. The document assumes a background in basic email and 122 network security technology and services. 124 DKIM allows an organization to take responsibility for a message, in 125 a way that can be verified by a recipient. The organization can be a 126 direct handler of the message, such as the author's, the originating 127 sending site's or an intermediary's along the transit path. However 128 it can also be and indirect handler, such as an independent service 129 that is providing assistance to a direct handler. DKIM defines a 130 domain-level digital signature authentication framework for email 131 through the use of public-key cryptography and using the domain name 132 service as its key server technology. [RFC4871] It permits 133 verification of the signer of a message, as well as the integrity of 134 its contents. DKIM will also provide a mechanism that permits 135 potential email signers to publish information about their email 136 signing practices; this will permit email receivers to make 137 additional assessments of unsigned messages. DKIM's authentication 138 of email identity can assist in the global control of "spam" and 139 "phishing". 141 Neither this document nor DKIM attempts to provide solutions to the 142 world's problems with spam, phishing, viruses, worms, joe jobs, etc. 143 DKIM provides one basic tool, in what needs to be a large arsenal, 144 for improving basic trust in the Internet mail service. However by 145 itself, DKIM is not sufficient to that task and this overview does 146 not pursue the issues of integrating DKIM into these larger efforts, 147 beyond a simple reference within a system diagram. Rather, it is a 148 basic introduction to the technology and its use. 150 1.1. DKIM's Scope 152 A person or organization has an "identity" -- that is, a 153 constellation of characteristics that distinguish them from any other 154 identity. Associated with this abstraction can be a label used as a 155 reference, or "identifier". This is the distinction between a thing 156 and the name of the thing. DKIM uses a domain name as an identifier, 157 to refer to the identity of a responsible person or organization. In 158 DKIM, this identifier is called the Signing Domain IDentifier (SDID) 159 and is contained in the DKIM-Signature header fields "d=" tag. Note 160 that the same identity can have multiple identifiers. 162 A DKIM signature can be created by a direct handler of a message, 163 such as the message's author or an intermediary. A signature also 164 can be created by an independent service that is providing assistance 165 to a handler of the message. Whoever does the signing chooses the 166 SDID to be used as the basis for later assessments. Hence, the 167 reputation associated with that domain name might be an additional 168 basis for evaluating whether to trust the message for delivery. The 169 owner of the SDID is declaring that they accept responsibility for 170 the message and can thus be held accountable for it. 172 DKIM is intended as a value-added feature for email. Mail that is 173 not signed by DKIM is handled in the same way as it was before DKIM 174 was defined. The message will be evaluated by established analysis 175 and filtering techniques. (A signing policy can provide additional 176 information for that analysis and filtering.) Over time, widespread 177 DKIM adoption could permit more strict handling of messages that are 178 not signed. However early benefits do not require this and probably 179 do not warrant this. 181 DKIM has a narrow scope. It is an enabling technology, intended for 182 use in the larger context of determining message legitimacy. This 183 larger context is complex, so it is easy to assume that a component 184 like DKIM, which actually provides only a limited service, instead 185 satisfies the broader set of requirements. 187 By itself, a DKIM signature: 189 o Does not authenticate or verify the contents of the message header 190 or body, such as the author From field, beyond certifying data 191 integrity between the time of signing and the time of verifying. 193 o Does not offer any assertions about the behaviors of the signer. 195 o Does not prescribe any specific actions for receivers to take upon 196 successful signature verification. 198 o Does not provide protection after signature verification. 200 o Does not protect against re-sending (replay of) a message that 201 already has a verified signature; therefore a transit intermediary 202 or a recipient can re-post the message -- that is, post it as a 203 new message -- with the original signature remaining verifiable, 204 even though the new recipient(s) might be different from those who 205 were originally specified by the author. 207 1.2. Prior Work 209 Historically, the IP Address of the system that directly sent the 210 message -- that is, the previous email "hop" -- has been treated as 211 an identity to use for making assessments. For example, see 212 [RFC4408], [RFC4406] and [RFC4407] for some current uses of the 213 sending system's IP address. The IP Address is obtained via 214 underlying Internet information mechanisms and is therefore trusted 215 to be accurate. Besides having some known security weaknesses, the 216 use of addresses presents a number of functional and operational 217 problems. Consequently there is a widespread desire to use an 218 identifier that has better correspondence to organizational 219 boundaries. Domain names can satisfy this need. 221 There have been four previous IETF Internet Mail signature standards. 222 Their goals have differed from those of DKIM. PEM and MOSS are only 223 of historical interest. 225 o Privacy Enhanced Mail (PEM) was first published in 1987. 226 [RFC0989] 228 o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and 229 first released in 1991. A later version was standardized as 230 OpenPGP. [RFC1991] [RFC2440] [RFC3156] [RFC4880] 232 o PEM eventually transformed into MIME Object Security Services 233 (MOSS) in 1995. [RFC1848] 235 o RSA Security independently developed Secure MIME (S/MIME) to 236 transport a PKCS #7 data object. It was standardized as 237 [RFC3851]. 239 Development of both S/MIME and OpenPGP has continued. While each has 240 achieved a significant user base, neither one has achieved ubiquity 241 in deployment or use. 243 To the extent that other message-signing services might have been 244 adapted to do the job that DKIM is designed to perform, it was felt 245 that re-purposing any of those would be more problematic than 246 creating a separate service. That said, DKIM only uses cryptographic 247 components that have a long history, including use within some of 248 those other messaging security services. 250 DKIM is differentiated by its reliance on an identifier that is 251 specific to DKIM use. 253 DKIM also has a distinctive approach for distributing and vouching 254 for keys. It uses a key-centric public key management scheme, rather 255 than the more typical approaches based on a certificate in the styles 256 of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust) 257 [WebofTrust]. For DKIM, the owner of the SDID asserts the validity 258 of a key, rather than having the validity of the key attested to by a 259 trusted third party, often including other assertions, such as a 260 quality assessment of the key's owner. DKIM treats quality 261 assessment as an independent, value-added service, beyond the initial 262 work of deploying a signature verification service. 264 Further, DKIM's key management is provided by adding information 265 records to the existing Domain Name System (DNS) [RFC1034], rather 266 than requiring deployment of a new query infrastructure. This 267 approach has significant operational advantages. First, it avoids 268 the considerable barrier of creating a new global infrastructure; 269 hence it leverages a global base of administrative experience and 270 highly reliable distributed operation. Second, the technical aspect 271 of the DNS is already known to be efficient. Any new service would 272 have to undergo a period of gradual maturation, with potentially 273 problematic early-stage behaviors. By (re-)using the DNS, DKIM 274 avoids these growing pains. 276 1.3. Internet Mail Background 278 The basic Internet Email service has evolved extensively over its 279 several decades of continuous operation. Its modern architecture 280 comprises a number of specialized components. A discussion about 281 Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer 282 Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents 283 (MDA), Mail Service Providers (MSP), Administrative Management 284 Domains (ADMDs), Mediators, and their relationships can be found in 285 Appendix A. 287 1.4. Discussion Venue 289 NOTE TO RFC EDITOR: This "Discussion Venue" section is to be 290 removed prior to publication. 292 This document is being discussed on the DKIM mailing list, 293 ietf-dkim@mipassoc.org. 295 1.4.1. Changes to document 297 In addition to simple wordsmithing, the following substantive changes 298 were made: 300 Service Arch figure and text: (per Allman) Existing figure and text 301 carries vestigial references to role of MSA and MDA. New text 302 switches focus to ADMD more completely and merely cites possible 303 functional modules within them. 305 Identity vs. Identifier: Added text in Scope to define terms and 306 their relationship. 308 Message Validity: Added section discussing restricted implication 309 of this. 311 2. The DKIM Value Proposition 313 The nature and origins of a message often are falsely stated. Such 314 misrepresentations may be employed for legitimate reasons or for 315 nefarious reasons. DKIM provides a foundation for distinguishing 316 legitimate mail, and thus a means of associating a verifiable 317 identifier with a message. Given the presence of that identifier, a 318 receiver can make decisions about further handling of the message, 319 based upon assessments of the identity that is associated with the 320 identifier. 322 Receivers who successfully verify a signature can use information 323 about the signer as part of a program to limit spam, spoofing, 324 phishing, or other undesirable behavior. DKIM does not, itself, 325 prescribe any specific actions by the recipient; rather it is an 326 enabling technology for services that do. 328 These services will typically: 330 1. Determine a verified identity as taking responsibility for the 331 message, if possible. 333 2. Evaluate the trustworthiness of this/these identities. 335 The role of DKIM is to perform the first of these; DKIM is an enabler 336 for the second. 338 2.1. Identity Verification 340 Consider an attack made against an organization or against customers 341 of an organization. The name of the organization is linked to a 342 particular Internet domain names (identifiers). Attackers can 343 leverage either using a legitimate domain name, without 344 authorization, or a "cousin" name that is similar to one that is 345 legitimate, but is not controlled by the target organization. An 346 assessment service that uses DKIM can differentiate between a domain 347 (SDID) used by a known organization and a domain used by others. As 348 such, DKIM performs the positive step of identifying messages 349 associated with verifiable identities, rather than the negative step 350 of identifying messages with problematic use of identities. Whether 351 a verified identity belongs to a Good Actor or a Bad Actor is a 352 question for later stages of assessment. 354 2.2. Enabling Trust Assessments 356 Email receiving services are faced with a basic decision: Whether to 357 accept and deliver a newly-arrived message to the indicated 358 recipient? That is, does the receiving service trust that the 359 message is sufficiently "safe" to be viewed? For the modern 360 Internet, most receiving services have an elaborate engine that 361 formulates this quality assessment. These engines take a variety of 362 information as input to the decision, such as from reputation lists 363 and accreditation services. As the engine processes information, it 364 raises or lowers its trust assessment for the message. 366 In order to formulate reputation information, an accurate, stable 367 identifier is needed. Otherwise, the information might not pertain 368 to the identified organization's own actions. When using an IP 369 Address, accuracy is based on the belief that the underlying Internet 370 infrastructure supplies an accurate address. When using domain based 371 reputation data, some other form of verification is needed, since it 372 is not supplied independently by the infrastructure. 374 DKIM satisfies this requirement by declaring a valid "responsible" 375 identity -- referenced through the SDID -- about which the engine can 376 make quality assessments and by using a digital signature to ensure 377 that use of the identifier is authorized. However by itself, a valid 378 DKIM signature neither lowers nor raises the level of trust 379 associated with the message, but it enables other mechanisms to be 380 used for doing so. 382 An organization might build upon its use of DKIM by publishing 383 information about its Signing Practices (SP). This could permit 384 detecting some messages that purport to be associated with a domain, 385 but which are not. As such, an SP can cause the trust assessment to 386 be reduced, or leave it unchanged. 388 2.3. Establishing Message Validity 390 Though man-in-the-middle attacks are historically rare in email, it 391 is nevertheless theoretically possible for a message to be modified 392 during transit. An interesting side effect of the cryptographic 393 method used by DKIM is that it is possible to be certain that a 394 signed message (or, if l= is used, the signed portion of a message) 395 has not been modified between the time of signing and the time of 396 verifying. If it has been changed in any way, then the message will 397 not be verified successfully with DKIM. 399 As described above, this validity neither lowers nor raises the level 400 of trust associated with the message. If it was an untrustworthy 401 message when initially sent, the verifier can be certain that the 402 message will be equally untrustworthy upon receipt and successful 403 verification. 405 3. DKIM Goals 407 DKIM adds an end-to-end authentication capability to the existing 408 email transfer infrastructure. That is, there can be multiple email 409 relaying hops between signing and verifying. Hence, it defines a 410 mechanism that only needs to be supported by the signer and the 411 verifier, rather than any of the functional components along the 412 handling path. This motivates functional goals about the 413 authentication itself and operational goals about its integration 414 with the rest of the Internet email service. 416 3.1. Functional Goals 418 3.1.1. Use Domain-level granularity for assurance 420 DKIM provides accountability at the coarse granularity of an 421 organization or, perhaps, a department. An existing construct that 422 enables this granularity is the Domain Name [RFC1034]. DKIM binds a 423 signing key record to a Domain Name, as the SDID. Further benefits 424 of using domain names include simplifying key management, enabling 425 signing by the infrastructure as opposed to the MUA, and reducing 426 privacy concerns. 428 Contrast this with OpenPGP and S/MIME, which associate verification 429 with individual authors, using their full email addresses. 431 3.1.2. Implementation Locality 433 Any party, anywhere along the transit path can implement DKIM 434 signing. Its use is not confined to particular systems, such as the 435 author's MUA or the inbound boundary MTA, and there can be more than 436 one signature per message. 438 3.1.3. Allow delegation of signing to independent parties 440 Different parties have different roles in the process of email 441 exchange. Some are easily visible to end users and others are 442 primarily visible to operators of the service. DKIM was designed to 443 support signing by any of these different parties and to permit them 444 to sign with any domain name that they deem appropriate (and for 445 which they hold authorized signing keys.) As an example an 446 organization that creates email content often delegates portions of 447 its processing or transmission to an outsourced group. DKIM supports 448 this mode of activity, in a manner that is not normally visible to 449 end users. Similarly, a reputation provider can delegate a signing 450 key for a domain under the control of the provider, to be used by an 451 organization the provider is prepared to vouch for. 453 3.1.4. Distinguish the core authentication mechanism from its 454 derivative uses 456 An authenticated identity can be subject to a variety of assessment 457 policies, either ad hoc or standardized. DKIM separates basic 458 authentication from assessment. The only semantics inherent to a 459 DKIM signature are that the signer is asserting some kind of 460 responsibility for the message. Any interpretation of this kind of 461 responsibility is the job of services building on DKIM, but the 462 details are beyond the scope of that core. One such mechanism might 463 assert a relationship between the SDID and the author, as specified 464 in the rfc5322.From: header field's domain identity. Another might 465 specify how to treat an unsigned message with that rfc5322.From: 466 field domain. 468 3.1.5. Retain ability to have anonymous email 470 The ability to send a message that does not identify its author is 471 considered to be a valuable quality of the current email service that 472 needs to be retained. DKIM is compatible with this goal since it 473 permits authentication of the email system operator, rather than the 474 content author. If it is possible to obtain effectively anonymous 475 accounts at example.com, knowing that a message definitely came from 476 example.com does not threaten the anonymity of the user who authored 477 it. 479 3.2. Operational Goals 480 3.2.1. Make presence of signature transparent to non-supporting 481 recipients 483 In order to facilitate incremental adoption, DKIM is designed to be 484 transparent to recipients that do not support it. A DKIM signature 485 does not "get in the way" for such recipients. 487 Contrast this with S/MIME and OpenPGP, which modify the message body. 488 Hence, their presence is potentially visible to email recipients, 489 whose user software needs to process the associated constructs. 491 3.2.2. Treat verification failure the same as no signature present 493 DKIM must also be transparent to existing assessment mechanisms. 494 Consequently, a DKIM signature verifier is to treat messages with 495 signatures that fail as if they were unsigned. Hence the message 496 will revert to normal handling, through the receiver's existing 497 filtering mechanisms. Thus, DKIM specifies that an assessing site is 498 not to take a message that has a broken signature and treat it any 499 differently than if the signature weren't there. 501 Contrast this with OpenPGP and S/MIME, which were designed for strong 502 cryptographic protection. This included treating verification 503 failure as message failure. 505 3.2.3. Permit incremental adoption for incremental benefit 507 DKIM can be used by any two organizations that exchange email and 508 implement DKIM; it does not require adoption within the open 509 Internet's email infrastructure. In the usual manner of "network 510 effects", the benefits of DKIM increase as its adoption increases. 512 Although this mechanism can be used in association with independent 513 assessment services, such services are not essential in order to 514 obtain initial benefit. For example DKIM allows (possibly large) 515 pairwise sets of email providers and spam filtering companies to 516 distinguish mail that is associated with a known organization, versus 517 mail that might deceptively purport to have the affiliation. This in 518 turn allows the development of "whitelist" schemes whereby 519 authenticated mail from a known source with good reputation is 520 allowed to bypass some anti-abuse filters. 522 In effect the email receiver can use their set of known relationships 523 to generate their own reputation data. This works particularly well 524 for traffic between large sending providers and large receiving 525 providers. However it also works well for any operator, public or 526 private, that has mail traffic dominated by exchanges among a stable 527 set of organizations. 529 Management of email delivery problems currently represents a 530 significant pain point for email administrators at every point on the 531 mail transit path. Administrators who have deployed DKIM 532 verification have an incentive to encourage senders (who might 533 subsequently complain that their email is not being delivered) to use 534 DKIM signatures. 536 3.2.4. Minimize the amount of required infrastructure 538 In order to allow early adopters to gain early benefit, DKIM makes no 539 changes to the core Internet Mail service and, instead, can provide a 540 useful benefit for any individual pair of signers and verifiers who 541 are exchanging mail. Similarly, DKIM's reliance on the Domain Name 542 System greatly reduces the amount of new administrative 543 infrastructure that is needed across the open Internet. 545 3.2.5. Permit a wide range of deployment choices 547 DKIM can be deployed at a variety of places within an organization's 548 email service. This affords flexibility in terms of who administers 549 its use, as well as what traffic carries a DKIM signature. For 550 example, employing DKIM at an outbound boundary MTA will mean that it 551 is administered by the organization's central IT department and that 552 internal messages are not signed. 554 4. DKIM Function 556 DKIM has a very constrained set of capabilities, primarily targeting 557 email while it is in transit from an author to a set of recipients. 558 It associates verifiable information with a message, especially a 559 responsible identity. When a message does not have a valid signature 560 associated with the author, a DKIM SP will permit the domain name of 561 the author to be used for obtaining information about their signing 562 practices. 564 4.1. Basic Signing 566 With the DKIM signature mechanism, a signer chooses a SDID, performs 567 digital signing on the message, and adds the signature information 568 using a DKIM header field. A verifier obtains the domain name and 569 the "selector" from the DKIM header field, obtains the public key 570 associated with the name, and verifies the signature. 572 DKIM permits any domain name to be used as the SDID, and supports 573 extensible choices for various algorithms. As is typical for 574 Internet standards, there is a core set of algorithms that all 575 implementations are required to support, in order to guarantee basic 576 interoperability. 578 DKIM permits restricting the use of a signature key to signing 579 messages for particular types of services, such as only for a single 580 source of email. This is intended to be helpful when delegating 581 signing authority, such as to a particular department or to a third- 582 party outsourcing service. 584 With DKIM the signer explicitly lists the headers that are signed, 585 such as From:, Date: and Subject:. By choosing the minimal set of 586 headers needed, the signature is likely to be considerably more 587 robust against the handling vagaries of intermediary MTAs. 589 4.2. Characteristics of a DKIM Signature 591 A DKIM signature applies to the message body and selected header 592 fields. The signer computes a hash of the selected header fields and 593 another hash of the body. The signer then uses a private key to 594 cryptographically encode this information, along with other signing 595 parameters. Signature information is placed into DKIM-Signature:, a 596 new [RFC5322] message header field. 598 4.3. The Selector Construct 600 The key for a signature is associated with an SDID. That domain name 601 provides the complete identity used for making assessments about the 602 signer. (The DKIM specification does not give any guidance on how to 603 do an assessment.) However this name is not sufficient for making a 604 DNS query to obtain the key needed to verify the signature. 606 A single SDID can have multiple signing keys and/or multiple 607 potential signers. To support this, DKIM identifies a particular 608 signature as using a combination of the SDID and an added field, 609 called the "selector", specified in a separate DKIM-Signature: header 610 field parameter. 612 NOTE: The semantics of the selector (if any) are strictly reserved 613 to the signer and is to be treated as an opaque string by all 614 other parties. If verifiers were to employ the selector as part 615 of an assessment mechanism, then there would be no remaining 616 mechanism for making a transition from an old, or compromised, key 617 to a new one. 619 4.4. Verification 621 After a message has been signed, any agent in the message transit 622 path can verify the signature to determine that the owner of the SDID 623 took responsibility for the message. Message recipients can verify 624 the signature by querying the DNS for the signer's domain directly, 625 to retrieve the appropriate public key, and thereby confirm that the 626 message was signed to by a party in possession of the private key for 627 the SDID. Typically, verification will be done by an agent in the 628 Administrative Management Domain (ADMD) of the message recipient. 630 4.5. Sub-Domain Assessment 632 Signers often need to support multiple assessments about their 633 organization, such as to distinguish one type of message from 634 another, or one portion of the organization from another. To permit 635 assessments that are independent, one method is for an organization 636 to use different sub-domains as the SDID tag, such as 637 "transaction.example.com" versus "newsletter.example.com", or 638 "productA.example.com" versus "productB.example.com". These can be 639 entirely separate from the rfc5322.From header field domain. 641 5. Service Architecture 642 DKIM uses external service components, such as for key retrieval and 643 relaying email. This specification defines an initial set, using DNS 644 and SMTP, for basic interoperability. 645 | 646 |- RFC5322 Message 647 V 648 +--------+ +--------------------------------+ 649 | Private| | ORIGINATING OR RELAYING ADMD | 650 | Key +...>| Sign Message with SDID | 651 | Store | +---------------+----------------+ 652 +--------+ | 653 (paired) [Internet] 654 +--------+ | +-----------+ 655 | Public | +--------------------------------+ | Remote | 656 | Key | | RELAYING OR DELIVERING ADMD | | Sender | 657 | Store | | Message Signed? | | Practices | 658 +----+---+ +-----+--------------------+-----+ +-----+-----+ 659 . |yes |no . 660 . V | . 661 . +-------------+ | . 662 +.......>| Verify +--------+ | . 663 | Signature | | | . 664 +------+------+ | | . 665 pass| fail| | . 666 V | | . 667 +-------------+ | | . 668 | | | | . 669 +.......>| Assessments | | | . 670 . | | V V . 671 . +-----+--+----+ +-------+ . 672 . | | / Check \<............+ 673 . | +-------->/ Signing \ 674 . | / Practices \<..........+ 675 . | +-------+-------+ . 676 . | | . 677 . | V . 678 +----+--------+ | +-----------+ +------+-----+ 679 |Reputation/ | | | Message | | Local Info | 680 |Accreditation| +----------->| Filtering | | on Sender | 681 |Info | | Engine | | Practices | 682 +-------------+ +-----------+ +------------+ 684 Figure 1: DKIM Service Architecture 686 As shown in Figure 1, basic message processing is divided between a 687 signing Administrative Management Domain (ADMD) and a verifying ADMD. 688 At its simplest, this is between the Originating ADMD and the 689 delivering ADMD, but can involve other ADMDs in the handling path. 691 Signing: Signing is performed by an authorized module within the 692 signing ADMD and uses private information from the Key Store, as 693 discussed below. Within the originating ADMD, this might be 694 performed by the MUA, MSA or an MTA. 696 verifying: verifying is performed by an authorized module within 697 the verifying ADMD. Within a delivering ADMD, verifying might be 698 performed by an MTA, MDA or MUA. The module verifies the 699 signature or determines whether a particular signature was 700 required. Verifying the signature uses public information from 701 the Key Store. If the signature passes, reputation information is 702 used to assess the signer and that information is passed to the 703 message filtering system. If the signature fails or there is no 704 signature using the author's domain, information about signing 705 practices related to the author can be retrieved remotely and/or 706 locally, and that information is passed to the message filtering 707 system. 709 If message has more than one valid signature, the order in which the 710 signers are assessed and the interactions among the assessments are 711 not defined by the DKIM specification. 713 5.1. Administration and Maintenance 715 A number of tables and services are used to provide external 716 information. Each of these introduces administration and maintenance 717 requirements. 719 Key Store: DKIM uses public/private (asymmetric) key cryptography. 720 The signer users a private key and the verifier uses the 721 corresponding public key. The current DKIM Signing specification 722 provides for querying the Domain Names Service (DNS), to permit a 723 verifier to obtain the public key. The signing organization 724 therefore needs to have a means of adding a key to the DNS, for 725 every selector/SDID combination. Further, the signing 726 organization needs policies for distributing and revising keys. 728 Reputation/Accreditation: If a message contains a valid signature, 729 then the verifier can evaluate the associated domain name's 730 reputation, in order to determine appropriate delivery or display 731 options for that message. Quality assessment information, which 732 is associated with a domain name, comes in many forms and from 733 many sources. DKIM does not define assessment services. Its 734 relevance to them is to provide a verified domain name, upon which 735 assessments can be made. 737 Signing Practices (SP): Separate from determining the validity of a 738 signature, and separate from assessing the reputation of the 739 organization that is associated with the signed identity, there is 740 an the opportunity to determine any organizational practices 741 concerning a domain name. Practices can range widely. They can 742 be published by the owner of the domain or they can be maintained 743 by the evaluating site. They can pertain to the use of the domain 744 name, such as whether it is used for signing messages, whether all 745 mail having that domain name in the author rfc5322.From: header 746 field is signed, or even whether the domain owner recommends 747 discarding messages in the absence of an appropriate signature. 748 The statements of practice are made at the level of a domain name, 749 and are distinct from assessments made about particular messages, 750 as occur in a Message Filtering Engine. Such assessments of 751 practices can provide useful input for the Message Filtering 752 Engine's determination of message handling. As practices are 753 defined, each domain name owner needs to consider what information 754 to publish. The nature and degree of checking practices, if any 755 is performed, is optional to the evaluating site and is strictly a 756 matter of local policy. 758 5.2. Signing 760 Signing can be performed by a component of the ADMD that creates the 761 message, and/or within any ADMD along the relay path. The signer 762 uses the appropriate private key that is associated with the SDID. 764 5.3. Verifying 766 Verification can be performed by any functional component along the 767 relay and delivery path. Verifiers retrieve the public key based 768 upon the parameters stored in the message. 770 5.4. Unverified or Unsigned Mail 772 Messages lacking a valid author signature (a signature associated 773 with the author of the message as opposed to a signature associated 774 with an intermediary) can prompt a query for any published "signing 775 practices" information, as an aid in determining whether the author 776 information has been used without authorization. 778 5.5. Assessing 780 Figure 1 shows the verified identity as being used to assess an 781 associated reputation, but it could be applied for other tasks, such 782 as management tracking of mail. Local policy guidelines may cause 783 signing practices to be checked or the message may be sent directly 784 to the message filtering engine. 786 A popular use of reputation information is as input to a filtering 787 engine that decides whether to deliver -- and possibly whether to 788 specially mark -- a message. Filtering engines have become complex 789 and sophisticated. Their details are outside of the scope of DKIM, 790 other than the expectation that the verified identity produced by 791 DKIM can accumulate its own reputation, and will be added to the 792 varied soup of rules used by the engines. The rules can cover signed 793 messages and can deal with unsigned messages from a domain, if the 794 domain has published information about its practices. 796 5.6. DKIM Processing within an ADMD 798 It is expected that the most common venue for a DKIM implementation 799 will be within the infrastructures of the authoring organization's 800 outbound service and the receiving organization's inbound service, 801 such as a department or a boundary MTA. DKIM can be implemented in 802 an author's or recipient's MUA, but this is expected to be less 803 typical, since it has higher administration and support costs. 805 A Mediator is an MUA that receives a message and can re-post a 806 modified version of it, such as to a mailing list. A DKIM signature 807 can survive some types of modifications through this process. 808 Furthermore the Mediator can add its own signature. This can be 809 added by the Mediator software itself, or by any outbound component 810 in the Mediator's ADMD. 812 6. Considerations 814 6.1. Security Considerations 816 The security considerations of the DKIM protocol are described in the 817 DKIM base specification [RFC4871], with [RFC4686] as their basis. 819 6.2. IANA Considerations 821 There are no actions for IANA. 823 NOTE TO RFC EDITOR: This section is to be removed prior to 824 publication. 826 6.3. Acknowledgements 828 Many people contributed to the development of the DomainKeys 829 Identified Mail and the effort of the DKIM Working Group is 830 gratefully acknowledged. In particular, we would like to thank Jim 831 Fenton for his extensive feedback diligently provided on every 832 version of this document. 834 7. Informative References 836 [Kohnfelder] 837 Kohnfelder, L., "Towards a Practical Public-key 838 Cryptosystem", May 1978. 840 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 841 for Internet electronic mail: Part I: Message encipherment 842 and authentication procedures", RFC 989, February 1987. 844 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 845 STD 13, RFC 1034, November 1987. 847 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 848 Object Security Services", RFC 1848, October 1995. 850 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 851 Exchange Formats", RFC 1991, August 1996. 853 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 854 "OpenPGP Message Format", RFC 2440, November 1998. 856 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 857 "MIME Security with OpenPGP", RFC 3156, August 2001. 859 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 860 Extensions (S/MIME) Version 3.1 Message Specification", 861 RFC 3851, July 2004. 863 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 864 RFC 4406, April 2006. 866 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail 867 Messages", RFC 4407, April 2006. 869 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 870 for Authorizing Use of Domains in E-Mail, Version 1", 871 RFC 4408, April 2006. 873 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 874 Identified Mail (DKIM)", RFC 4686, September 2006. 876 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 877 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 878 Signatures", RFC 4871, May 2007. 880 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 881 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 883 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 884 October 2008. 886 [WebofTrust] 887 Wikipedia, "Web of Trust", 888 URL http://en.wikipedia.org/wiki/Web_of_trust, 889 . 891 Appendix A. Internet Mail Background 893 A.1. Core Model 895 Internet Mail is split between the user world, in the form of Mail 896 User Agents (MUA), and the transmission world, in the form of the 897 Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). 898 The MHS is responsible for accepting a message from one user, the 899 author, and delivering it to one or more other users, the recipients. 900 This creates a virtual MUA-to-MUA exchange environment. The first 901 component of the MHS is called the Mail Submission Agent (MSA) and 902 the last is called the Mail Delivery Agent (MDA). 904 An email Mediator is both an inbound MDA and outbound MSA. It takes 905 delivery of a message, makes changes appropriate to its service, and 906 then re-posts it for further distribution. Typically the new message 907 will retain the original rfc5322.From: header field. A mailing list 908 is a common example of a Mediator. 910 The modern Internet Mail service is marked by many independent 911 operators, many different components for providing users with service 912 and many other components for performing message transfer. 913 Consequently, it is necessary to distinguish administrative 914 boundaries that surround sets of functional components, which are 915 subject to coherent operational policies. 917 As elaborated on below, every MSA is a candidate for signing using 918 DKIM, and every MDA is a candidate for doing DKIM verification. 920 A.2. Trust Boundaries 922 Operation of Internet Mail services is apportioned to different 923 providers (or operators). Each can be composed of an independent 924 ADministrative Management Domain (ADMD). An ADMD operates with an 925 independent set of policies and interacts with other ADMDs according 926 to differing types and amounts of trust. Examples include an end- 927 user operating a desktop client that connects to an independent email 928 service, a department operating a submission agent or a local Relay, 929 an organization's IT group that operates enterprise Relays, and an 930 ISP operating a public shared email service. 932 Each of these can be configured into many combinations of 933 administrative and operational relationships, with each ADMD 934 potentially having a complex arrangement of functional components. 935 Figure 2 depicts the relationships among ADMDs. Perhaps the most 936 salient aspect of an ADMD is the differential trust that determines 937 its policies for activities within the ADMD, versus those involving 938 interactions with other ADMDs. 940 Basic types of ADMDs include: 942 Edge: Independent transfer services, in networks at the edge of 943 the Internet Mail service. 945 User: End-user services. These might be subsumed under an Edge 946 service, such as is common for web-based email access. 948 Transit: These are Mail Service Providers (MSP) offering value- 949 added capabilities for Edge ADMDs, such as aggregation and 950 filtering. 952 Note that Transit services are quite different from packet-level 953 transit operation. Whereas end-to-end packet transfers usually go 954 through intermediate routers, email exchange across the open Internet 955 often is directly between the Edge ADMDs, at the email level. 956 +--------+ +--------+ +--------+ 957 | ADMD#1 | | ADMD#3 | | ADMD#4 | 958 | ------ | | ------ | | ------ | 959 | | +----------------------->| | | | 960 | User | | |--Edge--+--->|--User | 961 | | | | +--->| | | | 962 | V | | | +--------+ +--------+ 963 | Edge---+---+ | 964 | | | +----------+ | 965 +--------+ | | ADMD#2 | | 966 | | ------ | | 967 | | | | 968 +--->|-Transit--+---+ 969 | | 970 +----------+ 972 Figure 2: ADministrative Management Domains (ADMD) Example 974 In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM 975 signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM 976 verification. 978 The distinction between Transit network and Edge network transfer 979 services is primarily significant because it highlights the need for 980 concern over interaction and protection between independent 981 administrations. The interactions between functional components 982 within a single ADMD are subject to the policies of that domain. 983 Although any pair of ADMDs can arrange for whatever policies they 984 wish, Internet Mail is designed to permit inter-operation without 985 prior arrangement. 987 Common ADMD examples are: 989 Enterprise Service Providers: 991 Operators of an organization's internal data and/or mail 992 services. 994 Internet Service Providers: 996 Operators of underlying data communication services that, in 997 turn, are used by one or more Relays and Users. It is not 998 necessarily their job to perform email functions, but they 999 can, instead, provide an environment in which those 1000 functions can be performed. 1002 Mail Service Providers: 1004 Operators of email services, such as for end-users, or 1005 mailing lists. 1007 Index 1009 A 1010 ADMD 7 1011 Administrative Management Domain 7 1012 assessment 9 1014 D 1015 DKIM-Signature 14 1016 DNS 7, 14-17 1018 I 1019 identifier 5-6, 8 1020 identity 4-6, 8-9, 11, 13-14 1021 infrastructure 6-7, 9-10, 12-13, 19 1023 M 1024 Mail Delivery Agent 7 1025 Mail Handling Service 7 1026 Mail Service Provider 7 1027 Mail Submission Agent 7 1028 Mail Transfer Agent 7 1029 Mail User Agent 7 1030 MDA 7 1031 MHS 7 1032 MIME Object Security Services 6 1033 MOSS 6 1034 MSA 7 1035 MSP 7 1036 MTA 7 1037 MUA 7 1039 O 1040 OpenPGP 6 1042 P 1043 PEM 6 1044 PGP 6 1045 Pretty Good Privacy 6 1046 Privacy Enhanced Mail 6 1048 S 1049 S/MIME 6 1051 T 1052 trust 4, 9-10, 21 1054 V 1055 verification 5, 8, 10, 12, 15, 18, 21-22 1057 W 1058 Web of Trust 6 1060 X 1061 X.509 6 1063 Authors' Addresses 1065 Tony Hansen 1066 AT&T Laboratories 1067 200 Laurel Ave. 1068 Middletown, NJ 07748 1069 USA 1071 Email: tony+dkimov@maillennium.att.com 1073 Dave Crocker 1074 Brandenburg InternetWorking 1075 675 Spruce Dr. 1076 Sunnyvale, CA 94086 1077 USA 1079 Email: dcrocker@bbiw.net 1081 Phillip Hallam-Baker 1083 Email: phillip@hallambaker.com