idnits 2.17.1 draft-ietf-dkim-overview-09.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 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 984. 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 (February 25, 2008) is 5876 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Internet' is mentioned on line 577, but not defined == Unused Reference: 'I-D.kucherawy-sender-auth-header' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC4870' is defined on line 799, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-11 -- 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: August 28, 2008 Brandenburg InternetWorking 6 P. Hallam-Baker 7 VeriSign Inc. 8 February 25, 2008 10 DomainKeys Identified Mail (DKIM) Service Overview 11 draft-ietf-dkim-overview-09 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 August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document provides an overview of the DomainKeys Identified Mail 45 (DKIM) service and describes how it can fit into a messaging service. 46 It also describes how DKIM relates to other IETF message signature 47 technologies. It is intended for those who are adopting, developing, 48 or deploying DKIM. DKIM allows an organization to take 49 responsibility for transmitting a message, in a way that can be 50 validated by a recipient. The organization can be the author's, the 51 originating sending site, an intermediary, or one of their agents. 52 An organization may use one or more domain names to accomplish this. 53 DKIM defines a domain-level digital signature authentication 54 framework for email, using public-key cryptography and key server 55 technology [RFC4871]. This permits verification of a message source, 56 an intermediary, or one of their agents, as well as the integrity of 57 its contents. DKIM will also provide a mechanism that permits 58 potential email signers to publish information about their email 59 signing practices; this will permit email receivers to make 60 additional assessments about messages. Such protection of email 61 identity can assist in the global control of "spam" and "phishing". 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6 69 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6 70 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 71 2.1. Identity Verification . . . . . . . . . . . . . . . . . . 7 72 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7 73 3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 8 75 3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 9 76 4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 11 78 4.2. Characteristics of a DKIM signature . . . . . . . . . . . 11 79 4.3. The Selector construct . . . . . . . . . . . . . . . . . . 11 80 4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 12 81 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13 82 5.1. Administration and Maintenance . . . . . . . . . . . . . . 15 83 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 16 86 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 16 87 5.6. DKIM Placement within an ADMD . . . . . . . . . . . . . . 17 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 92 Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19 93 A.1. Administrative Management Domain (ADMD) . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Intellectual Property and Copyright Statements . . . . . . . . . . 23 97 1. Introduction 99 This document provides a description of the architecture and 100 functionality for DomainKeys Identified Mail (DKIM). It is intended 101 for those who are adopting, developing, or deploying DKIM. It will 102 also be helpful for those who are considering extending DKIM, either 103 into other areas of use or to support additional features. This 104 overview does not provide information on threats to DKIM or email, or 105 details on the protocol specifics, which can be found in [RFC4686] 106 and [RFC4871], respectively. The document assumes a background in 107 basic email and network security technology and services. 109 DKIM allows an organization to take responsibility for a message, in 110 a way that can be validated by a recipient. The organization can be 111 the author's, the originating sending site, an intermediary, or one 112 of their agents. DKIM defines a domain-level digital signature 113 authentication framework for email through the use of public-key 114 cryptography and key server technology. [RFC4871] It permits 115 verification of the signer of a message, as well as the integrity of 116 its contents. DKIM will also provide a mechanism that permits 117 potential email signers to publish information about their email 118 signing practices; this will permit email receivers to make 119 additional assessments of unsigned messages. Such protection of 120 email identity can assist in the global control of "spam" and 121 "phishing". 123 Neither this document nor DKIM attempts to provide solutions to the 124 world's problems with spam, phishing, virii, worms, joe jobs, etc. 125 DKIM provides one basic tool, in what needs to be a large arsenal, 126 for improving basic trust in the Internet mail service. However by 127 itself, DKIM is not sufficient to that task and this overview does 128 not pursue the issues of integrating DKIM into these larger efforts, 129 beyond a simple reference within a system diagram. Rather, it is a 130 basic introduction to the technology and its use. 132 1.1. DKIM's Scope 134 DKIM signatures can be created by a direct handler of a message, 135 either as its author or as an intermediary. It can also be created 136 by an independent service that is providing assistance to a handler 137 of the message. Whoever does the signing chooses the domain name to 138 be used as the basis for later assessments. Hence, the reputation 139 associated with that domain name is an additional basis for 140 evaluating whether to trust the message for delivery. The owner of 141 the domain name being used for a DKIM signature is declaring that 142 they accept responsibility for the message and may thus be held 143 accountable for it. 145 DKIM is intended as a value-added feature for email. Mail that is 146 not signed by DKIM is handled in the same way as it was before DKIM 147 was defined. The message will be evaluated by established analysis 148 and filtering techniques. (A signing policy may provide additional 149 information for that analysis and filtering.) Over time, widespread 150 DKIM adoption could permit more strict handling of messages that are 151 not signed. However early benefits do not require this and probably 152 do not warrant this. 154 DKIM's capabilities have a narrow scope. It is an enabling 155 technology, intended for use in the larger context of determining 156 message legitimacy. This larger context is complex, so it is easy to 157 assume that a component like DKIM, which actually provides only a 158 limited service, instead satisfies the broader set of requirements. 160 By itself, a DKIM signature: 162 o Does not offer any assertions about the behaviors of the identity 163 doing the signing. 165 o Does not prescribe any specific actions for receivers to take upon 166 successful signature verification. 168 o Does not provide protection after signature verification. 170 o Does not protect against re-sending (replay of) a message that 171 already has a verified signature; therefore a transit intermediary 172 or a recipient can re-post the message in such a way that the 173 signature would remain verifiable, although the new recipient(s) 174 would not have been specified by the author. 176 1.2. Prior Work 178 Historically, email delivery assessment decisions have been based on 179 an identity that used the IP Address of the system that directly sent 180 the message (that is, the previous email "hop"), [RFC4408] or on the 181 message content (e.g. [RFC4406] and [RFC4407]). The IP Address is 182 obtained via underlying Internet information mechanisms and is 183 therefore trusted to be accurate. Besides having some known security 184 weaknesses, the use of addresses presents a number of functional and 185 operational problems. Consequently there is a widespread desire to 186 use an identifier that has better correspondence to organizational 187 boundaries. Domain names are viewed as often satisfying this need. 189 There have been four previous IETF efforts at standardizing an 190 Internet email signature scheme. Their goals have differed from 191 those of DKIM. 193 o Privacy Enhanced Mail (PEM) was first published in 1987. 194 [RFC0989] 196 o PEM eventually transformed into MIME Object Security Services 197 (MOSS) in 1995. [RFC1848] Today, these two are only of historical 198 interest. 200 o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and 201 first released in 1991. [RFC1991] A later version was 202 standardized as OpenPGP. [RFC2440] [RFC3156] [RFC4880] 204 o RSA Security independently developed Secure MIME (S/MIME) to 205 transport a PKCS #7 data object. [RFC3851] 207 Development of both S/MIME and OpenPGP has continued. While each has 208 achieved a significant user base, neither one has achieved ubiquity 209 in deployment or use. 211 To the extent that other message-signing services might have been 212 adapted to do the job that DKIM is designed to perform, it was felt 213 that re-purposing any of those would be more problematic than 214 creating a separate service. That said, DKIM uses security algorithm 215 components that have a long history, including use within some of 216 those other messaging security services. 218 DKIM has a distinctive approach for distributing and vouching for 219 keys. It uses a key-centric Public Key Infrastructure (PKI) rather 220 than the more typical approaches based on a certificate in the styles 221 of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust). For 222 DKIM, the owner of a domain name asserts the validity of a key, 223 rather than relying on the key having a broader semantic implication 224 of the assertion, such as a quality assessment of the key's owner. 225 DKIM treats quality assessment as an independent, value-added 226 service, beyond the initial work of deploying a verifying signature 227 service. 229 Further, DKIM's PKI is provided by adding information records to the 230 existing Domain Name System (DNS) [RFC1034], rather than requiring 231 deployment of a new query infrastructure. This approach has 232 significant operational advantages. First, it avoids the 233 considerable barrier of creating a new global infrastructure; hence 234 it leverages a global base of administrative experience and highly 235 reliable distributed operation. Second, the technical aspect of the 236 DNS is already known to be efficient. Any new service would have to 237 undergo a period of gradual maturation, with potentially problematic 238 early-stage behaviors. By (re-)using the DNS, DKIM avoids these 239 growing pains. 241 1.3. Internet Mail Background 243 The basic Internet Email service has evolved extensively over its 244 several decades of continuous operation. Its modern architecture 245 comprises a number of specialized components. A discussion about 246 Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer 247 Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents 248 (MDA), Mail Service Providers (MSP), Administrative Management 249 Domains (ADMDs), and their relationships can be found in Appendix A. 251 1.4. Discussion Venue 253 NOTE TO RFC EDITOR: This "Discussion Venue" section is to be 254 removed prior to publication. 256 This document is being discussed on the DKIM mailing list, 257 ietf-dkim@mipassoc.org. 259 2. The DKIM Value Proposition 261 The nature and origins of a message are often falsely stated. Such 262 misrepresentations may (but not necessarily) be employed in order to 263 perpetrate abuse. DKIM provides a foundation for distinguishing 264 legitimate mail, and thus a means of associating a verifiable 265 identifier with a message. Given the presence of that identifier, a 266 receiver can make decisions about further handling of the message, 267 based upon assessments of the identity that is associated with the 268 identifier. 270 Receivers who successfully verify a signature can use information 271 about the signer as part of a program to limit spam, spoofing, 272 phishing, or other undesirable behavior. DKIM does not, itself, 273 prescribe any specific actions by the recipient; rather it is an 274 enabling technology for services that do. 276 These services will typically: 278 1. Determine a verified identity, if possible. 280 2. Determine whether a known identity is trusted. 282 The role of DKIM is to perform the first of these; DKIM is an enabler 283 for the second. 285 2.1. Identity Verification 287 Consider an attack made against an organization or against customers 288 of an organization. The name of the organization is linked to 289 particular Internet domain names (identifiers). One point of 290 leverage for attackers is either to use a legitimate domain name, 291 without authorization, or to use a "cousin" name that is similar to 292 one that is legitimate, but is not controlled by the target 293 organization. An assessment service that uses DKIM can differentiate 294 between domains used by known organizations and domains used by 295 others. As such, DKIM performs the positive step of identifying 296 messages associated with verifiable identities, rather than the 297 negative step of identifying messages with problematic use of 298 identities. Whether a verified identity belongs to a Good Actor or a 299 Bad Actor becomes a later step of assessment. 301 2.2. Enabling Trust Assessments 303 Email receiving services are faced with a basic decision: Should they 304 deliver a newly-arrived message to the indicated recipient? That is, 305 does the receiving service trust that the message is sufficiently 306 "safe" to be viewed? For the modern Internet, most receiving 307 services have an elaborate engine that formulates this quality 308 assessment. These engines take a variety of information as input to 309 the decision, such as from reputation lists and accreditation 310 services. As the engine processes information, it raises or lowers 311 its trust assessment for the message. 313 DKIM provides additional information to this process by declaring a 314 valid "responsible" identity about which the engine can make quality 315 assessments. By itself, a valid DKIM signature neither lowers nor 316 raises the level of trust associated with the message, but it enables 317 other mechanisms to be used for doing so. 319 An organization might build upon its use of DKIM by publishing 320 information about its Signing Practices (SP). This could permit 321 detecting some messages that purport to be associated with a domain, 322 but which are not. As such, an SP can cause the trust assessment to 323 be reduced, or leave it unchanged. 325 3. DKIM Goals 327 DKIM adds an end-to-end authentication mechanism to the existing 328 email transfer infrastructure. This motivates functional goals about 329 the authentication itself and operational goals about its integration 330 with the rest of the Internet email service. 332 3.1. Functional Goals 334 3.1.1. Use Domain-level granularity for assurance 336 DKIM seeks accountability at the coarse granularity of an 337 organization or, perhaps, a department. An existing Internet service 338 construct that enables this granularity is the Domain Name [RFC1034]. 339 DKIM binds the signing key record to the Domain Name. Further 340 benefits of using domain names include simplifying key management, 341 enabling signing by the infrastructure as opposed to the MUA, and 342 potential privacy issues. 344 Contrast this with OpenPGP and S/MIME, which provide end-to-end 345 validation in terms of individual authors, notably using full email 346 addresses. 348 3.1.2. Implementation Locality 350 Any party, anywhere along the transit path can implement DKIM 351 signing. Its use is not confined to the end systems or only in a 352 boundary MTA. 354 3.1.3. Allow delegation of signing to independent parties 356 Different parties have different roles in the process of email 357 exchange. Some are easily visible to end users and others are 358 primarily visible to operators of the service. DKIM was designed to 359 support signing by any of these different parties and to permit them 360 to sign with any domain name that they deem appropriate (and for 361 which they hold authorized signing keys.) As an example an 362 organization that creates email content often delegates portions of 363 its processing or transmission to an outsourced group. DKIM supports 364 this mode of activity, in a manner that is not normally visible to 365 end users. 367 3.1.4. Distinguish the core authentication mechanism from its 368 derivative uses 370 An authenticated identity can be subject to a variety of processing 371 policies, either ad hoc or standardized. The only semantics inherent 372 to a DKIM signature is that the signer is asserting (some) 373 responsibility for the message. All other mechanisms and meanings 374 are built on this core service. One such mechanism might assert a 375 relationship between the signing identity and the author, as 376 specified in the From: header field's domain identity[RFC2822]. 377 Another might specify how to treat an unsigned message with that 378 From: field domain. 380 3.1.5. Retain ability to have anonymous email 382 The ability to send a message that does not identify its author is 383 considered to be a valuable quality of the current email service that 384 needs to be retained. DKIM is compatible with this goal since it 385 permits authentication of the email system operator, rather than the 386 content author. If it is possible to obtain effectively anonymous 387 accounts at example.com, knowing that a message definitely came from 388 example.com does not threaten the anonymity of the user who authored 389 it. 391 3.2. Operational Goals 393 3.2.1. Treat verification failure the same as no signature present 395 As a sub-goal to the requirement for transparency, a DKIM signature 396 verifier is to treat messages with signatures that fail as if they 397 were unsigned. Hence the message will revert to normal handling, 398 through the receiver's existing filtering mechanisms. Thus, DKIM 399 specifies that an assessing site is not to take a message that has a 400 broken signature and treat it any differently than if the signature 401 weren't there. 403 Contrast this with OpenPGP and S/MIME, which were designed for strong 404 cryptographic protection. This included treating verification 405 failure as message failure. 407 3.2.2. Make signatures transparent to non-supporting recipients 409 In order to facilitate incremental adoption, DKIM is designed to be 410 transparent to recipients that do not support it. A DKIM signature 411 does not "get in the way" for such recipients. 413 Contrast this with S/MIME and OpenPGP, which modify the message body. 414 Hence, their presence is potentially visible to email recipients, 415 whose user software needs to process the associated constructs. 417 3.2.3. Permit incremental adoption for incremental benefit 419 DKIM can immediately provide benefits between any two organizations 420 that exchange email and implement DKIM. In the usual manner of 421 "network effects", the benefits of DKIM increase dramatically as its 422 adoption increases. 424 Although it is envisioned that this mechanism will call upon 425 independent services to aid in the assessment of DKIM results, they 426 are not essential in order to obtain initial benefit. For example 427 DKIM allows (possibly large) pair-wise sets of email providers and 428 spam filtering companies to distinguish mail that is associated with 429 a known organization from mail that might deceptively purport to have 430 the affiliation. This in turn allows the development of "whitelist" 431 schemes whereby authenticated mail from a known source with good 432 reputation is allowed to bypass some anti-abuse filters. 434 In effect the email receiver is using their set of known 435 relationships to generate their own reputation data. This works 436 particularly well for traffic between large sending providers and 437 large receiving providers. However it also works well for any 438 operator, public or private, that has mail traffic dominated by 439 exchanges among a stable set of organizations. 441 Management of email deliverability problems currently represents a 442 significant pain point for email administrators at every point on the 443 mail transit path. Administrators who have deployed DKIM 444 verification have an incentive to evangelize the use of DKIM 445 signatures to senders who may subsequently complain that their email 446 is not being delivered. 448 3.2.4. Minimize the amount of required infrastructure 450 A new service, or an enhancement to an existing service, requires 451 adoption in a critical mass of system components, before it can be 452 useful. The greater the number of required adopters, the higher the 453 adoption barrier. This becomes particularly serious when adoption is 454 required by independent, intermediary -- that is, infrastructure -- 455 service providers. In order to allow early adopters to gain early 456 benefit, DKIM makes no changes to the core Internet Mail service and, 457 instead, can provide a useful benefit for any individual pair of 458 signers and verifiers who are exchanging mail. Similarly, DKIM's 459 reliance on the Domain Name System greatly reduces the amount of new 460 administrative infrastructure that is needed across the open 461 Internet. 463 3.2.5. Permit wide range of deployment choices 465 DKIM can be deployed at a variety of places within an organization's 466 email service. This permits the organization to choose how much or 467 how little they want DKIM to be part of their service, rather than 468 part of a more localized operation. 470 4. DKIM Function 472 DKIM has a very constrained set of capabilities, primarily targeting 473 email while it is in transit from an author to a set of recipients. 474 It creates the ability to associate verifiable information with a 475 message, especially a responsible identity. When a message does not 476 have a valid signature associated with the author, DKIM SP will 477 permit the domain name of the author to be used for obtaining 478 information about their signing practices. 480 4.1. The Basic Signing Service 482 With the DKIM signature mechanism, a signer chooses a signing 483 identity based on their domain name, performs digital signing on the 484 message, and records signature information in a DKIM header field. A 485 verifier obtains the domain name and the "selector" from the DKIM 486 header field, queries for a public key associated with the name, and 487 verifies the signature. 489 DKIM permits any domain name to be used for signing, and supports 490 extensible choices for various algorithms. As is typical for 491 Internet standards, there is a core set of algorithms that all 492 implementations are required to support, in order to guarantee basic 493 interoperability. 495 DKIM permits restricting the use of a signature key (by using s=) to 496 signing messages for particular types of services, such as only for 497 email. This is intended to be helpful when delegating signing 498 authority, such as to a particular department or to a third-party 499 outsourcing service. 501 With DKIM the signer explicitly lists the headers that are signed, 502 such as From:, Date: and Subject:. By choosing the minimal set of 503 headers needed, the signature is likely to be considerably more 504 robust against the handling vagaries of intermediary MTAs. 506 4.2. Characteristics of a DKIM signature 508 A DKIM signature covers the message body and selected header fields. 509 The signer computes a hash of the selected header fields and another 510 hash of the body. The signer then uses a private key to 511 cryptographically encode this information, along with other signing 512 parameters. Signature information is placed into the DKIM-Signature 513 header field, a new [RFC2822] header field of the message. 515 4.3. The Selector construct 517 The key for a signature is associated with a domain name, as 518 specified in the d= parameter of the DKIM-Signature header. That 519 domain name, or the domain name or address in the i= parameter, 520 provide the complete identity used for making assessments about the 521 signer. (The DKIM specification does not give any guidance on how to 522 do an assessment.) However this name is not sufficient for making a 523 DNS query to obtain the key needed to verify the signature. 525 A single domain can use multiple signing keys and/or multiple 526 potential signers. To support this, DKIM identifies a particular 527 signature as a combination of the domain name and an added field, 528 called the "selector", specified in separate DKIM-Signature header 529 field parameters. 531 NOTE: The semantics of the selector (if any) are strictly reserved 532 to the signer and should be treated as an opaque string by all 533 other parties. If verifiers were to employ the selector as part 534 of a name assessment mechanism, then there would be no remaining 535 mechanism for making a transition from an old, or compromised, key 536 to a new one. 538 Signers often need to support multiple assessments about their 539 organization, such as to distinguish one type of message from 540 another, or one portion of the organization from another. To permit 541 assessments that are independent, one method is for an organization 542 to use different sub-domains in the "d=" parameter, such as 543 "transaction.example.com" versus "newsletter.example.com", or 544 "productA.example.com" versus "productB.example.com". 546 4.4. Verification 548 After a message has been signed, any agent in the message transit 549 path can verify the signature to determine that the signing identity 550 took responsibility for the message. Message recipients can verify 551 the signature by querying the DNS for the signer's domain directly, 552 to retrieve the appropriate public key, and thereby confirm that the 553 message was attested to by a party in possession of the private key 554 for the signing domain. Typically, verification will be done by an 555 agent in the Administrative Management Domain (ADMD) of the message 556 recipient. 558 5. Service Architecture 560 The DKIM service is divided into components that are performed using 561 different, external services, such as for key retrieval and relaying 562 email. The basic DKIM signing specification defines an initial set 563 of these services (using DNS and SMTP), in order to ensure a basic 564 level of interoperability. 566 | 567 |- RFC2822 Message 568 V 569 +--------+ +------------------------------------+ 570 | Private| | ORIGINATING OR RELAYING ADMD (MSA) | 571 | Key |.>| Sign Message | 572 | Store | +--------------+---------------------+ 573 +--------+ | 574 (paired) | 575 +--------+ | +-----------+ 576 | Public | | | Remote | 577 | Key | [Internet] | Sender | 578 | Store | | | Practices | 579 +----+---+ | +-----+-----+ 580 . V . 581 . +-----------------------------------+ . 582 . | RELAYING OR DELIVERING ADMD (MDA) | . 583 . | Message Signed? | . 584 . +--------+---------------+----------+ . 585 . |yes |no . 586 . V | . 587 . +------------+ | . 588 +.....>| Verify +----+ | . 589 | Signatures | | | . 590 +-----+------+ | | . 591 pass| fail| | . 592 V | | . 593 +--------+ | | . 594 +.......>| Assess | | | . 595 . | Signer | V V . 596 . +---+----+ +-------+ . 597 . | / Check \<............+ 598 . +------>/ Signing \ 599 . | / Practices \<..........+ 600 . | +-------+-------+ . 601 . | | . 602 . | V . 603 +---+---------+ | +-----------+ +------+-----+ 604 |Reputation/ | | | Message | | Local Info | 605 |Accreditation| +------>| Filtering | | on Sender | 606 |Info | | Engine | | Practices | 607 +-------------+ +-----------+ +------------+ 609 Figure 1: DKIM Service Architecture 611 As shown in Figure 1, basic message processing is divided between the 612 MSA and the MDA. 614 The MSA The MSA signs the message, using private information from 615 the Key Store. 617 The MDA The MDA verifies the signature or determines whether a 618 signature was required. Verifying the signature uses public 619 information from the Key Store. If the signature passes, 620 reputation information is used to asses the signer and that 621 information is passed to the message filtering system. If the 622 signature fails or there is no signature, information about the 623 related signing practices is retrieved remotely and/or locally, 624 and that information is passed to the message filtering system. 626 Note: Figure 1 does not show the effects on the message handling 627 when multiple signatures or non-author signatures are present. 629 5.1. Administration and Maintenance 631 A number of tables and services are used to provide external 632 information. Each of these introduces administration and maintenance 633 requirements. 635 Key Store DKIM uses public/private (asymmetric) key cryptography. 636 The signer users a private key and the validator uses the 637 corresponding public key. The current DKIM signing specification 638 provides for querying the Domain Names Service (DNS), to permit a 639 validator to obtain the public key. The signing organization 640 therefore must have a means of adding a key to the DNS, for every 641 selector/domain-name combination. Further, the signing 642 organization needs policies for distributing and revising keys. 644 Reputation/Accreditation If a message contains a valid signature, 645 then the verifier can evaluate the associated domain name's 646 reputation. Quality-assessment information, which is associated 647 with a domain name, comes in many forms and from many sources. 648 DKIM does not define assessment services. It's relevance to them 649 is to provide a validated domain name, upon which assessments can 650 be made. 652 Signing Practices (SP) Separate from determining the validity of a 653 signature, and separate from assessing the reputation of the 654 organization that is associated with the signed identity, there is 655 an the opportunity to determine any organizational practices 656 concerning a domain name. Practices can range widely. They can 657 be published by the owner of the domain or they can be maintained 658 by the evaluating site. They can pertain to the use of the domain 659 name, such as whether it is used for signing messages, whether all 660 mail having that domain name in the author From: header field is 661 signed, or whether such mail is to be discarded in the absence of 662 an appropriate signature. The statements of practice are made at 663 the level of a domain name, and are distinct from assessments made 664 about particular messages, as occur in a Message Filtering Engine. 665 Such assessments of practices can provide useful input for the 666 Message Filtering Engine's determination of message handling. As 667 practices are defined, each domain name owner needs to consider 668 what information to publish. The nature and degree of checking 669 practices, if any is performed, is optional to the evaluating site 670 and is strictly a matter of local policy. 672 5.2. Signing 674 Signing can be performed by a component of the ADMD that creates the 675 message, and/or within any ADMD along the relay path. The signer 676 uses the appropriate private key. 678 5.3. Verifying 680 Verification can be performed by any functional component along the 681 relay and delivery path. Verifiers retrieve the public key based 682 upon the parameters stored in the message. 684 5.4. Unverified or Unsigned Mail 686 Note that a failed signature causes the message to be treated in the 687 same manner as one that is unsigned. Messages lacking a valid author 688 signature (a signature associated with the author of the message as 689 opposed to a signature associated with an intermediary) can prompt a 690 query for any published "signing practices" information, as an aid in 691 determining whether the author information has been used without 692 authorization. 694 5.5. Assessing 696 Figure 1 shows the verified identity as being used to assess an 697 associated reputation, but it could be applied for other tasks, such 698 as management tracking of mail. A popular use of reputation 699 information is as input to a filtering engine that decides whether to 700 deliver -- and possibly whether to specially mark -- a message. 701 Filtering engines have become complex and sophisticated. Their 702 details are outside of the scope of DKIM, other than the expectation 703 that the validated identity produced by DKIM will be added to the 704 varied soup of rules used by the engines. The rules can cover signed 705 messages and can deal with unsigned messages from a domain, if the 706 domain has published information about its practices. 708 5.6. DKIM Placement within an ADMD 710 It is expected that the most common venue for a DKIM implementation 711 will be within the infrastructures of the authoring organization's 712 outbound service and the receiving organization's inbound service, 713 such as a department or a boundary MTA. DKIM can be implemented in 714 an author's or recipient MUA, but this is expected to be less 715 typical, since it has higher administration and support costs. 717 A Mediator, such as a mailing list, often can re-post a message 718 without breaking the DKIM signature. Furthermore it can add its own 719 signature. This can be added by the Mediator software itself, or by 720 any outbound component in the Mediator's ADMD. 722 6. Security Considerations 724 The security considerations of the DKIM protocol are described in the 725 DKIM base specification [RFC4871]. 727 7. IANA Considerations 729 There are no actions for IANA. 731 NOTE TO RFC EDITOR: This section may be removed prior to 732 publication. 734 8. Acknowledgements 736 Many people contributed to the development of the DomainKeys 737 Identified Mail and the efforts of the DKIM Working Group is 738 gratefully acknowledged. In particular, we would like to thank Jim 739 Fenton for his extensive feedback diligently provided on every 740 version of this document. 742 9. Informative References 744 [I-D.kucherawy-sender-auth-header] 745 Kucherawy, M., "Message Header Field for Indicating 746 Message Authentication Status", 747 draft-kucherawy-sender-auth-header-11 (work in progress), 748 February 2008. 750 [Kohnfelder] 751 Kohnfelder, L., "Towards a Practical Public-key 752 Cryptosystem", May 1978. 754 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 755 for Internet electronic mail: Part I: Message encipherment 756 and authentication procedures", RFC 989, February 1987. 758 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 759 STD 13, RFC 1034, November 1987. 761 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 762 Object Security Services", RFC 1848, October 1995. 764 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 765 Exchange Formats", RFC 1991, August 1996. 767 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 768 "OpenPGP Message Format", RFC 2440, November 1998. 770 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 771 April 2001. 773 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 774 April 2001. 776 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 777 "MIME Security with OpenPGP", RFC 3156, August 2001. 779 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 780 August 2001. 782 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 783 Extensions (S/MIME) Version 3.1 Message Specification", 784 RFC 3851, July 2004. 786 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 787 RFC 4406, April 2006. 789 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail 790 Messages", RFC 4407, April 2006. 792 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 793 for Authorizing Use of Domains in E-Mail, Version 1", 794 RFC 4408, April 2006. 796 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 797 Identified Mail (DKIM)", RFC 4686, September 2006. 799 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 800 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 801 May 2007. 803 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 804 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 805 Signatures", RFC 4871, May 2007. 807 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 808 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 810 Appendix A. Internet Mail Background 812 Internet Mail is split between the user world, in the form of Mail 813 User Agents (MUA), and the transmission world, in the form of the 814 Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). 815 The MHS is responsible for accepting a message from one user, the 816 author, and delivering it to one or more other users, the recipients. 817 This creates a virtual MUA-to-MUA exchange environment. The first 818 component of the MHS is called the Mail Submission Agent (MSA) and 819 the last is called the Mail Delivery Agent (MDA). 821 An email Mediator is both an inbound MDA and outbound MSA. It takes 822 delivery of a message and re-posts it for further distribution, 823 retaining the original From: header field. A mailing list is a 824 common example of a Mediator. 826 The modern Internet Mail service is marked by many independent 827 operators, many different components for providing users with service 828 and many other components for performing message transfer. 829 Consequently, it is necessary to distinguish administrative 830 boundaries that surround sets of functional components, which are 831 subject to coherent operational policies. 833 As elaborated on below, every MSA is a candidate for signing using 834 DKIM, and every MDA is a candidate for doing DKIM verification. 836 A.1. Administrative Management Domain (ADMD) 838 Operation of Internet Mail services is apportioned to different 839 providers (or operators). Each can be composed of an independent 840 ADministrative Management Domain (ADMD). An ADMD operates with an 841 independent set of policies and interacts with other ADMDs according 842 to differing types and amounts of trust. Examples include: an end- 843 user operating their desktop client that connects to an independent 844 email service, a department operating a submission agent or a local 845 Relay, an organization's IT group that operates enterprise Relays, 846 and an ISP operating a public shared email service. 848 Each of these can be configured into many combinations of 849 administrative and operational relationships, with each ADMD 850 potentially having a complex arrangement of functional components. 851 Figure 2 depicts the relationships among ADMDs. Perhaps the most 852 salient aspect of an ADMD is the differential trust that determines 853 its policies for activities within the ADMD, versus those involving 854 interactions with other ADMDs. 856 Basic types of ADMDs include: 858 Edge: Independent transfer services, in networks at the edge of 859 the Internet Mail service. 861 User: End-user services. These might be subsumed under an Edge 862 service, such as is common for web-based email access. 864 Transit: These are Mail Service Providers (MSP) offering value- 865 added capabilities for Edge ADMDs, such as aggregation and 866 filtering. 868 Note that Transit services are quite different from packet-level 869 transit operation. Whereas end-to-end packet transfers usually go 870 through intermediate routers, email exchange across the open Internet 871 is often directly between the Edge ADMDs, at the email level. 873 +--------+ +--------+ +--------+ 874 | ADMD#1 | | ADMD#3 | | ADMD#4 | 875 | ------ | | ------ | | ------ | 876 | | +----------------------->| | | | 877 | User | | |--Edge--+--->|--User | 878 | | | | +--->| | | | 879 | V | | | +--------+ +--------+ 880 | Edge---+---+ | 881 | | | +----------+ | 882 +--------+ | | ADMD#2 | | 883 | | ------ | | 884 | | | | 885 +--->|-Transit--+---+ 886 | | 887 +----------+ 889 Figure 2: ADministrative Management Domains (ADMD) Example 891 In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM 892 signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM 893 verification. 895 The distinction between Transit network and Edge network transfer 896 services is primarily significant because it highlights the need for 897 concern over interaction and protection between independent 898 administrations. The interactions between functional components 899 within a single ADMD are subject to the policies of that domain. 900 Although any pair of ADMDs can arrange for whatever policies they 901 wish, Internet Mail is designed to permit inter-operation without 902 prior arrangement. 904 Common ADMD examples are: 906 Enterprise Service Providers: 908 Operators of an organization's internal data and/or mail 909 services. 911 Internet Service Providers: 913 Operators of underlying data communication services that, in 914 turn, are used by one or more Relays and Users. It is not 915 necessarily their job to perform email functions, but they 916 can, instead, provide an environment in which those 917 functions can be performed. 919 Mail Service Providers: 921 Operators of email services, such as for end-users, or 922 mailing lists. 924 Authors' Addresses 926 Tony Hansen 927 AT&T Laboratories 928 200 Laurel Ave. 929 Middletown, NJ 07748 930 USA 932 Email: tony+dkimov@maillennium.att.com 933 Dave Crocker 934 Brandenburg InternetWorking 935 675 Spruce Dr. 936 Sunnyvale, CA 94086 937 USA 939 Email: dcrocker@bbiw.net 941 Phillip Hallam-Baker 942 VeriSign Inc. 944 Email: pbaker@verisign.com 946 Full Copyright Statement 948 Copyright (C) The IETF Trust (2008). 950 This document is subject to the rights, licenses and restrictions 951 contained in BCP 78, and except as set forth therein, the authors 952 retain all their rights. 954 This document and the information contained herein are provided on an 955 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 956 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 957 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 958 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 959 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 960 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 962 Intellectual Property 964 The IETF takes no position regarding the validity or scope of any 965 Intellectual Property Rights or other rights that might be claimed to 966 pertain to the implementation or use of the technology described in 967 this document or the extent to which any license under such rights 968 might or might not be available; nor does it represent that it has 969 made any independent effort to identify any such rights. Information 970 on the procedures with respect to rights in RFC documents can be 971 found in BCP 78 and BCP 79. 973 Copies of IPR disclosures made to the IETF Secretariat and any 974 assurances of licenses to be made available, or the result of an 975 attempt made to obtain a general license or permission for the use of 976 such proprietary rights by implementers or users of this 977 specification can be obtained from the IETF on-line IPR repository at 978 http://www.ietf.org/ipr. 980 The IETF invites any interested party to bring to its attention any 981 copyrights, patents or patent applications, or other proprietary 982 rights that may cover technology that may be required to implement 983 this standard. Please address the information to the IETF at 984 ietf-ipr@ietf.org. 986 Acknowledgment 988 Funding for the RFC Editor function is provided by the IETF 989 Administrative Support Activity (IASA).