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