idnits 2.17.1 draft-ietf-dkim-overview-06.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 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 906. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 672 has weird spacing: '... |pass fail ...' -- 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 (November 11, 2007) is 6011 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Internet' is mentioned on line 655, but not defined == Unused Reference: 'I-D.kucherawy-sender-auth-header' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC4870' is defined on line 837, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-09 -- 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 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 16 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: May 14, 2008 Brandenburg InternetWorking 6 P. Hallam-Baker 7 VeriSign Inc. 8 November 11, 2007 10 DomainKeys Identified Mail (DKIM) Service Overview 11 draft-ietf-dkim-overview-06 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 May 14, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 DomainKeys Identified Mail (DKIM) allows an organization to take 45 responsibility for a message, in a way that can be validated by a 46 recipient. The organization can be the author's, the originating 47 sending site, an intermediary, or one of their agent's. DKIM defines 48 a domain-level digital signature authentication framework for email, 49 using public-key cryptography and key server technology. This 50 permits verifying the signer of a message, as well as the integrity 51 of its contents. The ultimate goal of this framework is to permit a 52 signing domain to assert responsibility for a message, thus proving 53 and protecting the identity associated with the message and the 54 integrity of the messages itself, while retaining the functionality 55 of Internet email as it is known today. Such protection of email 56 identity can assist in the global control of "spam" and "phishing". 57 This document provides an overview of the DKIM service and describes 58 how it can fit into a messaging service. It also describes how DKIM 59 relates to other IETF message signature technologies. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5 66 2. Internet Mail Background . . . . . . . . . . . . . . . . . . . 5 67 2.1. Administrative Management Domain (ADMD) . . . . . . . . . 6 68 2.2. DKIM Placement within an ADMD . . . . . . . . . . . . . . 8 69 3. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8 70 4. The Role of Trust . . . . . . . . . . . . . . . . . . . . . . 10 71 5. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10 73 5.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11 74 6. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6.1. The Basic Signing Service . . . . . . . . . . . . . . . . 13 76 6.2. Characteristics of a DKIM signature . . . . . . . . . . . 13 77 6.3. The Selector construct . . . . . . . . . . . . . . . . . . 13 78 6.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. Service Architecture . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Administration and Maintenance . . . . . . . . . . . . . . 16 81 7.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17 83 7.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17 84 7.5. Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 11. Informative References . . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Intellectual Property and Copyright Statements . . . . . . . . . . 20 92 1. Introduction 94 DomainKeys Identified Mail (DKIM) allows an organization to take 95 responsibility for a message, in a way that can be validated by a 96 recipient. The organization can be the author's, the originating 97 sending site, an intermediary, or one of their agent's. DKIM defines 98 a domain-level digital signature authentication framework for email, 99 using public-key cryptography and key server technology. This 100 permits verifying the signer of a message, as well as the integrity 101 of its contents. DKIM accomplishes this by defining a domain-level 102 authentication framework for email using public-key cryptography and 103 key server technology [RFC4871]. This permits verifying a message 104 source, an intermediary, or one of their agents, as well as the 105 integrity of its contents. DKIM will also provide a mechanism that 106 permits potential email signers to publish information about their 107 email signing practices; this will permit email receivers to make 108 additional assessments of unsigned messages. 110 The ultimate goal of this framework is to permit a domain to assert 111 responsibility for a message, thus proving and protecting the 112 identity associated with the message and the integrity of the 113 messages itself, while retaining the functionality of Internet email 114 as it is known today. Such protection of email identity, can assist 115 in the global control of "spam" and "phishing". 117 This document provides a description of DKIM's architecture and 118 functionality. It is intended for those who are adopting, 119 developing, or deploying DKIM. It also will be helpful for those who 120 are considering extending DKIM, either into other areas of use or to 121 support additional features. This Overview does not provide 122 information on threats to DKIM or email, or details on the protocol 123 specifics, which can be found in [RFC4871] and [RFC4686], 124 respectively. The document assumes a background in basic network 125 security technology and services. 127 Neither this document nor DKIM attempt 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. Prior Work 138 Historical email assessment based on identity has been based on the 139 IP Address of a system that sent the message. The Address is 140 obtained via underlying Internet information mechanisms and is 141 therefore trusted to be accurate. Besides having some known security 142 weaknesses, the use of Addresses present a number of functional and 143 operational problems. Consequently there is an industry desire to 144 use a more stable value that has better correspondence to 145 organizational boundaries. Domain Names are viewed as satisfying 146 this need. 148 There have been four previous efforts at standardizing an Internet 149 email signature scheme: 151 o Privacy Enhanced Mail (PEM) was first published in 1987. 152 [RFC0989] 154 o PEM eventually transformed into MIME Object Security Services 155 (MOSS) in 1995. [RFC1848] Today, these two are only of historical 156 interest. 158 o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and 159 first released in 1991. [RFC1991] A later version was 160 standardized as OpenPGP. [RFC2440] [RFC3156] 161 [I-D.ietf-openpgp-rfc2440bis] 163 o RSA Security independently developed Secure MIME (S/MIME) to 164 transport a PKCS #7 data object. [RFC3851] 166 Development of S/MIME and OpenPGP have continued. While both have 167 achieved a significant user base, neither have achieved ubiquity in 168 deployment or use, and their goals differ from those of DKIM. 170 To the extent that other message-signing services might have been 171 adapted to do the job that DKIM is designed to perform, it was felt 172 that re-purposing any of those would be more problematic than 173 creating a separate service. That said, DKIM uses security algorithm 174 components that have a long history, including use within some of 175 those other messaging security services. 177 DKIM has a distinctive approach for distributing and vouching for 178 keys. It uses a key-centric Public Key Infrastructure (PKI) rather 179 than the more typical approaches based on a certificate in the styles 180 of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the 181 owner of a key asserts its validity, rather than relying on the key 182 having a broader semantic implication of the assertion, such as a 183 quality assessment of the key's owner. DKIM treats quality 184 assessment as an independent, value-added service, beyond the initial 185 work of deploying a verifying signature service. 187 Further, DKIM's PKI is supported by adding additional information 188 records to the existing Domain Name System (DNS) [RFC1034], rather 189 than requiring deployment of a new query infrastructure. This 190 approach has significant operational advantages. First, it avoids 191 the considerable barrier of creating a new infrastructure; hence it 192 leverages a global base of administrative experience and highly 193 reliable distributed operation. Second, the technical aspect of the 194 DNS is already known to be efficient. Any new service would have to 195 undergo a period of gradual maturation, with potentially problematic 196 early-stage behaviors. By (re-)using the DNS, DKIM avoids these 197 growing pains. 199 1.2. Discussion Venue 201 NOTE TO RFC EDITOR: This "Discussion Venue" section is to be 202 removed prior to publication. 204 This document is being discussed on the DKIM mailing list, 205 ietf-dkim@mipassoc.org. 207 2. Internet Mail Background 209 Internet Mail has a simple split between the user world, in the form 210 of Mail User Agents (MUA), and the transmission world, in the form of 211 the Mail Handling Service (MHS) composed of Mail Transfer Agents 212 (MTA). The MHS is responsible for accepting a message from one user, 213 the author, and delivering it to one or more other users, the 214 recipients. This creates a virtual MUA-to-MUA exchange environment. 215 The first component of the MHS is called the Mail Submission Agent 216 (MSA) and the last is called the Mail Delivery Agent (MDA). 218 An email Mediator is both an inbound MDA and outbound MSA. It takes 219 delivery of a message and reposts it for further distribution, 220 retaining the original From header field. A mailing list is a common 221 example of a Mediator 223 The modern Internet Mail service is marked by many independent 224 operators, many different components for providing users with service 225 and many other components for performing message transfer. 226 Consequently, it is necessary to distinguish administrative 227 boundaries that surround sets of functional components, which are 228 subject to coherent operational policies. 230 As expanded on below, every MSA is a candidate for signing using 231 DKIM, and every MDA is a candidate for doing DKIM verification. 233 2.1. Administrative Management Domain (ADMD) 235 Operation of Internet Mail services is apportioned to different 236 providers (or operators). Each can be composed of an independent 237 ADministrative Management Domain (ADMD). An ADMD operates with an 238 independent set of policies and interacts with other ADMDs according 239 to differing types and amounts of trust. Examples include: an end- 240 user operating their desktop client that connects to an independent 241 email service, a department operating a submission agent or a local 242 Relay, an organization's IT group that operates enterprise Relays, 243 and an ISP operating a public shared email service. 245 Each of these can be configured into many combinations of 246 administrative and operational relationships, with each ADMD 247 potentially having a complex arrangement of functional components. 248 Figure 1 depicts the relationships among ADMDs. Perhaps the most 249 salient aspect of an ADMD is the differential trust that determines 250 its policies for activities within the ADMD, versus those involving 251 interactions with other ADMDs. 253 Basic types of ADMDs include: 255 Edge: Independent transfer services, in networks at the edge of 256 the Internet Mail service. 258 User: End-user services. These might be subsumed under an Edge 259 service, such as is common for web-based email access. 261 Transit: These are Mail Service Providers (MSP) offering value- 262 added capabilities for Edge ADMDs, such as aggregation and 263 filtering. 265 Note that Transit services are quite different from packet-level 266 transit operation. Whereas end-to-end packet transfers usually go 267 through intermediate routers, email exchange across the open Internet 268 is often directly between the Edge ADMDs, at the email level. 270 +--------+ +--------+ +--------+ 271 | ADMD#1 | | ADMD#3 | | ADMD#4 | 272 | ------ | | ------ | | ------ | 273 | | +----------------------->| | | | 274 | User | | |--Edge--+--->|--User | 275 | | | | +--->| | | | 276 | V | | | +--------+ +--------+ 277 | Edge---+---+ | 278 | | | +----------+ | 279 +--------+ | | ADMD#2 | | 280 | | ------ | | 281 | | | | 282 +--->|-Transit--+---+ 283 | | 284 +----------+ 286 Figure 1: ADministrative Management Domains (ADMD) Example 288 In Figure 1, ADMD numbers 1 and 2 are candidates for doing DKIM 289 signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM 290 verification. 292 The distinction between Transit network and Edge network transfer 293 services is primarily significant because it highlights the need for 294 concern over interaction and protection between independent 295 administrations. The interactions between functional components 296 within an ADMD are subject to the policies of that domain. 298 Common ADMD examples are: 300 Enterprise Service Providers: 302 Operators of an organization's internal data and/or mail 303 services. 305 Internet Service Providers: 307 Operators of underlying data communication services that, in 308 turn, are used by one or more Relays and Users. It is not 309 necessarily their job to perform email functions, but they 310 can, instead, provide an environment in which those 311 functions can be performed. 313 Mail Service Providers: 315 Operators of email services, such as for end-users, or 316 mailing lists. 318 2.2. DKIM Placement within an ADMD 320 It is expected that the most common venue for a DKIM implementation 321 will be within the infrastructures of the originating organization's 322 outbound service and and the receiving organization's inbound 323 service, such as a department or a boundary MTA. DKIM can be 324 implemented in an author's or recipient MUA, but this is expected to 325 be less typical, since it has higher administration and support 326 costs. 328 A Mediator, such as a mailing list, often can re-post a message 329 without breaking the DKIM signature. Furthermore it can add its own 330 signature. This can be added by the Mediator software itself, or by 331 any outbound component in the Mediator's ADMD. 333 3. The DKIM Value Proposition 335 The nature and origins of a message are often falsely stated. As a 336 foundation for distinguishing legitimate mail, DKIM provides a means 337 of associating a verifiable identity with a message. Given the 338 presence of that identity, a receiver can make decisions about 339 further handling of the message, based upon assessments of that 340 identity. 342 Receivers who successfully verify a signature can use information 343 about the signer as part of a program to limit spam, spoofing, 344 phishing, or other undesirable behavior. DKIM does not, itself, 345 prescribe any specific actions by the recipient; rather it is an 346 enabling technology for services that do. 348 These services will typically: 350 1. Verify an identity 352 2. Determine whether the identity is known or unknown 354 3. Determine whether a known identity is trusted 356 The role of DKIM is in the first two of these; DKIM is an enabler for 357 the third. 359 An attack is made against an organization or against customers of an 360 organization. The name of the organization is linked to particular 361 Internet domain names. One point of leverage used by attackers is 362 either to spoof a legitimate domain name, or to use a "cousin" name 363 that is similar to one that is legitimate, but is not controlled by 364 the target organization. A DKIM-based accreditation service can 365 enforce a basic separation between domains used by such known 366 organizations and domains used by others. 368 DKIM signatures can be created by a direct handler of a message, 369 either as its originator or as an intermediary. It can also be 370 created by an independent service, providing assistance to a handler 371 of the message. Whoever does the signing chooses the domain name to 372 be used as the basis for later assessments. Hence, reputation 373 associated with that domain name is the basis for evaluating whether 374 to trust the message for delivery. The owner of the domain name 375 being used for a DKIM signature is declaring that they are 376 accountable for the message. 378 DKIM is intended to be a value-added feature for email. Mail that is 379 not signed by DKIM is handled in the same way as it was, before DKIM 380 was defined; it continues to be evaluated by established analysis and 381 filtering techniques. Over time, widespread DKIM adoption could 382 permit more strict handling of messages that are not signed. However 383 early benefits do not require this and probably do not warrant this. 385 It is important to be clear about the narrow scope of DKIM's 386 capabilities. It is an enabling technology, intended for use in the 387 larger context of determining message legitimacy. This larger 388 context is complex, so that it is easy to assume that a component 389 like DKIM, which actually provides only a limited service, instead 390 satisfies the broader set of requirements. A DKIM signature: 392 o Does not offer any assertions about the behaviors of the identity 393 doing the signing. 395 o Does not prescribe any specific actions for receivers to take upon 396 successful signature verification. 398 o Does not provide protection after signature verification. 400 o Does not protect against re-sending (replay of) a message that 401 already has a verified signature; therefore a transit intermediary 402 or a recipient can re-post the message in such a way that the 403 signature would remain verifiable, although the new recipient(s) 404 would not have been specified by the author. 406 4. The Role of Trust 408 As mentioned above, DKIM lets you verify the identity of a signer and 409 is an enabler for determining whether a now-known identity is 410 trusted; it does not itself provide that determination. Deciding 411 whether a non-known identity can be trusted must be handled by 412 accreditation and reputation services that are themselves trustable. 414 An accreditation service provides an assessment of a sender's 415 trustworthiness on behalf of the sender. They reflect the statement 416 "this signer says they are good and I concur with that statement." 417 Accreditation services are almost always network-based. 419 A reputation service provides an assessment of a sender's 420 trustworthiness on behalf of the receiver. They reflect the 421 statements "based on their past history or some private knowledge 422 about them, this signer can be trusted" or "not trusted." Reputation 423 services can be network-based or be based on local white lists and 424 black lists. 426 5. DKIM Goals 428 DKIM adds an end-to-end authentication mechanism to the existing 429 email transfer infrastructure. This motivates functional goals about 430 authentication and operational goals about integration with the 431 existing email service. 433 5.1. Functional Goals 435 5.1.1. Use Domain-level granularity for assurance. 437 OpenPGP and S/MIME apply the end-to-end principle in terms of 438 individual originators and recipients, notably using full email 439 addresses. DKIM seeks accountability at the more coarse granularity 440 of an organization or, perhaps, a department. An existing Internet 441 service construct that enables this granularity is the Domain Name 442 [RFC1034], to which the signing key record is bound. Further DKIM 443 signing and/or validating can be implemented anywhere along the 444 transit path, rather than only in the end systems or only in the 445 boundary MTA. 447 5.1.2. Allow delegation of signing to independent parties. 449 Different parties have different roles in the process of email 450 exchange. Some are easily visible to end users and others are 451 primarily visible to operators of the service. DKIM needs to support 452 signing by any of these different parties and needs to permit them to 453 sign with any domain name that they deem appropriate (and for which 454 they are authorized.) As an example an organization that creates 455 email content often delegates portions of its processing or 456 transmission to an outsourced group. DKIM supports this mode of 457 activity, in a manner that is not visible to end users. 459 5.1.3. Distinguish the core authentication mechanism from its 460 derivative uses. 462 An authenticated identity can be subject to a variety of processing 463 policies, either ad hoc or standardized. The only semantics inherent 464 to a DKIM signature is that the signer is asserting (some) 465 responsibility for the message. All other mechanisms and meanings 466 are independent of this core service. One such mechanism might 467 assert a relationship between the signing identity and the author, as 468 specified in the From header field's domain identity[RFC2822]. 469 Another might specify how to treat an unsigned message with that From 470 field domain. 472 5.1.4. Retain ability to have anonymous email. 474 The ability to send a message that does not identify its author is 475 considered to be a valuable quality of the current email service that 476 needs to be retained. DKIM is compatible with this goal since it 477 permits an email system operator to be authenticated, rather than the 478 content author. Knowing that a message definitely came from 479 example.com does not threaten the anonymity of the user who authored 480 it, if it is still possible to obtain effectively anonymous accounts 481 at example.com. 483 5.2. Operational Goals 485 5.2.1. Treat verification failure the same as no signature present. 487 OpenPGP and S/MIME were both designed for strong cryptographic 488 protection. This included treating verification failure as message 489 failure. As a sub-goal to the requirement for transparency, a DKIM 490 signature verifier is to treat messages with signatures that fail as 491 if they were unsigned. Hence the message will revert to normal 492 handling, through the receiver's existing filtering mechanisms. 493 Thus, a sender cannot apply a broken signture and force a message to 494 be treated any differently than if the signature weren't there. 496 5.2.2. Make signatures transparent to non-supporting recipients. 498 S/MIME and OpenPGP both modify the message body. Hence, their 499 presence is potentially visible to email recipients and their user 500 software needs to process the associated constructs. In order to 501 facilitate incremental adoption, DKIM is designed to be transparent 502 to recipients that do not support it. A DKIM signature cannot "get 503 in the way" for such recipients. 505 5.2.3. Permit incremental adoption for incremental benefit. 507 DKIM can immediately provide benefits between any two organizations 508 that exchange email and implement DKIM. In the usual manner of 509 "network effects", the benefits of DKIM increase dramatically as its 510 adoption increases. 512 Although it is envisioned that this mechanism will call upon 513 independent services to aid in the assessment of DKIM results, they 514 are not essential in order to obtain initial benefit. For example 515 DKIM allows (possibly large) pair-wise sets of email providers and 516 spam filtering companies to distinguish mail that is associated with 517 a known organization, from mail that might deceptively purport to 518 have the affiliation. This in turn allows the development of 519 "whitelist" schemes whereby authenticated mail from a known source 520 with good reputation is allowed to bypass some spam filters. 522 In effect the email receiver is using their set of known 523 relationships to generate their own reputation data. This works 524 particularly well for traffic between large sending providers and 525 large receiving providers. However it also works well for any 526 operator, public or private, that has mail traffic dominated by 527 exchanges among a stable set of organizations. 529 5.2.4. Minimize the amount of required infrastructure 531 A new service, or an enhancement to an existing service, requires 532 adoption by some number of systems, before it can be useful. The 533 greater the number of required adopters, the higher the adoption 534 barrier. This becomes particularly serious when adoption is required 535 by intermediary -- that is, infrastructure -- service providers. In 536 order to allow early adopters to gain early benefit, DKIM makes no 537 changes to the core Internet Mail service and, instead, can provide a 538 useful benefit for any signer/verifier pair of participants 539 exchanging mail. Similarly, DKIM's reliance on the Domain Name 540 System greatly reduces the amount of new administrative 541 infrastructure that is need, across the open Internet. 543 5.2.5. Permit wide range of deployment choices. 545 DKIM can be deployed at a variety of places within an organization's 546 email service. This permits the organization to choose how much or 547 how little they want DKIM to be part of their service, rather than 548 part of a more localized operation. 550 6. DKIM Function 552 DKIM has a very constrained set of capabilities, primarily targeting 553 email while it is in transit, from an author to a set of recipients. 554 It creates the ability to associate verifiable information with a 555 message, especially a responsible identity. When a message is not 556 signed, DKIM permits the identity of the sender to be used for 557 obtaining information about their signing practices. 559 6.1. The Basic Signing Service 561 With the DKIM signature mechanism, a signer chooses a signing 562 identity based on their domain name, performs digital signing on the 563 message, and records signature information in a DKIM header field. A 564 verifier obtains the domain name and the "selector" from the DKIM 565 header field, queries for a public key associated with the name, and 566 verifies the signature. 568 DKIM permits any domain name to be used for signing, and supports 569 extensible choices for various algorithms. As is typical for 570 Internet standards, there is a core set of algorithms that all 571 implementations are required to support, in order to guarantee basic 572 interoperability. This ensures an initial ability to interoperate. 574 DKIM permits restricting the use of a signature key to particular 575 types of services, such as only for email. This is helpful when 576 delegating signing authority, such as to a particular department or 577 to a third-party outsourcing service. 579 With DKIM the signer explicitly lists the headers that are signed. 580 By choosing the minimal set of headers needed, the signature is 581 likely to be considerably more robust against the handling the 582 vagaries of intermediary MTAs. 584 6.2. Characteristics of a DKIM signature 586 A DKIM signature covers the message body and selected header fields. 587 The signer computes a hash of the selected header fields and another 588 hash of the body. The signer then uses a private key to 589 cryptographically encode this information, along with other signing 590 parameters. Signature information is placed into a new [RFC2822] 591 header field of the message. 593 6.3. The Selector construct 595 A signature is associated with a domain name, as specified in the 596 "i=" (or "d=" if "i=" is not present) DKIM-Signature header field 597 parameters. That domain name is the complete identity used for 598 making assessments about the signer. However this name is not 599 sufficient for making a DNS query to obtain the key needed to verify 600 the signature. 602 A single domain can use multiple signing keys and/or multiple 603 signers. To support this, DKIM identifies a particular signature as 604 a combination of the domain name and an added field, called the 605 "selector", coded into separate DKIM-Signature header field 606 parameters. 608 NOTE: The selector is not intended to be part of the domain name 609 that is used for making assessments. Rather, the selector is 610 strictly reserved for use in administering keys that are 611 associated with the domain name. If the selector becomes part of 612 a name assessment mechanism, then there is no remaining mechanism 613 for making a transition from an old, or compromised, key to a new 614 one. 616 Signers often need to support multiple assessments about their 617 organization, such as to distinguish one type of message from 618 another, or one portion of the organization from another. To permit 619 assessments that are independent, one method is for an organization 620 to use different sub-domains in the "d=" parameter, such as 621 "transaction.example.com" versus "newsletter.example.com", or 622 "productA.example.com" versus "productB.example.com". 624 6.4. Verification 626 After a message has been signed, any agent in the message transit 627 path can verify the signature, to determine that the signing identity 628 took responsibility for the message. Message recipients can verify 629 the signature by querying the DNS for the signer's domain directly, 630 to retrieve the appropriate public key, and thereby confirm that the 631 message was attested to by a party in possession of the private key 632 for the signing domain. Typically, verification will be done by an 633 agent in the ADMD of the message recipient. 635 7. Service Architecture 637 The DKIM service is divided into components that can be performed 638 using different, external services, such as for key retrieval. 639 However the basic DKIM signing specification defines an initial set 640 of these services, in order to ensure a basic level of 641 interoperability. 643 | 644 |- RFC2822 Message 645 V 646 +------------------------------------+ 647 | ORIGINATING OR RELAYING ADMD (MSA) | 648 | | 649 +..>| Sign Message | 650 . +--------------+---------------------+ 651 . | 652 .private | 653 +---+---+ | 654 | Key | | +-----------+ 655 | Store | [Internet] | Sender | 656 +---+---+ | | Practices | 657 .public | +-----+-----+ 658 . V . 659 . +-----------------------------------+ . 660 . | RELAYING OR DELIVERING ADMD (MDA) | . 661 . | | . 662 . | Message Signed? | . 663 . +-------+----------------+----------+ . 664 . |yes |no . 665 . V V . 666 . +-----------+ +-----------+ . 667 +.....>| Verify | +-->| Check |<.......+ 668 | Signature | | | Practices |<.......+ 669 +---+-----+-+ | +---+-------+ . 670 | | | | . 671 | +---+ | . 672 |pass fail | . 673 V | +-----+-----+ 674 +--------+ | | Local | 675 +.......>| Assess | | | Sender | 676 . | Signer | | | Practices | 677 . +---+----+ | +-----------+ 678 . assessment| | 679 . +------+ +------+ 680 . | | 681 +-+-----------+ V V 682 | Reputation/ | +-----------+ 683 |Accreditation| | Message | 684 | Info | | Filtering | 685 +-----+-------+ | Engine | 686 +-----------+> 688 Figure 2: DKIM Service Architecture 690 As shown in Figure 2, basic message processing is divided between the 691 MSA and the MDA. 693 The MSA The MSA signs the message, using private information from 694 the Key Store. 696 The MDA The MDA verifies the signature or determines whether a 697 signature was required. Verifying the signature uses public 698 information from the Key Store. If the signature passes, 699 reputation information is used to asses the signer and that 700 information is passed to the message filtering system. If the 701 signature fails or there is no signature, information about the 702 sender's practices is retrieved remotely and/or locally, and that 703 information is passed to the message filtering system. 705 Note: Figure 2 does not show the affects on the flow of multiple 706 signatures or third-party signatures. 708 7.1. Administration and Maintenance 710 A number of tables and services are used to provide external 711 information. Each of these introduces administration and maintenance 712 requirements. 714 Key Store DKIM uses public/private (asymmetric) key technology. The 715 signer users a private key and the validator uses the 716 corresponding public key. The current DKIM signing specification 717 provides for querying the Domain Names Service (DNS), to permit a 718 validator to obtain the public key. The signing organization 719 therefore must have a means of adding a key to the DNS, for every 720 selector/domain-name combination. Further, the signing 721 organization needs policies for distributing and revising keys. 723 Sender Practices If a message contains a valid signature, then the 724 verifier can evaluate the associated domain name's reputation. If 725 a message does not contain a valid signature, that fact could be 726 useful, if the verifier can discover information about the DKIM- 727 related practices of one of the agents purportedly involved with 728 the message, such as the domain listed in the author's FROM header 729 field. Such information might come from tables developed through 730 private agreement or from standards-based mechanisms. As they are 731 defined, each domain name owner will need to consider what 732 information to publish through the mechanism and then will need to 733 create and maintain it. 735 Reputation/Accreditation "Reputation/Accreditation" provides 736 quality-assessment information that is associated with a domain 737 name, and comes in many forms and from many sources. DKIM does 738 not define these services. It's relevance to them is to provide a 739 validated domain name, upon which assessments can be made. 741 7.2. Signing 743 Signing can be performed by a component of the ADMD that creates the 744 message, and/or within any ADMD, along the relay path. The signer 745 uses the appropriate private key. 747 7.3. Verifying 749 Verification can be performed by any functional component along the 750 relay and delivery path. Verifiers retrieve the public key based 751 upon the parameters stored in the message. 753 7.4. Unverified or Unsigned Mail 755 Note that a failed signature causes the message to be treated in the 756 same manner as one that is unsigned. Messages lacking a valid 757 originator signature (a signature associated with the originator of 758 the message as opposed to a signature associated with an 759 intermediary) prompt a query for any published "sender practices" 760 information, as an aid in determining whether the sender information 761 has been used without authorization. 763 7.5. Evaluating 765 The Figure shows the verified identity as being used to assess an 766 associated reputation, but it could be applied for other tasks, such 767 as management tracking of mail. A popular use of reputation 768 information is as input to a filtering engine that decides whether to 769 deliver -- and possibly whether to specially mark -- a message. 770 Filtering engines have become complex and sophisticated. Their 771 details are outside of DKIM's scope, other than the expectation that 772 DKIM-related information is added to the varied soup of rules used by 773 the engines. The rules can cover signed messages and can deal with 774 unsigned messages from a domain, if the domain has published 775 information about is practices 777 8. Security Considerations 779 TBD 781 9. IANA Considerations 783 TBD 785 10. Acknowledgements 787 TBD 789 11. Informative References 791 [I-D.ietf-openpgp-rfc2440bis] 792 Callas, J., "OpenPGP Message Format", 793 draft-ietf-openpgp-rfc2440bis-22 (work in progress), 794 April 2007. 796 [I-D.kucherawy-sender-auth-header] 797 Kucherawy, M., "Message Header Field for Indicating 798 Message Authentication Status", 799 draft-kucherawy-sender-auth-header-09 (work in progress), 800 November 2007. 802 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 803 for Internet electronic mail: Part I: Message encipherment 804 and authentication procedures", RFC 989, February 1987. 806 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 807 STD 13, RFC 1034, November 1987. 809 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 810 Object Security Services", RFC 1848, October 1995. 812 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 813 Exchange Formats", RFC 1991, August 1996. 815 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 816 "OpenPGP Message Format", RFC 2440, November 1998. 818 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 819 April 2001. 821 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 822 April 2001. 824 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 825 "MIME Security with OpenPGP", RFC 3156, August 2001. 827 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 828 August 2001. 830 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 831 Extensions (S/MIME) Version 3.1 Message Specification", 832 RFC 3851, July 2004. 834 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 835 Identified Mail (DKIM)", RFC 4686, September 2006. 837 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 838 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 839 May 2007. 841 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 842 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 843 Signatures", RFC 4871, May 2007. 845 Authors' Addresses 847 Tony Hansen 848 AT&T Laboratories 849 200 Laurel Ave. 850 Middletown, NJ 07748 851 USA 853 Email: tony+dkimov@maillennium.att.com 855 Dave Crocker 856 Brandenburg InternetWorking 857 675 Spruce Dr. 858 Sunnyvale, CA 94086 859 USA 861 Email: dcrocker@bbiw.net 863 Phillip Hallam-Baker 864 VeriSign Inc. 866 Email: pbaker@verisign.com 868 Full Copyright Statement 870 Copyright (C) The IETF Trust (2007). 872 This document is subject to the rights, licenses and restrictions 873 contained in BCP 78, and except as set forth therein, the authors 874 retain all their rights. 876 This document and the information contained herein are provided on an 877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 879 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 880 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 881 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 884 Intellectual Property 886 The IETF takes no position regarding the validity or scope of any 887 Intellectual Property Rights or other rights that might be claimed to 888 pertain to the implementation or use of the technology described in 889 this document or the extent to which any license under such rights 890 might or might not be available; nor does it represent that it has 891 made any independent effort to identify any such rights. Information 892 on the procedures with respect to rights in RFC documents can be 893 found in BCP 78 and BCP 79. 895 Copies of IPR disclosures made to the IETF Secretariat and any 896 assurances of licenses to be made available, or the result of an 897 attempt made to obtain a general license or permission for the use of 898 such proprietary rights by implementers or users of this 899 specification can be obtained from the IETF on-line IPR repository at 900 http://www.ietf.org/ipr. 902 The IETF invites any interested party to bring to its attention any 903 copyrights, patents or patent applications, or other proprietary 904 rights that may cover technology that may be required to implement 905 this standard. Please address the information to the IETF at 906 ietf-ipr@ietf.org. 908 Acknowledgment 910 Funding for the RFC Editor function is provided by the IETF 911 Administrative Support Activity (IASA).