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