idnits 2.17.1 draft-fenton-dkim-threats-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 26, 2005) is 6780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-allman-dkim-base-00 == Outdated reference: A later version (-02) exists of draft-allman-dkim-ssp-00 == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-04 == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-workgroup J. Fenton 3 Internet-Draft Cisco Systems, Inc. 4 Expires: March 30, 2006 September 26, 2005 6 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) 7 draft-fenton-dkim-threats-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 30, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document provides an analysis of some threats against Internet 41 mail that are intended to be addressed by signature-based mail 42 authentication, in particular DomainKeys Identified Mail. It 43 discusses the nature and location of the bad actors, what their 44 capabilities are, and what they intend to accomplish via their 45 attacks. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The Bad Actors . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Capabilities of the Bad Actors . . . . . . . . . . . . . . . . 4 52 3.1. General capabilities . . . . . . . . . . . . . . . . . . . 4 53 3.2. Advanced capabilities . . . . . . . . . . . . . . . . . . 4 54 4. Location of the Bad Actors . . . . . . . . . . . . . . . . . . 5 55 4.1. Externally-located Bad Actors . . . . . . . . . . . . . . 5 56 4.2. Within Claimed Originator's Administrative Unit . . . . . 6 57 4.3. Within Recipient's Administrative Unit . . . . . . . . . . 6 58 5. Representative Bad Acts . . . . . . . . . . . . . . . . . . . 6 59 5.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 6 60 5.2. Use of Specific Identities . . . . . . . . . . . . . . . . 7 61 5.2.1. Exploitation of Social Relationships . . . . . . . . . 7 62 5.2.2. Identity-Related Fraud . . . . . . . . . . . . . . . . 7 63 5.2.3. Reputation Attacks . . . . . . . . . . . . . . . . . . 8 64 6. Attacks on Message Signing . . . . . . . . . . . . . . . . . . 8 65 6.1. Unsigned Messages . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Use of throw-away addresses . . . . . . . . . . . . . . . 9 67 6.3. Message replay . . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 71 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 11 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Introduction 78 Message signing, as exemplified by DomainKeys Identified Mail (DKIM) 79 [I-D.allman-dkim-base], is a mechanism to allow an email sender or 80 intermediary to assert responsibility for an email message in transit 81 by means of a digital signature. 83 Once the responsible party or parties have been established, the 84 recipient may evaluate the message in the context of additional 85 information such as locally-maintained whitelists, shared reputation 86 services, and/or third-party accreditation. The description of these 87 mechanisms is outside the scope of this effort. By applying a 88 signature, a good player will be able to associate a positive 89 reputation with the message, in hopes that it will receive 90 preferential treatment by the recipient. 92 This effort is not intended to address threats associated with 93 message confidentiality nor does it intend to provide a long-term 94 archival signature. 96 2. The Bad Actors 98 The problem space being addressed by DKIM is characterized by a wide 99 range of attackers in terms of motivation, sophistication, and 100 capabilities. 102 At the low end of the spectrum are bad actors who may simply send 103 email, perhaps using one of many commercially available tools, which 104 the recipient does not want to receive. These tools may or may not 105 falsify the origin address of messages, and may, in the future, be 106 capable of generating message signatures as well. 108 At the next tier are what would be considered "professional" senders 109 of unwanted email. These attackers would deploy specific 110 infrastructure, including Mail Transfer Agents (MTAs), registered 111 domains and possibly "zombie" networks to send messages, and in some 112 cases to harvest addresses to which to send. These senders often 113 operate as commercial enterprises and send messages on behalf of 114 third parties. 116 The most sophisticated and financially-motivated senders of messages 117 are those who stand to receive substantial financial benefit, such as 118 from an email-based fraud scheme. These attackers can be expected to 119 employ all of the above mechanisms and in addition attacks on 120 Internet infrastructure itself, such as DNS cache-poisoning attacks 121 and IP routing attacks via compromised network routing elements. 123 3. Capabilities of the Bad Actors 125 3.1. General capabilities 127 In general, the bad actors described above should be expected to have 128 access to the following: 130 1. An extensive corpus of messages from domains they might wish to 131 impersonate 133 2. Knowledge of the business aims and model for domains they might 134 wish to impersonate 136 3. Access to public key and associated authorization records 137 published by the domain 139 and the ability to do at least some of the following: 141 1. Submit messages to MTAs at multiple locations in the Internet 143 2. Construct arbitrary message headers, including those claiming to 144 be mailing lists, resenders, and other mail agents 146 3. Sign messages on behalf of potentially-untraceable domains under 147 their control 149 4. Generate substantial numbers of either unsigned or apparently- 150 signed messages which might be used to attempt a denial of 151 service attack 153 5. Resend messages which may have been previously signed by the 154 domain 156 6. Transmit messages using any envelope information desired 158 3.2. Advanced capabilities 160 As noted above, certain classes of bad actors may have substantial 161 financial motivation for their activities, and therefore should be 162 expected to have more capabilities at their disposal. These include: 164 1. Manipulation of IP routing. This could be used to submit 165 messages from specific IP addresses or difficult-to-trace 166 addresses, or to cause diversion of messages to a specific 167 domain. 169 2. Limited influence over portions of DNS using mechanisms such as 170 cache poisoning. This might be used to influence message 171 routing, or to cause falsification of DNS-based key or policy 172 advertisements. 174 3. Access to significant computing resources, perhaps through the 175 conscription of worm-infected "zombie" computers. This could 176 allow the bad actor to perform various types of brute-force 177 attacks. 179 4. Ability to "wiretap" some existing traffic, perhaps from a 180 wireless network. 182 Either of the first two of these mechanisms could be used to allow 183 the bad actor to function as a man-in-the-middle between sender and 184 recipient, if that attack is useful. 186 4. Location of the Bad Actors 188 In the following discussion, the term "administrative unit", taken 189 from [I-D.crocker-email-arch], is used to refer to a portion of the 190 email path that is under common administration. The originator and 191 recipient typically develop trust relationships with the 192 administrative units that send and receive their email, respectively, 193 to perform the signing and verification of their messages. 195 Bad actors or their proxies can be located anywhere in the Internet. 196 Bad actors within the administrative unit of the claimed originator 197 and/or recipient domain have capabilities beyond those elsewhere, as 198 described in the below sections. 200 4.1. Externally-located Bad Actors 202 DKIM focuses primarily on bad actors located external to the 203 administrative units of the claimed originator and the recipient. It 204 is in this area that the trust relationships required for 205 authenticated message submission do not exist and do not scale 206 adequately to be practical. 208 External bad actors are usually attempting to exploit the "any to 209 any" nature of email which motivates most recipient MTAs to accept 210 messages from anywhere for delivery to their local domain. They may 211 generate messages without signatures, with incorrect signatures, or 212 with correct signatures from domains with little traceability. They 213 may also pose as mailing lists, greeting cards, or other agents which 214 legitimately send or re-send messages on behalf of others. 216 4.2. Within Claimed Originator's Administrative Unit 218 Bad actors in the form of rogue or unauthorized users or malware- 219 infected computers can exist within the administrative unit 220 corresponding to a message's origin address. Since the submission of 221 messages in this area generally occurs prior to the application of a 222 message signature, DKIM is not directly effective against these bad 223 actors. Defense against these bad actors is dependent upon other 224 means, such as proper use of firewalls, and mail submission agents 225 that are configured to authenticate the sender. 227 In the special case where the administrative unit is non-contiguous 228 (e.g., a company that communicates between branches over the external 229 Internet), DKIM signatures can be used to distinguish between 230 legitimate externally-originated messages and attempts to spoof 231 addresses in the local domain. 233 4.3. Within Recipient's Administrative Unit 235 Bad actors may also exist with the administrative unit of the message 236 recipient. These bad actors may attempt to exploit the trust 237 relationships which happen within the unit. Since messages will 238 typically have undergone DKIM verification at the administrative unit 239 boundary, DKIM is not effective against messages submitted in this 240 area. 242 For example, the bad actor may attempt to apply a header such as 243 Authentication-Results [I-D.kucherawy-sender-auth-header] which would 244 normally be added (and spoofing of which would be detected) at the 245 boundary of the administrative unit. This could be used to falsely 246 indicate that the message was authenticated successfully. 248 As in the originator case, these bad actors are best dealt with by 249 controlling the submission of messages within the administrative unit 250 using a mechanism like SMTP AUTH. 252 5. Representative Bad Acts 254 One of the most fundamental bad acts being attempted is the delivery 255 of messages which are not authorized by the alleged originating 256 domain. As described above, these messages might merely be unwanted 257 by the recipient, or might be part of a confidence scheme or a 258 delivery vector for malware. 260 5.1. Use of Arbitrary Identities 262 This class of bad acts includes the sending of messages which aim to 263 obscure the identity of the actual sender. In some cases the actual 264 sender might be the bad actor, or in other cases might be a third- 265 party under the control of the bad actor (e.g., a compromised 266 computer). 268 DKIM is effective in mitigating against the use of addresses not 269 controlled by bad actors, but is not effective against the use of 270 addresses they control. In other words, the presence of a valid DKIM 271 signature does not guarantee that the signer is not a bad actor. It 272 also does not guarantee the accountability of the signer, since that 273 is limited by the extent to which domain registration requires 274 accountability for its registrants. However, accreditation and 275 reputation systems can be used to enhance the accountability of DKIM- 276 verified addresses and/or the likelihood that signed messages are 277 desirable. 279 5.2. Use of Specific Identities 281 A second major class of bad acts involves the assertion of specific 282 identities in email. 284 5.2.1. Exploitation of Social Relationships 286 One reason for asserting a specific origin address is to encourage a 287 recipient to read and act on particular email messages by appearing 288 to be an acquaintance or previous correspondent that the recipient 289 might trust. This tactic has been used by email-propagated worms 290 which mail themselves to addresses in the infected host's address 291 book. In this case, however, the sender's address may not be 292 falsified, so DKIM would not be effective in defending against this 293 act. 295 It is also possible for address books to be harvested and used by an 296 attacker to send messages from elsewhere. DKIM would be effective in 297 mitigating these acts. 299 5.2.2. Identity-Related Fraud 301 Bad acts related to email-based fraud often, but not always, involve 302 the transmission of messages using specific origin addresses of other 303 entities as part of the fraud scheme. The use of a specific address 304 of origin sometimes contributes to the success of the fraud by 305 convincing the recipient that the message was actually sent by the 306 alleged sender. 308 To the extent that the success of the fraud depends on or is enhanced 309 by the use of a specific origin address, the bad actor may have 310 significant financial motivation and resources to circumvent any 311 measures taken to protect specific addresses from unauthorized use. 313 5.2.3. Reputation Attacks 315 Another motivation for using a specific origin address in a message 316 is to harm the reputation of another, commonly referred to as a "joe- 317 job". For example, a commercial entity might wish to harm the 318 reputation of a competitor, perhaps by sending unsolicited bulk email 319 on behalf of that competitor. It is for this reason that reputation 320 systems must be based on an identity that is, in practice, fairly 321 reliable. 323 Reputation attacks of this sort are sometimes based on the 324 retransmission (often referred to as a "replay") of a legitimately 325 sent message. DKIM provides little protection against such acts, 326 except that the key used to sign the original instance of the message 327 can be revoked. Other reputation attacks, involving the fabrication 328 and transmission of a fictitious message, are addressed by DKIM since 329 the bad actor would not, without inside assistance, be able to obtain 330 a valid signature for the fabricated message. 332 6. Attacks on Message Signing 334 Bad actors can be expected to exploit all of the limitations of 335 message authentication systems. They are also likely to be motivated 336 to degrade the usefulness of message authentication systems in order 337 to hinder their deployment. Some representatives of these categories 338 of bad acts are described below. Additional postulated attacks are 339 described in the Security Considerations section of [I-D.allman-dkim- 340 base]. 342 6.1. Unsigned Messages 344 Messages without signatures may be sent in an effort to exploit the 345 incremental deployment of message signatures. In many cases, a 346 recipient may not be able to make a determination about unsigned 347 messages from a domain, and therefore will need to accept the message 348 (although perhaps at a lower delivery priority). This situation is 349 mitigated by the use of the DKIM Sender Signing Policy (SSP) 350 [I-D.allman-dkim-ssp] that indicates whether or not a given domain 351 signs all of its messages. Nevertheless, the possibility of 352 signature breakage due to legitimate modification of the message may 353 limit the ability of SSP to dictate harsh treatment of messages 354 without valid signatures. 356 Messages with invalid signatures may also be introduced by bad 357 actors. The intent may be to make the message appear as though it 358 was legitimately sent, but "broken" in transit, i.e. that the message 359 was modified, rendering the signature invalid. At least until the 360 causes of signature breakage are well understood, messages with 361 invalid signatures need to be evaluated as if the invalid signature 362 isn't present at all. 364 6.2. Use of throw-away addresses 366 Bad actors may also introduce messages with valid signatures on 367 behalf of domains they control, perhaps "throw-away" domains 368 registered under false pretenses which are difficult to trace. In 369 other words, the existence of a message signature does not imply that 370 the message is "good". The use of such domains will undoubtedly give 371 rise to domain-based accreditation and reputation systems. Until 372 these are available, local reputation, mostly in the form of 373 whitelists, can be maintained by domains to improve the 374 deliverability of email from domains with which they have business or 375 other relationships. 377 Accreditation and reputation, or even local whitelists, require a 378 reliable identity on which to base their assertion, and in the case 379 of reputation on which to base any feedback reports. Message signing 380 provides an identity which is intended to be sufficiently reliable 381 for this purpose, and it (or some other reliable mechanism) is 382 necessary for accreditation and reputation systems to operate. 384 Modification of messages by mailing lists and other legitimate agents 385 requires that a mechanism be created for signing of messages by other 386 than the originating domain. This provides a bad actor with an 387 additional avenue through which it might attempt to circumvent 388 message authentication. A bad actor might attempt to pose as a 389 mailing list which modifies a message and adds its own signature 390 taking responsibility for the message. If this signature is from an 391 untraceable domain, little assertion of the legitimacy of the message 392 is provided by this signature. For this reason, accreditation, 393 reputation, and local reputation in the form of white lists is at 394 least as important for these signatures from third parties as they 395 are for origination address signatures. 397 6.3. Message replay 399 Message replay is a term used to describe the retransmission of 400 already-signed messages. Here the bad actor obtains an account with 401 a domain such as a consumer ISP, and sends an undesirable message to 402 an external address controlled by the bad actor or an accomplice. 403 That message, having now obtained a signature, is forwarded to other 404 recipients without the authorization of the signing domain. It is 405 closely related to one of the reputation attacks described above. 407 This bad act is basically indistinguishable from a number of 408 acceptable acts, such as the transparent forwarding of messages by a 409 recipient to multiple addresses. For this reason, DKIM is not 410 particularly effective at detecting and eliminating this bad act. 411 Prompt key revocation may mitigate this problem; however, since 412 verification typically occurs as messages are received by recipient 413 domains, time is of the essence. 415 Other means to mitigate this bad act include the use of content 416 filtering on messages being signed, and business models which enforce 417 more accountability for subscribers whose messages are to be signed 418 by DKIM. 420 7. IANA Considerations 422 This document defines no items requiring IANA assignment. 424 8. Security Considerations 426 This document describes the security threat environment in which 427 DomainKeys Identified Mail (DKIM) is expected to provide some 428 benefit. 430 9. Informative References 432 [I-D.allman-dkim-base] 433 Allman, E., "DomainKeys Identified Mail (DKIM)", 434 draft-allman-dkim-base-00 (work in progress), July 2005. 436 [I-D.allman-dkim-ssp] 437 Allman, E., "DKIM Sender Signing Policy", 438 draft-allman-dkim-ssp-00 (work in progress), July 2005. 440 [I-D.crocker-email-arch] 441 Crocker, D., "Internet Mail Architecture", 442 draft-crocker-email-arch-04 (work in progress), 443 March 2005. 445 [I-D.kucherawy-sender-auth-header] 446 Kucherawy, M., "Message Header for Indicating Sender 447 Authentication Status", 448 draft-kucherawy-sender-auth-header-02 (work in progress), 449 May 2005. 451 Appendix A. Glossary 453 Origin address - The address on an email message, typically the RFC 454 2822 From: address, which is associated with the alleged author of 455 the message and is displayed by the recipient's MUA as the source of 456 the message. 458 Appendix B. Acknowledgements 460 The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony 461 Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, and 462 Jon Callas for valuable suggestions and constructive criticism of 463 earlier versions of this draft. 465 Author's Address 467 Jim Fenton 468 Cisco Systems, Inc. 469 MS SJ-24/2 470 170 W. Tasman Drive 471 San Jose, CA 95134-1706 472 USA 474 Phone: +1 408 526 5914 475 Email: fenton@cisco.com 476 URI: 478 Intellectual Property Statement 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org. 502 Disclaimer of Validity 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 512 Copyright Statement 514 Copyright (C) The Internet Society (2005). This document is subject 515 to the rights, licenses and restrictions contained in BCP 78, and 516 except as set forth therein, the authors retain all their rights. 518 Acknowledgment 520 Funding for the RFC Editor function is currently provided by the 521 Internet Society.