idnits 2.17.1 draft-ietf-dkim-overview-03.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 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1793. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-dkim-base]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 824: '...against other processes SHOULD be used...' RFC 2119 keyword, line 825: '...ticular, great care MUST be taken when...' RFC 2119 keyword, line 847: '... implementations SHOULD provide a conv...' RFC 2119 keyword, line 850: '...rted however such mechanism(s) MUST be...' RFC 2119 keyword, line 859: '... SHOULD support use of cryptographic...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 23, 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Internet' is mentioned on line 764, but not defined == Missing Reference: 'Report' is mentioned on line 779, but not defined == Missing Reference: 'LOGOTYPE' is mentioned on line 1495, but not defined == Missing Reference: 'PHB-NIST' is mentioned on line 1497, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-dkim-base-06 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- 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 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 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: April 26, 2007 Brandenburg InternetWorking 6 P. Hallam-Baker 7 VeriSign Inc. 8 October 23, 2006 10 DomainKeys Identified Mail (DKIM) Service Overview 11 draft-ietf-dkim-overview-03 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 April 26, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 DomainKeys Identified Mail (DKIM) associates a "responsible" identity 45 with a message and provides a means of verifying that the association 46 is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level 47 authentication framework for email using public-key cryptography and 48 key server technology. This permits verifying the source or 49 intermediary for a message, as well as the contents of messages. The 50 ultimate goal of this framework is to permit a signing domain to 51 assert responsibility for a message, thus proving and protecting the 52 identity associated with the message and the integrity of the 53 messages itself, while retaining the functionality of Internet email 54 as it is known today. Such protection of email identity, may assist 55 in the global control of "spam" and "phishing". This document 56 provides an overview of DKIM and describes how it can fit into a 57 messaging service, how it relates to other IETF message signature 58 technologies. It also includes implementation and migration 59 considerations. 61 Note 63 This document is being discussed on the DKIM mailing list, 64 ietf-dkim@mipassoc.org. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 70 3. DKIM's Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. Treat verification failure as if unsigned. . . . . . . . 8 72 3.2. Domain-level assurance . . . . . . . . . . . . . . . . . 8 73 3.3. Incremental adoption . . . . . . . . . . . . . . . . . . 8 74 3.4. Minimal infrastructure . . . . . . . . . . . . . . . . . 9 75 3.5. Transparent signature . . . . . . . . . . . . . . . . . . 9 76 3.6. Security policy . . . . . . . . . . . . . . . . . . . . . 9 77 4. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . . . 9 78 4.1. What is a DKIM signature? . . . . . . . . . . . . . . . . 10 79 4.2. The Selector construct . . . . . . . . . . . . . . . . . 10 80 4.3. Who validates the signature? . . . . . . . . . . . . . . 10 81 4.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . 11 82 4.5. Does DKIM eliminate anonymity for email? . . . . . . . . 11 83 4.6. Outline potential DKIM applications . . . . . . . . . . . 11 84 4.7. What is a DKIM policy? . . . . . . . . . . . . . . . . . 11 85 5. DKIM Within Existing Internet Email . . . . . . . . . . . . . 12 86 5.1. Review of Internet Mail Service Architecture . . . . . . 12 87 5.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 15 88 5.3. Impact on Email Activities . . . . . . . . . . . . . . . 16 89 5.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18 90 6. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 19 91 7. Implementation Considerations . . . . . . . . . . . . . . . . 21 92 7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 21 93 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 24 94 7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24 95 7.4. Accreditation service . . . . . . . . . . . . . . . . . . 24 96 8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 8.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 26 99 8.3. Transition strategy . . . . . . . . . . . . . . . . . . . 27 100 9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 9.1. DNS Signature Record Deployment Considerations . . . . . 28 102 9.2. Private Key Management . . . . . . . . . . . . . . . . . 30 103 9.3. Mailing List Management . . . . . . . . . . . . . . . . . 31 104 10. Outline Future Extensions . . . . . . . . . . . . . . . . . . 31 105 10.1. Introducing a new signing algorithm . . . . . . . . . . . 32 106 10.2. Possible future signature algorithm choices . . . . . . . 33 107 10.3. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33 108 10.4. Trusted Third Party Assertions . . . . . . . . . . . . . 34 109 10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35 110 10.6. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 111 10.7. Verification in the Client . . . . . . . . . . . . . . . 36 112 10.8. Per user signature . . . . . . . . . . . . . . . . . . . 36 113 10.9. Encryption . . . . . . . . . . . . . . . . . . . . . . . 37 114 10.10. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38 115 10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 117 12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 39 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 119 13.1. References -- Normative . . . . . . . . . . . . . . . . . 40 120 13.2. Informative References . . . . . . . . . . . . . . . . . 40 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 122 Intellectual Property and Copyright Statements . . . . . . . . . . 42 124 1. Introduction 126 This document provides an overview of DomainKeys Identified Mail 127 (DKIM). It is intended for those who are adopting, developing, or 128 deploying DKIM. It also will be helpful for those who are 129 considering extending DKIM, either into other areas or to support 130 additional features. This Overview does not provide information on 131 threats to DKIM or email, or details on the protocol specifics, which 132 can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats], 133 respectively. The document assumes a background in basic network 134 security technology and services. 136 NOTE: It must be stressed that neither this document nor DKIM 137 attempt to provide solutions to the world's problems with spam, 138 phish, virii, worms, joe jobs, etc. DKIM creates one, basic tool 139 in what needs to be a large arsenal of tools, for improving the 140 safety of Internet mail. However by itself, DKIM is not 141 sufficient to that task and this Overview does not pursue the 142 issues of integrating DKIM into these larger efforts. Rather, it 143 is a basic introduction to the technology and its deployment. 145 NOTE: A number of sections in this document are just placeholders, 146 for now. 148 There have been four other efforts at standardizing an email 149 signature scheme: 151 o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989] 152 and eventually transformed into MIME Object Security Services in 153 1995 [RFC1848]. Today, they are only of historical interest. 155 o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and 156 first released in 1991.[RFC1991] A later version was standardized 157 as OpenPGP. [RFC3156] 159 o RSA Security, the holder of the patent rights to the principle 160 public key cryptography algorithm, independently developed Secure 161 MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851] 163 Development of S/MIME and OpenPGP has continued. While both have 164 achieved a significant user base neither has achieved ubiquity in 165 deployment or use and their goals differ from those of DKIM. 167 In principle the S/MIME protocol can support semantics such as domain 168 level signatures or make use of keys stored in the DNS. However the 169 currently deployed base does not and modifying it to do so would 170 require extensive effort. 172 Unlike all four previous IETF email security initiatives, DKIM 173 employs a key centric Public Key Infrastructure (PKI) as opposed to 174 one that is based on a certificate in the style of Kohnfelder (X.509) 175 or Zimmerman (web of trust). That is, the owner of a key asserts its 176 validity, rather than relying on having a broader semantic 177 implication of the assertion, such as a quality assessment of the 178 key's owner. DKIM treats quality assessment as an independent, 179 value-added service, beyond the initial work of deploying a 180 validating signature service. 182 NOTE: It would be useful to include a citation to a general 183 discussion about PKI issues, including their long history of 184 difficulties with respect to the Internet. 186 Further, DKIM's PKI is supported as additional information records to 187 the existing Domain Name Service, rather than requiring deployment of 188 a new query infrastructure. This approach also has significant 189 performance advantages as DNS is layered on UDP and key retrieval is 190 typically achieved in a single round trip. 192 2. The DKIM Value Proposition 194 Spam can be understood as two separate problems. The first is the 195 problem of the companies that are inappropriately aggressive, in 196 sending out unsolicited marketing email. This accounts for, perhaps, 197 5% of the spam volume and is in any case usually handled by existing 198 spam filters. The second problem is rogue spam -- often involving 199 criminal activities -- mostly sent from coerced botnets of 200 compromised machines. For this latter set of mail, the origins of a 201 message are often falsely stated. 203 Even without the addition of independent accreditation services, DKIM 204 allows pair-wise sets of (possibly large) email providers and spam 205 filtering companies to distinguish mail that is associated with a 206 known organization, from mail that might deceptively purport to have 207 the affiliation. This in turn allows the development of 'whitelist' 208 schemes whereby authenticated mail from a known source with good 209 reputation is allowed to bypass some spam filters. 211 In effect the email receiver is using their set of known 212 relationships to generate their own accreditation/reputation data. 213 This works particularly well for traffic between large sending 214 providers and large receiving providers. However it also works well 215 for any operator, public or private, that has mail traffic dominated 216 by exchanges among a stable set of organizations. 218 NOTE: Perhaps add some citations to detailed discussions about spam 219 and phishing and the role of authentication and accreditation in 220 fighting them? 222 DKIM used in conjunction with a real-time blacklist allows phishing 223 emails to be preemptively blocked. The value of a cousin domain, 224 that could be mistaken for the legitimate domain, is significantly 225 reduced if the number of emails that can be successfully sent from it 226 is small. 228 Phishing attacks are typically made against trusted brands, that is, 229 names that are closely affiliated with well-known organizations. A 230 DKIM-based accreditation service can enforce a basic separation 231 between domains used by such known organizations and domains used by 232 others. 234 Receivers who successfully validate a signature can use information 235 about the signer as part of a program to limit spam, spoofing, 236 phishing, or other undesirable behavior, although the DKIM 237 specification itself does not prescribe any specific actions by the 238 recipient. 240 3. DKIM's Goals 242 DKIM lets an organization take responsibility for a message. The 243 organization taking responsibility typically is a handler of the 244 message, either as its originator or as an intermediary. It can also 245 be an independent service, providing assistance to a handler of the 246 message. Their reputation is the basis for evaluating whether to 247 trust the message for delivery. 249 The owner of the domain name being used for a DKIM signature is 250 declaring that they are accountable for the message. This means that 251 their reputation is at stake. 253 By design, DKIM purposely: 255 o is compatible with the existing email infrastructure and 256 transparent to the fullest extent possible 258 o requires minimal new infrastructure 260 o can be implemented independently of clients in order to reduce 261 deployment time 263 o does not require the use of trusted third parties (e.g., 264 certificate authorities) that might impose significant costs or 265 introduce delays to deployment 267 o can be deployed incrementally, with separate deployment of signers 268 and verifiers in either order 270 o allows delegation of signing to third parties 272 o is not intended be used for archival purposes 274 DKIM authentication provides one link in a chain of responsibility, 275 hopefully leading to better accountability by the senders. 277 3.1. Treat verification failure as if unsigned. 279 PGP and S/MIME were both designed for strong cryptographic 280 protection. This included treating validation failure as message 281 failure, at least warning the user that the message was unsigned. In 282 a small number of cases the application went even further by 283 'warning' the user whenever a signed message was received. This 284 approach has proved problematic. Hence for DKIM, the guidance is 285 that an email signature verifier is to treat messages with signatures 286 that fail as if they were unsigned. 288 It is highly unlikely that an attacker is going to add a digital 289 signature to a message unless doing so causes the message to be 290 treated more favorably than an unsigned one. Any messages that carry 291 signatures that fail verification are thus much more likely to be a 292 genuine message that has been damaged in transit than an attempted 293 forgery. It makes no sense to warn the recipient unless it is known 294 that the sender always signs email messages and that there is a high 295 probability that a forgery would be attempted. 297 3.2. Domain-level assurance 299 PGP and S/MIME apply the end-to-end principle in terms of individual 300 originators and recipients, notably using full email addresses. DKIM 301 seeks accountability at the more coarse grain of an organization or, 302 perhaps, a department. A deployed construct that enables this 303 granularity is the domain name, to which the signing key record is 304 bound. 306 3.3. Incremental adoption 308 DKIM can immediately provide benefits between any two organizations 309 that exchange email and implement DKIM. In the usual manner of 310 "network effects", the benefits of DKIM increase dramatically as its 311 adoption increases. 313 Over time, DKIM adoption might become sufficiently widespread to 314 permit special, negative handling of messages that are not signed. 315 However early benefits do not require this more-stringent 316 enforcement. 318 3.4. Minimal infrastructure 320 DKIM can be implemented at a variety of places within an 321 organization's email service. This permits the organization to 322 choose how much or how little they want DKIM to be part of their 323 infrastructure, rather than part of a more localized operation. 324 Similarly, DKIM's reliance on the Domain Name Service greatly reduces 325 the amount of new administrative infrastructure that must be deployed 326 over the open Internet. 328 Even with use of the DNS, one challenge is that it is usually 329 operated by different administrative staff than those who operate an 330 organization's email service. In order to ensure that DKIM DNS 331 records are accurate, this imposes a requirement for careful 332 coordination between the two operations groups. 334 3.5. Transparent signature 336 S/MIME and PGP both modify the message body. Hence, their presence 337 is visible to all email recipients and their user software must be 338 able to process the associated constructs. In order to facilitate 339 incremental adoption, DKIM is designed to be transparent to 340 recipients that do not support it. 342 3.6. Security policy 344 DKIM is pursuing an incremental innovation, over basic identity 345 authentication, through the publication of security policies 346 associated with one or of the identities presented in a message. For 347 example, a valid DKIM signature allows the signing party to assert 348 responsibility for a message. For a recipient to interpret an 349 unsigned message it is necessary to know whether it should expect a 350 message from that source to be signed and if so the signature 351 characteristics to expect. It would, therefore, be helpful for a 352 potential signer to be able to publish whether they sign all of their 353 message. Once this is published, recipients can choose to handle the 354 receipt of unsigned messages with added caution. 356 4. A Quick Overview of DKIM 358 DKIM has a very constrained set of capabilities, primarily targeting 359 email while it is in transit, from an originator to one or more 360 recipients. DKIM defines a mechanism by which email messages can be 361 cryptographically signed, permitting a signing domain to claim 362 responsibility for the presence of a message in the mail stream. A 363 responsible organization adds a digital signature to the message, 364 associating it with a domain name of that organization. Typically, 365 signing will be done by a service agent within the authority of the 366 message originator's Administrative Management Domain (ADMD). 367 (Signing might be performed by any of the functional components in 368 that environment, including a Mail User Agent (MUA), a Mail 369 Submission Agent (MSA), or an Internet Boundary MTA. DKIM also 370 permits signing to be performed by authorized third-parties.) 372 4.1. What is a DKIM signature? 374 A signature covers the message body and selected header fields. The 375 signer computes a hash of the selected header fields and another hash 376 of the body. They then use a private key to cryptographically encode 377 this information, along with other signing parameters. The signature 378 information is placed into a new header field of the RFC2822 379 [RFC2822] message. 381 4.2. The Selector construct 383 In order to allow a domain name to support multiple, simultaneous 384 keys, a particular signature is identified by the combination of the 385 domain name and an added field, called the "selector". Both of these 386 are coded into the DKIM-Signature header field. Selectors are 387 assigned according to the administrative needs of the signing domain, 388 such as for rolling over to a new key or for delegating of the right 389 to authenticate a portion of the namespace to a trusted third party. 391 Examples include: jun2005.eng._domainkey.example.com 393 widget.promotion._domainkey.example.com 395 NOTE: It is intended that assessments of DKIM identities be based 396 on the domain name, and not include the selector. This permits 397 the selector to be used only for key administration, rather than 398 having an effect on reputation assessment. 400 4.3. Who validates the signature? 402 After a message has been signed, any agent in the message transit 403 path can choose to validate the signature. Validation of the 404 signature, by a later agent in the path, demonstrates that the 405 signing identity took responsibility for the message 407 Message recipients can verify the signature by querying the signer's 408 domain directly to retrieve the appropriate public key, and thereby 409 confirm that the message was attested to by a party in possession of 410 the private key for the signing domain. Typically, validation will 411 be done by an agent in the ADMD of the message recipient. Again, 412 this may be done by any functional component within that environment. 413 (Notably this means that the signature can be used by the recipient 414 ADMD's filtering software, rather than requiring the recipient end- 415 user to make an assessment.) 417 4.4. What does DKIM NOT do? 419 DKIM does not: 421 o offer any assertions about the behaviors of the identity doing the 422 signing. 424 o prescribe any specific actions for receivers to take upon 425 successful (or unsuccessful) signature validation. 427 o provide protection after message delivery. 429 o protect against re-sending (replay of) a message that already has 430 a valid signature; therefore a transit intermediary or a recipient 431 can re-post the message in such a way that the signature would 432 remain valid, although the new recipient(s) would not have been 433 specified by the originator. 435 4.5. Does DKIM eliminate anonymity for email? 437 The ability to send a message that does not identify its author is 438 considered to be a valuable quality of the current email system. It 439 turns out that DKIM is particularly helpful to this goal, because a 440 DKIM signature will typically be used to identity an email system 441 operator, rather than a content author. Knowing that a mail 442 definitely came from example.com does not threaten the anonymity of 443 the user, if it is still possible to obtain effectively anonymous 444 accounts at example.com and other web mail providers. 446 4.6. Outline potential DKIM applications 448 TBD 450 4.7. What is a DKIM policy? 452 TBD 454 5. DKIM Within Existing Internet Email 456 5.1. Review of Internet Mail Service Architecture 458 Internet Mail has a simple split between the user world, in the form 459 of Mail User Agents (MUA), and the transmission world, in the form of 460 the Mail Handling Service (MHS) composed of Mail Transfer Agents 461 (MTA). The MHS is responsible for accepting a message from one User 462 and delivering it to one or more other users, creating a virtual MUA- 463 to-MUA exchange environment. The first MTA is called the Mail 464 Submission Agent (MSA) and the final MTA is called the Mail Delivery 465 Agent (MDA) 467 +--------+ 468 +---------------->| User | 469 | +--------+ 470 | ^ 471 +--------+ | +--------+ . 472 | User +--+--------->| User | . 473 +--------+ | +--------+ . 474 . | ^ . 475 . | +--------+ . . 476 . +-->| User | . . 477 . +--------+ . . 478 . ^ . . 479 . . . . 480 V . . . 481 +---+----------------+------+------+---+ 482 | . . . . | 483 | +...............>+ . . | 484 | . . . | 485 | +......................>+ . | 486 | . . | 487 | +.............................>+ | 488 | | 489 | Mail Handling Service (MHS) | 490 +--------------------------------------+ 492 Figure 1: Basic Internet Mail Service Model 494 Modern Internet Mail service is marked by many independent operators, 495 many different components for providing users with service and many 496 other components for performing message transfer. Consequently, it 497 is necessary to distinguish administrative boundaries that surround 498 sets of functional components. 500 5.1.1. Administrative Actors 502 Operation of Internet Mail services is apportioned to different 503 providers (or operators). Each can be composed of an independent 504 ADministrative Management Domain (ADMD). An ADMD operates with an 505 independent set of policies and interacts with other ADMDs according 506 to differing types and amounts of trust. Examples include an end- 507 user operating their desktop client, a department operating a local 508 Relay, an IT department operating an enterprise Relay and an ISP 509 operating a public shared email service. These can be configured 510 into many combinations of administrative and operational 511 relationships, with each ADMD potentially having a complex 512 arrangement of functional components. Figure 2 depicts the 513 relationships among ADMDs. Perhaps the most salient aspect of an 514 ADMD is the differential trust that determines its policies for 515 activities within the ADMD, versus those involving interactions with 516 other ADMDs. 518 Basic components of ADMD distinction include: 520 Edge -- Independent transfer services, in networks at the edge 521 of the Internet Mail service. 523 User -- End-user services. These might be subsumed under an 524 Edge service, such as is common for web-based email access. 526 Transit -- These are Mail Service Providers (MSP) offering 527 value-added capabilities for Edge ADMDs, such as aggregation 528 and filtering. 530 Note that Transit services are quite different from packet-level 531 transit operation. Whereas end-to-end packet transfers usually go 532 through intermediate routers, email exchange across the open Internet 533 is often directly between the Edge ADMDs, at the email level. 535 +-------+ +-------+ +-------+ 536 | ADMD1 | | ADMD3 | | ADMD4 | 537 | ----- | | ----- | | ----- | 538 | | +---------------------->| | | | 539 | User | | |-Edge--+--->|-User | 540 | | | | +--->| | | | 541 | V | | | +-------+ +-------+ 542 | Edge--+---+ | 543 | | | +---------+ | 544 +-------+ | | ADMD2 | | 545 | | ----- | | 546 | | | | 547 +--->|-Transit-+---+ 548 | | 549 +---------+ 551 Figure 2: ADministrative Management Domains (ADMD) Example 553 The distinction between Transit network and Edge network transfer 554 services is primarily significant because it highlights the need for 555 concern over interaction and protection between independent 556 administrations. The interactions between functional components 557 within an ADMD are subject to the policies of that domain. 559 Common ADMD examples are: 561 Enterprise Service Providers -- Operating an organization's 562 internal data and/or mail services. 564 Internet Service Providers -- Operating underlying data 565 communication services that, in turn, are used by one or more 566 Relays and Users. It is not necessarily their job to perform 567 email functions, but they can, instead, provide an environment 568 in which those functions can be performed. 570 Mail Service Providers -- Operating email services, such as for 571 end-users, or mailing lists. 573 5.1.2. Field Referencing Convention 575 In this document, references to structured fields of a message use a 576 two-part dotted notation. The first part cites the document that 577 contains the specification for the field and the second is the name 578 of the field. Hence is the From field in an email 579 content header [RFC2822] and is the address in the 580 SMTP "Mail From" command. [RFC2821] 582 5.2. Where to Place DKIM Functions 584 DKIM associates a "responsible" identity with a message and provides 585 a means of verifying that the association is legitimate. Deciding 586 which ADMD shall perform signing or verifying, which identity to 587 assign and which functional components to use for DKIM processing 588 depends upon the nature of the trust/reputation that is of interest 589 and the most convenient or efficient way to use it. 591 Messages may be signed or verified by any functional component within 592 an ADMD, as that domain wishes to arrange. Examples include: 594 Outbound -- MUA, MSA or boundary MTA. 596 Inbound -- Boundary MTA, MDA or MUA. 598 By having an MUA do the signing or verifying, there is no dependence 599 upon implementation by an email service infrastructure. By having an 600 MHS component do signing or verifying, there is no dependence upon 601 user training or the upgrade of potentially large numbers of user 602 applications. 604 For implementation by an ADMD's email service operators, perhaps the 605 most obvious choices within the MHS are the MSA or MDA, and the 606 outbound or inbound (boundary) MTA. By signing or verifying at the 607 MSA and MDA, respectively, this outermost portion of the MHS provides 608 true end-to-end service, and requires the smallest amount of trust of 609 the intervening service infrastructure. By signing or verifying at a 610 boundary, the smallest number of systems need modifying within an 611 ADMD and the signature is subject to the smallest amount of handling 612 that can break the signature. Note, however, that this will 613 eliminate DKIM signing for mail that stays within the ADMD. 615 The choice of identity to use might not be obvious. Examples 616 include: 618 Author -- The domain associated with the RFC2822.From field 619 provides basic authorization for the author to generate mail. 620 Because the organization controlling that domain is closest to 621 the author, they well might be in the best position to offer 622 their reputation as a basis for asserting that the content is 623 "safe". 625 Operator -- Email recipient services have long-used the IP 626 Address of a client SMTP server as the basis for assessing 627 whether to permit relay or delivery of a message. These 628 Addresses identify the operator of an email service, rather 629 than necessarily indicating the author of messages being sent 630 by that service. Use of an operator's domain name is a natural 631 extension of this model. 633 Third-party -- An independent service might wish to certify an 634 author, a message or an operator, by providing its own 635 signature to a message. Hence, evaluation of the message will 636 be based upon the identity of that third-party, rather than any 637 of the identities involved in creating or transferring the 638 message. Indeed, this model is already emerging among a number 639 of reputation-vetting services and is similar to the way a 640 credit card permits a customer to make purchases, based upon 641 the reputation of the credit card company -- and its 642 willingness to issue the card. 644 Ultimately, deciding where to sign a message will depend upon both 645 the identity being used and tradeoffs among flexibility of uses, 646 administrative control, and operational control. Deciding where to 647 verify a message will depend upon the intended use and similar 648 concerns about flexibility and control. A typical choice for 649 reputation-related verification will be to place the signature 650 verification function "close" to the message-filtering engine. 652 5.3. Impact on Email Activities 654 5.3.1. Resources 656 Although cryptographic authentication is considered to be 657 computationally expensive, the real impact of a mechanism like DKIM 658 is remarkably small. Direct impact on CPU-load has been measured to 659 be 10-15%. Mail handling tends to be I/O-intensive, so dedicated 660 email platforms tend to have unused computational capacity. It is 661 therefore likely that no new hardware will be required for these 662 systems to be able to add DKIM support. 664 5.3.2. Operations 666 The costs to deploy, administer and operate DKIM vary greatly, 667 depending upon the placement of DKIM-related modules. The greatest 668 flexibility comes from placing the modules as close as possible to 669 the end user. However this also imposes the greatest costs. The 670 most common scenarios are likely to be: 672 Boundary MTA -- Here, DKIM is used only for email external to the 673 ADMD. Administration and operation is the simplest, but could 674 cause problems for mobile users who are associated with the 675 organization but must send mail using facilities that are 676 independent of their home ADMD. It also provides no assistance 677 for inter-departmental accountability within the ADMD.. 679 MSA/MDA (Department) -- Placing DKIM support at the points of 680 submission and delivery increases the deployment costs but still 681 keeps control within the ADMD's operational staff. It avoids the 682 considerable, added costs of having to enhance all of the MUAs. 683 This does not improve the lot of mobile users who submit from 684 independent MSAs, but does provide full protection within the 685 ADMD. 687 MUA -- Obviously this can provide the most complete protection, but 688 at the cost of considerable added administrative effort. Worse, 689 there is extensive evidence that email infrastructure services 690 often perform changes to message content that can break a message 691 signature. Examples include transformation by the MSA to ensure 692 that the message is in full conformance with Internet standards 693 and transformation by Boundary MTAs, to ensure conformance with 694 organizational policies about external communications. 696 Placing DKIM support into the MUA is the only way to ensure that a 697 highly mobile user retains all of its benefits, in spite of these 698 concerns and having to send mail through independent MSAs. 700 TBD ... Challenge of mobile users. Server-resident folders -- web 701 or imap -- no problem. Laptop-resident folders, requires remote MSA 702 access or per-user keying and mobile-author awareness. 704 Key creation and replacement. Update DNS and signing component 706 5.3.3. Users 708 TBD ... Challenge of mobile users. Server-resident folders -- web 709 or imap -- no problem. Laptop-resident folders, requires remote MSA 710 access or per-user keying and mobile-author awareness. 712 Challenge of mailing lists. Different list styles warrant different 713 signature policies. 715 Can be hidden from end-user; used by filter engine. Method and 716 benefits for displaying to users unknown. 718 5.4. Migrating from DomainKeys 720 5.4.1. Signing 722 DNS Records: DKIM is upward compatible with existing DomainKeys 723 (DK) DNS records, so that a DKIM module does not automatically 724 require additional DNS administration! DKIM has enhanced the 725 DomainKeys DNS key record format by adding several optional 726 parameters. 728 Boundary MTA: Enforce signature policies and practices 730 > 732 5.4.2. Verifying 734 DNS Client: TBD 736 Verifying module: See "Signing Module". 738 5.4.3. Boundary MTA 740 Strip "local" signatures that are not local? 742 6. DKIM Service Architecture 744 DKIM provides an end-to-end service for signing and verifying 745 messages that are in transit. It is divided into components that can 746 be performed using different, external services, such as for key 747 retrieval, although the basic DKIM operation provides an initial set. 749 | 750 | - RFC2822 Message 751 V 752 +---------------------------------------------+ 753 +-----------+ | ORIGINATING OR RELAYING ADMD | 754 | | | ============================ | 755 | Signer | | | 756 | Practices +......>| SIGN MESSAGE | 757 | | | ...> ADD A SIGNATURE HEADER FIELD | 758 +-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) | 759 . . | ... COMPUTE SIGNATURE | 760 . V +----------------+----------------------------+ 761 . +-------+ | - Message 762 . | | | 1*(Domain, Selector, 763 . | Key | | Sig) 764 . | Store | [Internet] 765 . | | | 766 . +---+---+ V 767 . . +---------------------------------------------+ 768 . . | RELAYING OR DELIVERING ADMD | 769 . . | =========================== | 770 . . | | 771 . . | VERIFY MESSAGE (Verifier Practices) | 772 . . | ...> VERIFY A SIGNATURE HEADER FIELD | 773 . . | . GET A SIGNATURE | 774 . .....>| . LOOKUP PUB-KEY (Domain, Selector) | 775 . | . VERIFY SIGNATURE VALUE | 776 . | ... EVALUATE SIGNATURE CONSTRAINTS | 777 . +-------------------+-------------------------+ 778 . | - Verified Domain(s) 779 . V - [Report] 780 . +---------------------------------------------+ 781 . | | 782 . | MESSAGE DISPOSITION | 783 .............>| SIGNER PRACTICES | 784 .............>| REPUTATION | 785 . | | 786 +-----+------+ +---------------------------------------------+ 787 | | 788 | Reputation | 789 | | 790 +------------+> 792 Figure 3: DKIM Service Architecture 794 Basic message processing divides between signing the message, 795 validating the signature, and then performing further decision-making 796 based upon the validated signature. The component doing the signing 797 applies whatever signing policies are in force, including ones that 798 determine what private key to use. Validation may be performed by 799 any functional component along the relay and delivery path. The 800 public key is retrieved, based upon the parameters stored in the 801 message. The example shows use of the validated identity for 802 assessing an associated reputation. However it could be applied for 803 other tasks, such as management tracking of mail. 805 7. Implementation Considerations 807 7.1. Development 809 7.1.1. Coding Criteria for Cryptographic Applications 811 Correct implementation of a cryptographic algorithm is a necessary 812 but not a sufficient condition for coding of cryptographic 813 applications. Coding of cryptographic libraries requires close 814 attention to security considerations that are unique to cryptographic 815 applications. 817 In addition to the usual security coding considerations, such as 818 avoiding buffer or integer overflow and underflow, implementers 819 should pay close attention to management of cryptographic private 820 keys and session keys, ensuring that these are correctly initialized 821 and disposed of. 823 Operating system mechanisms that permit the confidentiality of 824 private keys to be protected against other processes SHOULD be used 825 when available. In particular, great care MUST be taken when 826 releasing memory pages to the operating system to ensure that private 827 key information is not disclosed to other processes. 829 On multiple processor and dual core architectures, certain 830 implementations of public key algorithms such as RSA may be 831 vulnerable to a timing analysis attack. 833 Support for cryptographic hardware providing key management 834 capabilities is strongly encouraged. In addition to offering 835 performance benefits, many cryptographic hardware devices provide 836 robust and verifiable management of private keys. 838 Fortunately appropriately designed and coded cryptographic libraries 839 are available for most operating system platforms under license terms 840 compatible with commercial, open source and free software license 841 terms. Use of standard cryptographic libraries is strongly 842 encouraged. These have been extensively tested, reduce development 843 time and support a wide range of cryptographic hardware. 845 7.1.1.1. Signer 847 Signer implementations SHOULD provide a convenient means of 848 generating DNS key records corresponding to the signer configuration. 849 Support for automatic insertion of key records into the DNS is also 850 highly desirable. If supported however such mechanism(s) MUST be 851 properly authenticated. 853 Means of verifying that the signer configuration is compatible with 854 the signature policy is also highly desirable. 856 Disclosure of a private signature key component to a third party 857 allows that third party to impersonate the sender. Protection of 858 private signature key data is therefore a critical concern. Signers 859 SHOULD support use of cryptographic hardware providing key management 860 features. 862 The import and export of private keys, and the ability to generate a 863 Certificate Signing Request (CSR) for certificate registration are 864 highly desirable. 866 7.1.1.2. Verifier 868 Verifiers SHOULD treat the result of the verification step as an 869 input to the message evaluation process rather than as providing a 870 final decision. The knowledge that a message is authentically sent 871 by a domain does not say much about the legitimacy of the message, 872 unless the characteristics of the domain claiming responsibility are 873 known. 875 In particular, verifiers SHOULD NOT automatically assume that an 876 email message that does not contain a signature, or that contains a 877 signature that does not validate, is forged. Verifiers should treat 878 a signature that fails to validate the same as if no signature were 879 present. 881 7.1.2. Email Handlers 883 7.1.2.1. Mail User Agent 885 DKIM is designed to support deployment and use in email components 886 other than an MUA. However an MUA may also implement DKIM features 887 directly. 889 Outbound: If an MUA is configured to send email directly, rather 890 than relayed through an outbound MTA, the MUA SHOULD be considered 891 as if it were an outbound MTA for the purposes of DKIM. An MUA 892 MAY support signing even if mail is to be relayed through an 893 outbound MTA. In this case the signature applied by the MUA may 894 be in addition to or in place of the MTA signature. 896 Inbound: An MUA MAY rely on a report of a DKIM signature 897 verification that took place at some point in the inbound MTA 898 path. An MUA MAY perform DKIM signature verification directly. 899 Such an MUA SHOULD allow for the case where mail is modified in 900 the inbound MTA path. 902 7.1.3. Mail Transfer Agent 904 It is expected that the most common venue for a DKIM implementation 905 wil be a department or a boundary MTA. 907 Outbound: An Outbound MTA should allow for automatic verification 908 of the MTA configuration such that the MTA can generate an 909 operator alert if it determines that it is (1) an edge MTA, (2) 910 configured to send email messages that do not comply with the 911 published DKIM sending policy. 913 An outbound MTA should be aware that users may employ MUAs that 914 add their own signatures and be prepared to take steps necessary 915 to ensure that the message sent is in compliance with the 916 advertised email sending policy. 918 Inbound: An inbound MTA that does not support DKIM should avoid 919 modifying messages in ways that prevent verification by other 920 MTAs, or MUAs to which the message may be forwarded. 922 Intermediaries: An email intermediary is both an inbound and 923 outbound MTA. Each of the requirements outlined in the sections 924 relating to MTAs apply. If the intermediary modifies a message in 925 a way that breaks the signature, the intermediary SHOULD 927 * deploy abuse filtering measures on the inbound mail 929 * remove all signatures that will be broken 931 In addition the intermediary MAY: 933 * Verify the message signature prior to modification 935 * Incorporate an Authentication-Results header to report the 936 verification result. 938 * Sign the modified message including the Authentication-Results 939 header 941 7.2. Filtering 943 Developers of filtering schemes designed to accept DKIM 944 authentication results as input should be aware that their 945 implementations will be subject to counter-attack by email abusers. 946 The efficacy of a filtering scheme cannot therefore be determined by 947 reference to static test vectors alone; resistance to counter attack 948 must also be considered. 950 Naive learning algorithms that only consider the presence or absence 951 of a valid DKIM signature are vulnerable to an attack in which a 952 spammer or other malefactor signs all their mail, thus creating a 953 large negative value for presence of a DKIM signature in the hope of 954 discouraging widespread use. 956 If heuristic algorithms are employed, they should be trained on 957 feature sets that sufficiently reveal the internal structure of the 958 DKIM responses. In particular the algorithm should consider the 959 domains purporting to claim responsibility for the signature, rather 960 than the existence of a signature or not. 962 Unless a scheme can correlate the DKIM signature with accreditation 963 or reputation data, the presence of a DKIM signature SHOULD be 964 ignored. 966 7.3. DNS Server 968 TBD 970 7.4. Accreditation service 972 TBD 974 8. Deployment 976 This section describes the basic steps for introducing DKIM into an 977 organization's email service operation. The considerations are 978 divided between an organization's generating DKIM signatures 979 (Signing) and an organization's processing of messages that contain a 980 DKIM signature (Verifying). 982 8.1. Signing 984 Creating messages that have DKIM signatures requires modification of 985 only two portions of the email service: 987 o Addition of relevant DNS information. 989 o Addition of the signature by a trusted module within the 990 organization's email handling service. 992 The signing module uses the appropriate private key to create a 993 signature. The means by which the signing module obtains this key is 994 not specified by DKIM. Given that DKIM is intended for use during 995 email transit, rather than for long-term storage, it is expected that 996 keys will be changed regularly. Clearly this means that key 997 information should not be hard-coded into software. 999 8.1.1. DNS Records 1001 A receiver attempting to validate a DKIM signature must obtain the 1002 public key that is associated with the signature for that message. 1003 The DKIM-Signature header in the message will specify the basic 1004 domain name doing the signing and the selector to be used for the 1005 specific public key. Hence, the relevant 1006 ._domainkeys. DNS record needs to contain a 1007 DKIM-related RR that provides the public key information. 1009 The administrator of the zone containing the relevant domain name 1010 adds this information. DNS administrative software varies 1011 considerably in its abilities to add new types of DNS records. 1012 Initial DKIM DNS information is contained within TXT RRs. 1014 8.1.2. Signing Module 1016 The module doing signing can be placed anywhere within an 1017 organization's trusted Administrative Management Domain (ADMD). 1018 Common choices are expected to be department-level posting and 1019 delivering agents, as well as boundary MTAs to the open Internet. 1020 However, note that it is entirely acceptable to have signing and 1021 validation be done by MUAs. Hence the choice among the modules 1022 depends upon software development and administrative overhead 1023 tradeoffs. One perspective that helps resolve this choice is the 1024 difference between the flexibility of use by systems at, or close to, 1025 the MUA, versus the centralized control that is more easily obtained 1026 by implementing the mechanism "deeper" into the organization's email 1027 infrastructure, such as at its boundary MTA. 1029 8.1.3. Signing Policies and Practices 1031 Every organization (ADMD) will have its own policies and practices 1032 for deciding when to sign messages and with what domain name and key 1033 (selector). Examples include signing all mail, signing mail from 1034 particular email addresses, or signing mail from particular sub- 1035 domains. Given this variability, and the likelihood that signing 1036 practices will change over time, it will be useful to have these 1037 decisions represented in some sort of configuration information, 1038 rather than being more deeply coded into the signing software. 1040 8.2. Verifying 1042 Verification is performed within an ADMD that wishes to make 1043 assessments based upon the domain name used for a DKIM signature. 1044 Any component within the ADMD that handles messages, whether in 1045 transit or being delivered, can be appropriate to do the verifying. 1046 It must communicate the results of verification to another component 1047 within the ADMD that performs the desired assessments. Verification 1048 and assessment might occur within the same software mechanism, such 1049 as a Boundary MTA, or an MDA. Or they may be separated, such as 1050 having verification performed by the Boundary MTA and assessment 1051 performed by the MDA. 1053 As with the signing process, choice of service venues for 1054 verification and assessment -- such as filtering or presentation to 1055 the recipient user -- depend on trade-offs for flexibility, control, 1056 and operational ease. An added concern is that the linkage between 1057 verification and assessment entails essential trust: The assessment 1058 module must have a strong basis for believing that the verification 1059 information is correct. 1061 8.2.1. DNS Client 1063 The primary means of publishing DKIM key information, initially, is 1064 through DNS TXT records. Some DNS client software might have 1065 problems obtaining these records. As DNS client software improves 1066 this will not be a concern. 1068 8.2.2. Boundary Enforcement 1070 In order for an assessment module to trust the information it 1071 receives about verification, it is essential to eliminate 1072 verification information originating from outside the ADMD in which 1073 the assessment mechanism operates. As a matter of friendly practice, 1074 it is equally important to make sure that verification information 1075 generated within the ADMD not escape outside of it. 1077 In most environments, the easiest way to enforce this stripping of 1078 verification information is to place modules in the receiving and 1079 sending Boundary MTA(s). For incoming mail, check for known means of 1080 communicating verification information and remove it. The same 1081 applies for outgoing mail. 1083 8.3. Transition strategy 1085 Deployment of a new signature algorithm without a 'flag day' requires 1086 a transition strategy such that signers and verifiers can phase in 1087 support for the new algorithm independently and if necessary phase 1088 out support for the old algorithm independently. 1090 DKIM achieves these requirements through two features. First a 1091 signed message may contain multiple signatures created by the same 1092 signer. Secondly the security policy layer allows the signing 1093 algorithms in use to be advertised, thus preventing a downgrade 1094 attack. 1096 8.3.1. Signer transition strategy 1098 Let the old signing algorithm be A, the new signing algorithm be B. 1099 The sequence of events by which a Signer may introduce a new signing 1100 algorithm, without disruption of service to legacy verifiers, is as 1101 follows: 1103 1. Signer signs with algorithm A 1105 A. Signer advertises that it signs with algorithm A 1107 2. Signer signs messages twice, first with algorithm A and algorithm 1108 B 1110 A. The signer tests new signing configuration 1112 B. Signer advertises that it signs with algorithm A and 1113 algorithm B 1115 3. Signer determines that support for Algorithm A is no longer 1116 necessary 1118 4. Signer determines that support for algorithm A is to be withdrawn 1120 A. Signer removes advertisement for Algorithm A 1122 B. Signer waits for cached copies of earlier signature policy to 1123 expire 1125 C. Signer stops signing with Algorithm A 1127 8.3.2. Verifier transition strategy 1129 The actions of the verifier are independent of the signer's actions 1130 and do not need to be performed in a particular sequence. The 1131 verifier may make a decision to cease accepting algorithm A without 1132 first deploying support for algorithm B. Similarly a verifier may be 1133 upgraded to support algorithm B without requiring algorithm A to be 1134 withdrawn. The decisions of the verifier must make are therefore: 1136 o The verifier MAY change the degree of confidence associated with 1137 any signature at any time, including determining that a given 1138 signature algorithm provides a limited assurance of authenticity 1139 at a given key strength. 1141 * A verifier MAY evaluate signature records in any order it 1142 chooses, including making use of the signature algorithm for 1143 choosing the order. 1145 o The verifier MAY make a determination that Algorithm A does not 1146 offer a useful level of security, or that the cost of verifying 1147 the signature is less than the value of doing so. 1149 * In this case the verifier ignores signatures created using the 1150 algorithm A and references to algorithm A in policy records are 1151 treated as if the algorithm were not implemented. 1153 o The verifier MAY decide to add support for additional signature 1154 algorithms at any time. 1156 * The verifier MAY add support for algorithm B at any time. 1158 9. Operations 1160 This section describes the basic steps for the continued operation of 1161 email systems that use DKIM. This section discusses keeping DKIM 1162 going, as opposed to getting DKIM started. The primary 1163 considerations are: the upkeep of the selector files, and the 1164 security of the private keys. 1166 9.1. DNS Signature Record Deployment Considerations 1168 The key point to remember is that the DNS DKIM selectors WILL and 1169 SHOULD be changed over time. Some reasons for changing DKIM 1170 selectors are well understood; others are still theoretical. There 1171 are several schemes that may be used to determine the policies for 1172 changing DKIM selectors: 1174 o time based 1176 o associations with clusters of servers 1178 o the use of third party signers 1180 o security considerations 1182 9.1.1. Time Basis and Security Considerations 1184 The reason for changing the selector periodically is usually related 1185 to the security exposure of a system. When the potential exposure of 1186 the private keys associated with the DKIM selector have reached 1187 sufficient levels, the selector should be changed. (It is unclear 1188 currently what kinds of metrics can be used to aid in deciding when 1189 the exposure has reached sufficient levels to warrant changing the 1190 selector.) 1192 For example, 1194 o Selectors should be changed more frequently on systems that are 1195 widely exposed, than on systems that are less widely exposed. For 1196 example, a gateway system that has numerous externally-accessible 1197 services running on it, is more widely exposed than one that ONLY 1198 runs a mail server. 1200 o Selectors should be changed more frequently on operating systems 1201 that are under wide attack. 1203 o While the use of DKIM information is transient, keys with 1204 sufficient exposure do become stale and should be changed. 1206 o Whenever you make a substantial system change, such as bringing up 1207 a new server, or making a major operating system change, you 1208 should consider changing the selector. 1210 o Whenever there is either suspicion or evidence of the compromise 1211 of the system or the private keys, you should change the selector. 1213 9.1.2. Server Clusters 1215 TBD 1217 9.1.3. Deploying New Selectors 1219 A primary consideration in changing the selector is remembering to 1220 change it. It needs to be a standard part of the operational staff 1221 Methods and Procedures for your systems. If they are separate, both 1222 the mail team and the DNS team will be involved in deploying new 1223 selectors. 1225 When deploying a new selector, it needs to be phased in: 1227 1. generate the new public / private key pair and create a selector 1228 record with the public key in it 1230 2. add the new selector record to your DNS 1232 3. verify that the new selector record can be used to verify 1233 signatures 1235 4. turn on signing with the new private key 1237 5. optionally back up the old private key in a secure location 1239 6. remove the old private key from your servers 1241 7. after a period of time, remove the old selector from your DNS 1243 The time an unused selector should be kept in the DNS system is 1244 dependent on the reason it's being changed. If the private key has 1245 definitely been exposed, the corresponding selector should be removed 1246 immediately. Otherwise, longer periods are allowable. 1248 9.1.4. Subdomain Considerations 1250 TBD 1252 9.1.5. Third party Signature Delegations 1254 Allowing third parties to sign email from your domain opens your 1255 system security to include the security of the third party's systems. 1256 At a minimum, you should not allow the third parties to use the same 1257 selector and private key as your main mail system. It is recommended 1258 that each third party be given their own private key and selector. 1259 This limits the exposure for any given private key, and minimizes the 1260 impact if any given private key were exposed. 1262 9.2. Private Key Management 1264 The permissions of private key files must be carefully managed. If 1265 key management hardware support is available, it should be used. 1266 Auditing software should be used to periodically verify that the 1267 private key files remain secure. 1269 9.3. Mailing List Management 1271 [ Note: this section may be controversial. ] 1273 A mailing list often provides facilities to its administrator to 1274 manipulate parts of the mail messages that are flowing through. The 1275 desired goal is that messages flowing through the mailing list will 1276 be verifiable by the recipient, which means that either the mailing 1277 list (or its MSA) must sign the message, or the mailing list must not 1278 perform actions on the messages that will break existing DKIM 1279 signatures. To avoid breaking existing signatures, a mailing list 1280 system has these choices: 1282 o A mailing list may add its own DKIM signature. If it does this, 1283 it must make sure that it adds its signature after it performs any 1284 content transformations to the message, such as adding a footer to 1285 the body, adding a prefix to the body, modifying the subject 1286 header, etc. 1288 o If a mailing list does not add its own DKIM signature, it must not 1289 modify any existing headers that are listed in an h= parameter of 1290 any existing DKIM-Signature headers, nor may it add any footer 1291 content to the body if there is no l= in any existing DKIM- 1292 Signature headers. 1294 o If a mailing list cannot add its own DKIM signature, and must 1295 modify the headers or body in a way that will break verification 1296 of existing DKIM-Signature headers, it should remove any existing 1297 DKIM-Signature headers. 1299 10. Outline Future Extensions 1301 The design of DKIM is unapologetically focused on overcoming the need 1302 for immediate deployment and achieving ubiquitous use in the near 1303 future. As such, the original design discussions generally tok the 1304 approach of 'if in doubt, leave it out'. 1306 But the need to exclude consideration of these features in the near 1307 term was in no way intended to preclude their development at a later 1308 date. Nor is the lack of a specification describing the use of DKIM 1309 with a different PKI infrastructure intended to indicate an intention 1310 to develop similar capabilities within the DKIM framework at a future 1311 date. 1313 DKIM is an example of 'Design for Deployment', and the need to 1314 support rapid deployment has been the overriding priority. It has 1315 traditionally been asserted that deployment of a flawed cryptographic 1316 protocol is an almost unacceptable risk, and that bad security is 1317 worse than no security; experience demonstrates otherwise. Informing 1318 users that email is insecure does not cause them to modify their 1319 behavior to avoid dependence thereupon. Deployment of flawed 1320 cryptographic security systems such as SSL and WEP has been rectified 1321 far more quickly than deployment of protocols such as IPSEC or DNSSEC 1322 where caution has prevailed. 1324 One possible future for DKIM is that it becomes the starting point 1325 for a new cryptographic infrastructure that eventually replaces 1326 legacy systems including S/MIME and PGP. While this future is 1327 certainly preferable to never achieving ubiquitous deployment of 1328 strong cryptographic security in the Internet, it would certainly 1329 take a long time to re-invent this particular wheel. Moreover the 1330 deployment of the proposed DKIM enhancements would face political 1331 opposition from the adherents to existing formats to be rendered 1332 historical. A likely outcome of such a strategy is that the existing 1333 two way standards stalemate between S/MIME and PGP would become a 1334 three way stalemate. 1336 Alternatively, another possible future is that DKIM provides the 1337 'bootstrap' that enables ubiquitous use of the legacy infrastructure, 1338 including the deployed base of PGP and S/MIME capable email clients 1339 and the existing business infrastructure of commercial Certificate 1340 Authorities. Such a strategy would make use of DKIM in conjunction 1341 with existing PKI standards such as PKIX and XKMS and leverage 1342 features of PGP and S/MIME where appropriate. 1344 10.1. Introducing a new signing algorithm 1346 Regardless of whether extension of the DKIM feature set is desirable, 1347 the need to replace the signature algorithm is practically a 1348 certainty. The RSA signature algorithm at best provides equivalent 1349 security to an 80 bit symmetric cipher when used with a 1024 bit key 1350 [cite]. Extending the key size to 2048 bits improves the cipher 1351 strength to only 112 bit equivalence. Achieving 128 bit security 1352 requires a minimum of 3072 bits. Achieving equivalent cipher 1353 strength to a 192 bit symmetric algorithm requires a prohibitive key 1354 size. 1356 The choice of cryptographic algorithm affects the DKIM algorithm in 1357 two important ways: First there is the difficulty of storing keys in 1358 the DNS. Secondly there is the problem of handling larger 1359 signatures. 1361 The default DNS response packet limit of 512 bytes places an 1362 effective upper bound of 4096 bits on a DKIM key. In practice the 1363 need for packaging, meta-data and the desirability of using DNSSEC to 1364 sign the record reduces the upper bound to no more than 2048 bits. 1366 The size of the DKIM signature itself is a weaker constraint. Even 1367 so, while 1024 and even 2048 bit signatures are likely to be 1368 acceptable in most implementations larger signature sizes may become 1369 prohibitive, particularly since the signature must be Base 64 1370 encoded. 1372 10.2. Possible future signature algorithm choices 1374 ECC cryptography offers a means of implementing public key 1375 cryptography using a key size and signature size that are each only 1376 twice the size of the equivalent symmetric key algorithm. 1378 While ECC offers clear technical advantages over algorithms based on 1379 the difficulty on solving the discrete log problem in a finite field, 1380 it is not possible at this point to be confident that a means of 1381 applying ECC has been found that is consistent with the position on 1382 intellectual property adopted by the DKIM working group. 1384 The DSA signature algorithm based on the discrete log problem faces 1385 the same key size limitations as RSA. Importantly for the design of 1386 DKIM and DNSSEC however, the signature size is much smaller, the same 1387 size as for ECC algorithms. 1389 It is likely that DSA would have received greater attention during 1390 the design of DSA if key sizes greater than 512 bits and use of hash 1391 functions stronger than SHA-1 had been supported at the time. In 1392 March 2006 a proposed revision of the DSA signature algorithm 1393 answered these objections permitting larger key sizes and specifying 1394 the use of stronger hash functions (including SHA-256 and SHA 512). 1395 While the advantages offered by DSA are not sufficient to warrant an 1396 immediate transition to the new algorithm at this late stage, it is 1397 highly probably that the algorithm will be employed by DNSSEC when 1398 finally deployed. 1400 10.3. Linkage to Other PKIs 1402 The principle limitations in DKIM are the lack of support for end- 1403 user keying, the lack of support for long term verification of 1404 signatures, and the lack of support for trusted third party issued 1405 assertions. Each of these limitations is determined by the key 1406 distribution mechanism rather than the signature format. 1408 Although the DNS infrastructure could in principle be extended to 1409 support these features, this approach would require substantial 1410 modifications that entirely negate the advantage of employing an 1411 existing infrastructure. The point of using DNS is to reuse the DNS 1412 infrastructure, not necessarily the DNS protocol. 1414 The preferred approach to addressing these limitations is to support 1415 use of a PKI infrastructure designed to support these requirements 1416 such as PKIX, PGP or XKMS. 1418 10.4. Trusted Third Party Assertions 1420 A DKIM signature tells the signature verifier that the owner of a 1421 particular domain name accepts responsibility for the message. 1422 Combining this information with information that allows the behavior 1423 of the domain name owner to be predicted may allow the probability 1424 that the message is abusive to be determined without the need for 1425 heuristic content analysis. 1427 Recipients of large volumes of email can generate reputation data for 1428 email senders internally. Recipients of smaller volumes of messages 1429 are likely to need to acquire reputation data from a third party. In 1430 either case the use of reputation data is intrinsically limited to 1431 email senders that have established a prior history of sending 1432 messages. 1434 Another commonly used technique for evaluating email senders is 1435 accreditation. Most spam sent today is sent by criminals to further 1436 a scheme that is unambiguously illegal. Spam demonstrates an 1437 Internet equivalent of Gresham's law: the bad spam drives out the 1438 merely irritating, the outright criminal drives out the bad. A 1439 message is highly unlikely to be spam if: the email sender can 1440 demonstrate that it is a legitimate business, and that it has 1441 provided a legitimate address where legal process can be served. In 1442 addition the accredited email sender may accept a legally binding 1443 undertaking not to send spam and possibly post a performance bond 1444 that is subject to forfeiture in case of default. 1446 As with reputation data, a high volume email recipient may be in a 1447 position to establish bilateral agreements with high volume senders. 1448 Smaller recipients are not in a position to require accreditation, 1449 nor is it practical for each large sender to accredit every sender. 1450 Trusted Third Party accreditation services allow an email sender to 1451 obtain an accreditation that is recognized by every email recipient 1452 that recognizes the Trusted Third Party. 1454 [Need use of both systems] 1456 [Need means of advertising existence of positive reputation data] 1458 10.5. Linkage to X.509 Certificates 1460 The industry standard for distribution of Trusted Third Party data 1461 tied to a public key is the X.509v3/PKIX standard. X.509 based PKI 1462 is designed to support requirements such as long term archiving of 1463 signatures, end entity signing and Trusted Third Party assertions. 1464 Combining the DKIM signature format with the PKIX PKI infrastructure 1465 provides an equivalent set of capabilities to S/MIME. 1467 Two approaches may be used to inform signature verifiers that an 1468 X.509 certificate has been issued that makes an assertion about the 1469 signing key for a DKIM signature: 1471 1. By means of an attribute in the key record 1473 2. By means of a signature header q= parameter 1475 Typical commercially issued digital certificates are considerably 1476 larger (1-2 kb) than the 512 byte message size that DNS servers are 1477 required to support as a minimum. Practical large scale PKI 1478 deployment requires support for certificate chains in addition to the 1479 end entity certificate. Publication of a URL for the certificate or 1480 certificate chain is therefore a more appropriate approach than 1481 storing the certificate data itself in the DNS. 1483 The ability to support multiple key distribution mechanisms for the 1484 same key is highly desirable. For example a signer may support DNS 1485 based key distribution (for the convenience and efficiency of 1486 transport based DKIM signature verifiers) as well as an X.509 1487 certificate. 1489 In other cases a signer may intentionally discourage transport 1490 verification by only providing an X.509 certificate. 1492 An X.509 application of particular interest is the use of DKIM as a 1493 signature format for Secure Internet Letterhead (Letterhead). 1494 Letterhead employs X.509 certificates containing a LOGOTYPE attribute 1495 extension [LOGOTYPE] to identify the certificate subject and/or 1496 issuer to the user by means of a brand image such as a corporate 1497 logo. [PHB-NIST] 1499 10.6. XKMS 1501 XKMS is a key centric PKI that supports registration and location of 1502 keys. XKMS is layered as a Web service and the existence of XKMS 1503 service for a domain is typically advertised by means of a DNS SRV 1504 record. 1506 XKISS, the key location component of XKMS provides a superset of the 1507 capabilities of the DKIM DNS key distribution mechanism. As XKMS is 1508 layered on SOAP over HTTP over TCP/IP the overhead incurred in 1509 retrieving keys through XKMS is substantially higher than the single 1510 UDP request/response of DNS key distribution. 1512 Like X.509 XKMS is designed to key management over time periods of 1513 years and decades rather than days and supports the use of trusted 1514 third parties. XKMS is designed to allow complexity to be 1515 concentrated at the Web service as opposed to the client. A client 1516 interacts with an XKMS service using request of the form 'provide a 1517 key to verify signatures on messages sent by A using protocol B'. 1519 XKMS may also be used as a gateway to one or more PKIs including an 1520 X.509 based PKI that makes use of sophisticated features such as 1521 cross certification. The verifier may at its option rely on the XKMS 1522 service to provide a trusted key or request the complete certificate 1523 path allowing offline verification. 1525 A signer may notify signature verifiers that a key may be retrieved 1526 using XKMS by means of the q= attribute. The verifier may then 1527 discover the corresponding XKMS service using the SRV mechanism as 1528 set out in the XKMS specification. 1530 10.7. Verification in the Client 1532 The DKIM specification is designed to support edge to edge 1533 authentication. The specification neither supports nor prohibits 1534 verification of DKIM signatures in the client. In particular the 1535 specification does not attempt to define client semantics for 1536 signatures or provide an exhaustive list of user interface security 1537 considerations. 1539 For client based verification to be practical, it is likely that a 1540 client needs to be capable of determining that it is able to receive 1541 messages that do not get clobbered before coming to any conclusions 1542 with respect to unsigned messages. 1544 DKIM requires that all verifiers treat messages with signatures that 1545 do not verify as if they are unsigned. If verification in the client 1546 is to be acceptable to users, it is also essential that successful 1547 verification of a signature not result in a less than satisfactory 1548 user experience compared to leaving the message unsigned. 1550 10.8. Per user signature 1552 Although DKIM is designed to support domain level signatures, the 1553 DKIM core design neither supports nor prohibits use of per user 1554 signatures. A DKIM key record can specify restrictions on the email 1555 addresses it can be used to sign for. These restrictions are not 1556 intended to be exhaustive nor are detailed semantics or security 1557 considerations set out for interpreting per user signatures. The 1558 primary use that this feature is intended to support, is to allow a 1559 company to delegate the signing authority for bulk marketing 1560 communications without the risk of effectively delegating the 1561 authority to sign contracts on behalf of the CEO. 1563 For per user signing keys to provide value beyond this limited use 1564 scenario, it is likely that additional requirements will be 1565 necessary, such as the ability to perform long term validation of the 1566 key. Linkage to some form of PKI is likely to be necessary. 1568 In addition any scheme that involves maintenance of a significant 1569 number of public keys will require infrastructure to support that 1570 management. A system in which the end user is required to generate a 1571 public key pair and transmit it to the DNS administrator out of band 1572 is not likely to meet acceptance criteria for either usability or 1573 security. At a minimum, a key registration protocol must be defined. 1575 10.9. Encryption 1577 DKIM is not designed to support encryption. A strong case can be 1578 made for applying the DKIM style of transparent security, key centric 1579 key management and domain level keying. It is not clear that re- 1580 using the DKIM signature architecture is the best way to achieve this 1581 goal. 1583 The DKIM signature format in particular is designed to allow meta- 1584 data to be attached to a message without modifying the content. 1585 Content encryption by its very nature requires modification of the 1586 message content. The message encryption formats of PGP and S/MIME 1587 both solve the problem of message encryption perfectly adequately; 1588 there is no reason to believe that a new effort in this space would 1589 improve matters. 1591 An architecture of this form would require development of an email 1592 receiver security policy that allows a recipient to state that 1593 encrypted email messages are acceptable and to specify the key 1594 distribution infrastructure(s) by which the necessary encryption keys 1595 may be discovered. 1597 A policy infrastructure of this type is implicit in the XKMS 1598 standard. One drawback to this approach is that policy distribution 1599 and key distribution are conflated, an approach that is satisfactory 1600 for message level encryption schemes such as PGP and S/MIME, but less 1601 satisfactory for transport layer encryption such as SSL. 1603 10.10. Reuse of Key Record 1605 A number of proposals have been made that attempt to reuse the DKIM 1606 key record. Architects considering this approach should be aware of 1607 the advantages and limitations. 1609 As a minimum each of the security considerations listed in the DKIM 1610 specification should be considered and its possible relevance to the 1611 proposed field of use carefully evaluated. Application of a security 1612 mechanism outside the context in which it was originally designed for 1613 is a principle cause of security failures. 1615 DKIM is designed to meet the security needs of an application where 1616 the cost of individual failures is insignificant or small. A single 1617 spam in an email inbox is not a disaster, indeed it is no longer even 1618 an irritation. For the long time spam sufferer who has seen their 1619 inbox filled with hundreds or even thousands of spams, an occasional 1620 failure may even be cause for satisfaction as a reminder of a 1621 successfully vanquished foe. 1623 One of the chief limitations of using DNS based key records is that 1624 maintenance of DNS records is typically a network operations concern. 1625 If the entity to which the public key corresponds is a network object 1626 (e.g. a mail server), the use of DNS based key management is likely 1627 to be satisfactory. If the entity is not a network related object 1628 (e.g. an end user) a significant degree of pushback from network 1629 administrators should be anticipated. 1631 The design of DKIM is designed for rapid deployment in response to an 1632 immediate need. As such many of the design decisions are not the 1633 decisions that would be taken if the choice were unconstrained by the 1634 limitations of the current legacy DNS. In particular the use of Base 1635 64 encoded public keys distributed through TXT records is not ideal. 1637 Applications that do not face the same constraints as DKIM should 1638 carefully evaluate the feasibility of using the binary key record. 1639 In particular an application predicated on the use of DNSSEC to 1640 authenticate keys should assume support for DKIM binary key records. 1642 10.11. Use of Policy Record 1644 DKIM demonstrates the power of using the DNS to distribute security 1645 policy information. It is not possible to achieve robust security 1646 unless the parties to a conversation know the security capabilities 1647 and expectations of the other. 1649 Any party proposing re-use of the DKIM policy record should carefully 1650 consider whether their needs would be better met by proposing a 1651 flexible security policy architecture in the DKIM style rather than 1652 proposing ad-hoc extensions and variations. 1654 At a minimum any proposal for new security policy formats that make 1655 use of the TXT record should employ a new policy prefix and ensure 1656 that mislabeled and wild-carded policy records are not accidentally 1657 misinterpreted. 1659 11. Acknowledgements 1661 TBD 1663 12. { Misc Text -- Should go elsewhere, if used at all } 1665 DKIM permits the signing identity to be different from the identities 1666 used for the author or the initial posting agent. This is essential, 1667 for example, to enable support of signing by authorized third- 1668 parties, and to permit signatures by email providers who are 1669 otherwise independent of the domain name of the message author. 1671 DKIM permits restricting the use of a signature key to particular 1672 types of services, such as only for email. This is helpful when 1673 delegating signing authority, such as to a particular department or 1674 to a third-party outsourcing service. 1676 With DKIM the signer MUST explicitly list the headers that are 1677 signed. This is an improvement because it requires the signer to use 1678 the more conservative (likely to verify correctly) mechanism and 1679 makes it considerably more robust against the handling of 1680 intermediary MTAs. 1682 DKIM self-signs the DKIM-Signature header field, to protect against 1683 its being modified. 1685 In order to survive the vagaries of different email transfer systems, 1686 mechanisms like DKIM must evaluate the message data in some canonical 1687 form, such as treating a string of spaces as tabs as if they were a 1688 single space. DKIM has added the "relaxed" canonicalization in place 1689 of "nofws". 1691 MUA UI considerations 1693 key delegation/ 3rd party 1695 13. References 1696 13.1. References -- Normative 1698 [I-D.ietf-dkim-base] 1699 Allman, E., "DomainKeys Identified Mail (DKIM) 1700 Signatures", draft-ietf-dkim-base-06 (work in progress), 1701 October 2006. 1703 [I-D.ietf-dkim-threats] 1704 Fenton, J., "Analysis of Threats Motivating DomainKeys 1705 Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work 1706 in progress), May 2006. 1708 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1709 April 2001. 1711 13.2. Informative References 1713 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 1714 for Internet electronic mail: Part I: Message encipherment 1715 and authentication procedures", RFC 989, February 1987. 1717 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 1718 Object Security Services", RFC 1848, October 1995. 1720 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1721 Exchange Formats", RFC 1991, August 1996. 1723 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1724 April 2001. 1726 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1727 "MIME Security with OpenPGP", RFC 3156, August 2001. 1729 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1730 Extensions (S/MIME) Version 3.1 Message Specification", 1731 RFC 3851, July 2004. 1733 Authors' Addresses 1735 Tony Hansen 1736 AT&T Laboratories 1737 200 Laurel Ave. 1738 Middletown, NJ 07748 1739 USA 1741 Email: tony+dkimov@maillennium.att.com 1742 Dave Crocker 1743 Brandenburg InternetWorking 1744 675 Spruce Dr. 1745 Sunnyvale, CA 94086 1746 USA 1748 Email: dcrocker@bbiw.net 1750 Phillip Hallam-Baker 1751 VeriSign Inc. 1753 Email: pbaker@verisign.com 1755 Full Copyright Statement 1757 Copyright (C) The Internet Society (2006). 1759 This document is subject to the rights, licenses and restrictions 1760 contained in BCP 78, and except as set forth therein, the authors 1761 retain all their rights. 1763 This document and the information contained herein are provided on an 1764 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1765 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1766 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1767 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1768 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1769 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1771 Intellectual Property 1773 The IETF takes no position regarding the validity or scope of any 1774 Intellectual Property Rights or other rights that might be claimed to 1775 pertain to the implementation or use of the technology described in 1776 this document or the extent to which any license under such rights 1777 might or might not be available; nor does it represent that it has 1778 made any independent effort to identify any such rights. Information 1779 on the procedures with respect to rights in RFC documents can be 1780 found in BCP 78 and BCP 79. 1782 Copies of IPR disclosures made to the IETF Secretariat and any 1783 assurances of licenses to be made available, or the result of an 1784 attempt made to obtain a general license or permission for the use of 1785 such proprietary rights by implementers or users of this 1786 specification can be obtained from the IETF on-line IPR repository at 1787 http://www.ietf.org/ipr. 1789 The IETF invites any interested party to bring to its attention any 1790 copyrights, patents or patent applications, or other proprietary 1791 rights that may cover technology that may be required to implement 1792 this standard. Please address the information to the IETF at 1793 ietf-ipr@ietf.org. 1795 Acknowledgment 1797 Funding for the RFC Editor function is provided by the IETF 1798 Administrative Support Activity (IASA).