idnits 2.17.1 draft-fenton-dkim-threats-02.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 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1001. ** 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (December 19, 2005) is 6703 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) == Missing Reference: 'Internet' is mentioned on line 135, but not defined == Missing Reference: 'Report' is mentioned on line 146, but not defined == Unused Reference: 'I-D.allman-dkim-ssp' is defined on line 900, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-allman-dkim-ssp-01 == 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 -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 8 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: June 22, 2006 December 19, 2005 6 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) 7 draft-fenton-dkim-threats-02 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 June 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Terminology and Model . . . . . . . . . . . . . . . . . . 4 51 2. The Bad Actors . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1. Characteristics . . . . . . . . . . . . . . . . . . . . . 5 53 2.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.3.1. Externally-located Bad Actors . . . . . . . . . . . . 7 56 2.3.2. Within Claimed Originator's Administrative Unit . . . 8 57 2.3.3. Within Recipient's Administrative Unit . . . . . . . . 8 58 3. Representative Bad Acts . . . . . . . . . . . . . . . . . . . 9 59 3.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 9 60 3.2. Use of Specific Identities . . . . . . . . . . . . . . . . 9 61 3.2.1. Exploitation of Social Relationships . . . . . . . . . 10 62 3.2.2. Identity-Related Fraud . . . . . . . . . . . . . . . . 10 63 3.2.3. Reputation Attacks . . . . . . . . . . . . . . . . . . 10 64 4. Attacks on Message Signing . . . . . . . . . . . . . . . . . . 11 65 4.1. Attacks Against Message Signatures . . . . . . . . . . . . 12 66 4.1.1. Theft of Private Key for Domain . . . . . . . . . . . 12 67 4.1.2. Theft of Delegated Private Key . . . . . . . . . . . . 13 68 4.1.3. Private Key Recovery via Timing Attack . . . . . . . . 13 69 4.1.4. Chosen Message Replay . . . . . . . . . . . . . . . . 13 70 4.1.5. Signed Message Replay . . . . . . . . . . . . . . . . 14 71 4.1.6. Denial-of-Service Attack Against Verifier . . . . . . 15 72 4.1.7. Denial-of-Service Attack Against Key Service . . . . . 15 73 4.1.8. Canonicalization Abuse . . . . . . . . . . . . . . . . 15 74 4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 16 75 4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 16 76 4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 17 77 4.1.12. Falsification of Key Service Replies . . . . . . . . . 17 78 4.1.13. Publication of Malformed Key Records and/or 79 Signatures . . . . . . . . . . . . . . . . . . . . . . 17 80 4.1.14. Cryptographic Weaknesses in Signature Generation . . . 18 81 4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 18 82 4.1.16. Compromised System Within Originator's Network . . . . 19 83 4.2. Attacks Against Message Signing Policy . . . . . . . . . . 19 84 4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 19 85 4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 19 86 4.2.3. Denial-of-Service Attack Against Signing Policy . . . 20 87 4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 20 88 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 20 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 8. Informative References . . . . . . . . . . . . . . . . . . . . 21 92 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 22 93 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 94 Appendix C. Edit History . . . . . . . . . . . . . . . . . . . . 22 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Intellectual Property and Copyright Statements . . . . . . . . . . 25 98 1. Introduction 100 DomainKeys Identified Mail (DKIM) [I-D.allman-dkim-base] defines a 101 simple, low cost, and effective mechanism by which email messages can 102 be cryptographically signed, permitting a signing domain to claim 103 responsibility for the use of a given email address. Message 104 recipients can verify the signature by querying the signer's domain 105 directly to retrieve the appropriate public key, and thereby confirm 106 that the message was attested to by a party in possession of the 107 private key for the signing domain. 109 Once the attesting party or parties have been established, the 110 recipient may evaluate the message in the context of additional 111 information such as locally-maintained whitelists, shared reputation 112 services, and/or third-party accreditation. The description of these 113 mechanisms is outside the scope of this effort. By applying a 114 signature, a good player will be able to associate a positive 115 reputation with the message, in hopes that it will receive 116 preferential treatment by the recipient. 118 This effort is not intended to address threats associated with 119 message confidentiality nor does it intend to provide a long-term 120 archival signature. 122 1.1. Terminology and Model 124 The following diagram illustrates a typical usage flowchart for DKIM: 126 +---------------------------------+ 127 | SIGNATURE CREATION | 128 | (Originating or Relaying ADMD) | 129 | | 130 | Sign (Message, Domain, Key) | 131 | | 132 +---------------------------------+ 133 | - Message (Domain, Key) 134 | 135 [Internet] 136 | 137 V 138 +---------------------------------+ 139 +-----------+ | SIGNATURE VERIFICATION | 140 | | | (Relaying or Delivering ADMD) | 141 | KEY | | | 142 | QUERY +...>| Verify (Message, Domain, Key) | 143 | | | | 144 +-----------+ +----------------+----------------+ 145 | - Verified Domain 146 +-----------+ V - [Report] 147 | | +----------------+----------------+ 148 | SIGNER | | | 149 | PRACTICES +...>| SIGNER EVALUATION | 150 | QUERY | | | 151 | | +---------------------------------+ 152 +-----------+ 154 Definitions of some terms used in this document may be found in 155 Appendix A. 157 Placeholder for some discussion of 2821 vs. 2822 solutions, etc. 159 2. The Bad Actors 161 2.1. Characteristics 163 The problem space being addressed by DKIM is characterized by a wide 164 range of attackers in terms of motivation, sophistication, and 165 capabilities. 167 At the low end of the spectrum are bad actors who may simply send 168 email, perhaps using one of many commercially available tools, which 169 the recipient does not want to receive. These tools may or may not 170 falsify the origin address of messages, and may, in the future, be 171 capable of generating message signatures as well. 173 At the next tier are what would be considered "professional" senders 174 of unwanted email. These attackers would deploy specific 175 infrastructure, including Mail Transfer Agents (MTAs), registered 176 domains and possibly networks of compromised computers ("zombies") to 177 send messages, and in some cases to harvest addresses to which to 178 send. These senders often operate as commercial enterprises and send 179 messages on behalf of third parties. 181 The most sophisticated and financially-motivated senders of messages 182 are those who stand to receive substantial financial benefit, such as 183 from an email-based fraud scheme. These attackers can be expected to 184 employ all of the above mechanisms and additionally may attack the 185 Internet infrastructure itself, e.g., DNS cache-poisoning attacks; IP 186 routing attacks via compromised network routing elements. 188 2.2. Capabilities 190 In general, the bad actors described above should be expected to have 191 access to the following: 193 1. An extensive corpus of messages from domains they might wish to 194 impersonate 196 2. Knowledge of the business aims and model for domains they might 197 wish to impersonate 199 3. Access to public keys and associated authorization records 200 published by the domain 202 and the ability to do at least some of the following: 204 1. Submit messages to MTAs at multiple locations in the Internet 206 2. Construct arbitrary message headers, including those claiming to 207 be mailing lists, resenders, and other mail agents 209 3. Sign messages on behalf of potentially-untraceable domains under 210 their control 212 4. Generate substantial numbers of either unsigned or apparently- 213 signed messages which might be used to attempt a denial of 214 service attack 216 5. Resend messages which may have been previously signed by the 217 domain 219 6. Transmit messages using any envelope information desired 220 As noted above, certain classes of bad actors may have substantial 221 financial motivation for their activities, and therefore should be 222 expected to have more capabilities at their disposal. These include: 224 1. Manipulation of IP routing. This could be used to submit 225 messages from specific IP addresses or difficult-to-trace 226 addresses, or to cause diversion of messages to a specific 227 domain. 229 2. Limited influence over portions of DNS using mechanisms such as 230 cache poisoning. This might be used to influence message 231 routing, or to cause falsification of DNS-based key or policy 232 advertisements. 234 3. Access to significant computing resources, perhaps through the 235 conscription of worm-infected "zombie" computers. This could 236 allow the bad actor to perform various types of brute-force 237 attacks. 239 4. Ability to "wiretap" some existing traffic, perhaps from a 240 wireless network. 242 Either of the first two of these mechanisms could be used to allow 243 the bad actor to function as a man-in-the-middle between sender and 244 recipient, if that attack is useful. 246 2.3. Location 248 In the following discussion, the term "administrative unit", taken 249 from [I-D.crocker-email-arch], is used to refer to a portion of the 250 email path that is under common administration. The originator and 251 recipient typically develop trust relationships with the 252 administrative units that send and receive their email, respectively, 253 to perform the signing and verification of their messages. 255 Bad actors or their proxies can be located anywhere in the Internet. 256 Certain attacks are possible primarily within the administrative unit 257 of the claimed originator and/or recipient domain have capabilities 258 beyond those elsewhere, as described in the below sections. Bad 259 actors can also collude by acting in multiple locations 260 simultaneously (a "distributed bad actor"). 262 2.3.1. Externally-located Bad Actors 264 DKIM focuses primarily on bad actors located outside of the 265 administrative units of the claimed originator and the recipient. 266 These administrative units frequently correspond to the protected 267 portions of the network adjacent to the originator and recipient. It 268 is in this area that the trust relationships required for 269 authenticated message submission do not exist and do not scale 270 adequately to be practical. Conversely, within these administrative 271 units, there are other mechanisms such as authenticated message 272 submission that are easier to deploy and more likely to be used than 273 DKIM. 275 External bad actors are usually attempting to exploit the "any to 276 any" nature of email which motivates most recipient MTAs to accept 277 messages from anywhere for delivery to their local domain. They may 278 generate messages without signatures, with incorrect signatures, or 279 with correct signatures from domains with little traceability. They 280 may also pose as mailing lists, greeting cards, or other agents which 281 legitimately send or re-send messages on behalf of others. 283 2.3.2. Within Claimed Originator's Administrative Unit 285 Bad actors in the form of rogue or unauthorized users or malware- 286 infected computers can exist within the administrative unit 287 corresponding to a message's origin address. Since the submission of 288 messages in this area generally occurs prior to the application of a 289 message signature, DKIM is not directly effective against these bad 290 actors. Defense against these bad actors is dependent upon other 291 means, such as proper use of firewalls, and mail submission agents 292 that are configured to authenticate the sender. 294 In the special case where the administrative unit is non-contiguous 295 (e.g., a company that communicates between branches over the external 296 Internet), DKIM signatures can be used to distinguish between 297 legitimate externally-originated messages and attempts to spoof 298 addresses in the local domain. 300 2.3.3. Within Recipient's Administrative Unit 302 Bad actors may also exist within the administrative unit of the 303 message recipient. These bad actors may attempt to exploit the trust 304 relationships which exist within the unit. Since messages will 305 typically only have undergone DKIM verification at the administrative 306 unit boundary, DKIM is not effective against messages submitted in 307 this area. 309 For example, the bad actor may attempt to apply a header such as 310 Authentication-Results [I-D.kucherawy-sender-auth-header] which would 311 normally be added (and spoofing of which would be detected) at the 312 boundary of the administrative unit. This could be used to falsely 313 indicate that the message was authenticated successfully. 315 As in the originator case, these bad actors are best dealt with by 316 controlling the submission of messages within the administrative 317 unit. Depending on the characteristics of the administrative unit, 318 cryptographic methods may or may not be needed to accomplish this. 320 3. Representative Bad Acts 322 One of the most fundamental bad acts being attempted is the delivery 323 of messages which are not authorized by the alleged originating 324 domain. As described above, these messages might merely be unwanted 325 by the recipient, or might be part of a confidence scheme or a 326 delivery vector for malware. 328 3.1. Use of Arbitrary Identities 330 This class of bad acts includes the sending of messages which aim to 331 obscure the identity of the actual sender. In some cases the actual 332 sender might be the bad actor, or in other cases might be a third- 333 party under the control of the bad actor (e.g., a compromised 334 computer). 336 DKIM is effective in mitigating against the use of addresses not 337 controlled by bad actors, but is not effective against the use of 338 addresses they control. In other words, the presence of a valid DKIM 339 signature does not guarantee that the signer is not a bad actor. It 340 also does not guarantee the accountability of the signer, since that 341 is limited by the extent to which domain registration requires 342 accountability for its registrants. However, accreditation and 343 reputation systems can be used to enhance the accountability of DKIM- 344 verified addresses and/or the likelihood that signed messages are 345 desirable. 347 3.2. Use of Specific Identities 349 A second major class of bad acts involves the assertion of specific 350 identities in email. 352 Note that some bad acts involving specific identities can sometimes 353 be accomplished, although perhaps less effectively, with similar 354 looking identities that mislead some recipients. For example, if the 355 bad actor is able to control the domain "examp1e.com" (note the "one" 356 between the p and e), they might be able to convince some recipients 357 that a message from admin@examp1e.com is really admin@example.com. 358 Similar types of attacks using internationalized domain names have 359 been hypothesized where it could be very difficult to see character 360 differences in popular typefaces. Similarly, if example2.com was 361 controlled by a bad actor, the bad actor could sign messages from 362 bigbank.example2.com which might also mislead some recipients. To 363 the extent that these domains are controlled by bad actors, DKIM is 364 not effective against these attacks, although it could support the 365 ability of reputation and/or accreditation systems to aid the user in 366 identifying them. 368 3.2.1. Exploitation of Social Relationships 370 One reason for asserting a specific origin address is to encourage a 371 recipient to read and act on particular email messages by appearing 372 to be an acquaintance or previous correspondent that the recipient 373 might trust. This tactic has been used by email-propagated malware 374 which mail themselves to addresses in the infected host's address 375 book. In this case, however, the sender's address may not be 376 falsified, so DKIM would not be effective in defending against this 377 act. 379 It is also possible for address books to be harvested and used by an 380 attacker to send messages from elsewhere. DKIM would be effective in 381 mitigating these acts by limiting the scope of origin addresses for 382 which a valid signature can be obtained when sending the messages 383 from other locations. 385 3.2.2. Identity-Related Fraud 387 Bad acts related to email-based fraud often, but not always, involve 388 the transmission of messages using specific origin addresses of other 389 entities as part of the fraud scheme. The use of a specific address 390 of origin sometimes contributes to the success of the fraud by 391 helping convince the recipient that the message was actually sent by 392 the alleged sender. 394 To the extent that the success of the fraud depends on or is enhanced 395 by the use of a specific origin address, the bad actor may have 396 significant financial motivation and resources to circumvent any 397 measures taken to protect specific addresses from unauthorized use. 399 3.2.3. Reputation Attacks 401 Another motivation for using a specific origin address in a message 402 is to harm the reputation of another, commonly referred to as a "joe- 403 job". For example, a commercial entity might wish to harm the 404 reputation of a competitor, perhaps by sending unsolicited bulk email 405 on behalf of that competitor. It is for this reason that reputation 406 systems must be based on an identity that is, in practice, fairly 407 reliable. 409 4. Attacks on Message Signing 411 Bad actors can be expected to exploit all of the limitations of 412 message authentication systems. They are also likely to be motivated 413 to degrade the usefulness of message authentication systems in order 414 to hinder their deployment. Both the signature mechanism itself and 415 declarations made regarding use of message signatures (often referred 416 to as Sender Signing Policy, Sender Signing Practices or SSP) can be 417 expected to be the target of attacks. 419 The sections below begin with a table summarizing the postulated 420 attacks in each category along with their expected impact and 421 likelihood. The following criteria were used in scoring the attacks 422 against these criteria: 424 Impact: 426 High: Affects the verification of messages by an entire domain or 427 multiple domains 429 Medium: Affects the verification of messages by specific users, MTAs, 430 and/or bounded time periods 432 Low: Affects the verification of isolated individual messages only 434 Likelihood: 436 High: All users of DKIM should expect this attack on a frequent basis 438 Medium: Users of DKIM should expect this attack occasionally; 439 frequently for a few users 441 Low: Attack is expected to be rare and/or very infrequent 443 4.1. Attacks Against Message Signatures 445 Summary of postulated attacks against DKIM signatures: 447 +---------------------------------------------+--------+------------+ 448 | Attack Name | Impact | Likelihood | 449 +---------------------------------------------+--------+------------+ 450 | Theft of private key for domain | High | Low | 451 | Theft of delegated private key | Medium | Medium | 452 | Private key recovery via timing attack | High | Low | 453 | Chosen message replay | Low | M/H | 454 | Signed message replay | Low | High | 455 | Denial-of-service attack against verifier | High | Medium | 456 | Denial-of-service attack against key | High | Medium | 457 | service | | | 458 | Canonicalization abuse | Low | Medium | 459 | Body length limit abuse | Medium | Medium | 460 | Use of revoked key | Medium | Low | 461 | Compromise of key server | High | Low | 462 | Falsification of key service replies | Medium | Medium | 463 | Publication of malformed key records and/or | High | Low | 464 | signatures | | | 465 | Cryptographic weaknesses in signature | High | Low | 466 | generation | | | 467 | Display name abuse | Medium | High | 468 | Compromised system within originator's | Medium | Medium | 469 | network | | | 470 +---------------------------------------------+--------+------------+ 472 4.1.1. Theft of Private Key for Domain 474 Message signing technologies such as DKIM are vulnerable to theft of 475 the private keys used to sign messages. This includes "out-of-band" 476 means for this theft, including burglary, bribery, extortion, and the 477 like, as well as electronic means for such theft, such as a 478 compromise of network and host security around the place where a 479 private key is stored. 481 Keys which are valid for all addresses in a domain typically reside 482 in MTAs which should be located in well-protected sites, such as data 483 centers. Various means should be employed for minimizing access to 484 private keys, such as non-existence of commands for displaying their 485 value, although ultimately memory dumps and the like will probably 486 contain the keys. Due to the unattended nature of MTAs, some 487 countermeasures, such as the use of a pass phrase to "unlock" a key, 488 are not practical to use. 490 4.1.2. Theft of Delegated Private Key 492 There are several circumstances where a domain owner will want to 493 delegate the ability to sign messages for the domain to an individual 494 user or a third-party associated with an outsourced activity such as 495 a corporate benefits administrator or a marketing campaign. Since 496 these keys may exist on less well-protected devices than the domain's 497 own MTAs, they will in many cases be more susceptible to compromise. 499 In order to mitigate this exposure, keys used to sign such messages 500 can be restricted by the domain owner to be valid for signing 501 messages only on behalf of specific addresses in the domain. This 502 maintains protection for the majority of addresses in the domain. 504 4.1.3. Private Key Recovery via Timing Attack 506 Timing attacks are a technique whereby the private key is recovered 507 by observing the time required to sign a series of messages. It 508 requires both the ability to submit messages for signing as well as 509 the ability to accurately measure the time required to compute the 510 signature. 512 In most cases, an MTA has are enough variables (system load, clock 513 resolution, queuing delays, etc.) to prevent the signing time from 514 being measured accurately enough to be useful for a timing attack. 515 Furthermore, while some domains, e.g., consumer ISPs, would allow an 516 attacker to submit messages for signature, with many other domains 517 this is difficult. Other mechanisms, such as mailing lists hosted by 518 the domain, might be paths by which an attacker might submit messages 519 for signature, and should also be considered as possible vectors for 520 timing attacks. 522 4.1.4. Chosen Message Replay 524 Chosen Message Replay (CMR) refers to the scenario where the attacker 525 creates a message and obtains a signature for it by sending it 526 through an MTA authorized by the originating domain to him/herself or 527 an accomplice. They then "replay" the signed message by sending it, 528 using different envelope addresses, to a (typically large) number of 529 other recipients. 531 Due to the requirement to get an attacker-generated message signed, 532 Chosen Message Replay would most commonly be experienced by consumer 533 ISPs or others offering email accounts to clients, particularly where 534 there is little or no accountability to the account holder (the 535 attacker in this case). One approach to this problem is for the 536 domain to only sign email for clients that have passed a vetting 537 process to provide traceability to the message originator in the 538 event of abuse. At present, the low cost of email accounts (zero) 539 does not make it practical for any vetting to occur. It remains to 540 be seen whether this will be the model with signed mail as well, or 541 whether a higher level of trust will be required to obtain an email 542 signature. 544 Revocation of the signature is a potential countermeasure. However, 545 the rapid pace at which the message might be replayed (especially 546 with an army of "zombie" computers), compared with the time required 547 to detect the attack and implement the revocation, is likely to be 548 problematic. A related problem is the likelihood that domains will 549 use a small number of signing keys for a large number of customers, 550 which is beneficial from a caching standpoint but presents a problem 551 revoking some signatures and not others. To this end, "revocation 552 identifiers" have been proposed which would permit more fine-grained 553 revocation, perhaps on a per-account basis. Messages containing 554 these identifiers would result in a query to a revocation database, 555 which might be represented in DNS. Further study is needed to 556 determine if the benefits from revocation (given the potential speed 557 of a replay attack) outweigh the transactional cost of querying the 558 revocation database. 560 4.1.5. Signed Message Replay 562 Signed Message Replay (SMR) refers to the retransmission of already- 563 signed messages to additional recipients beyond those intended by the 564 sender. The attacker arranges to receive a message from the victim, 565 and then retransmits it intact but with different envelope addresses. 566 This might be done, for example, to make it look like a legitimate 567 sender of messages is sending a large amount of spam. When 568 reputation services are deployed, this could damage the originator's 569 reputation. 571 A larger number of domains are potential victims of SMR than of CMR, 572 because the former does not require the ability for the attacker to 573 send messages from the victim domain. However, the capabilities of 574 the attacker are lower. Unless coupled with another attack such as 575 body length limit abuse, it isn't possible for the attacker to use 576 this, for example, for advertising. 578 Many mailing lists, especially those which do not modify the content 579 of the message and signed headers and hence do not invalidate the 580 signature, engage in a form of SMR. The only things that distinguish 581 this case from undesirable forms of SMR is the intent of the 582 replayer, which cannot be determined by the network. 584 4.1.6. Denial-of-Service Attack Against Verifier 586 While it takes some compute resources to sign and verify a signature, 587 it takes negligible compute resources to generate an invalid 588 signature. An attacker could therefore construct a "make work" 589 attack against a verifier, by sending a large number of incorrectly- 590 signed messages to a given verifier, perhaps with multiple signatures 591 each. The motivation might be to make it too expensive to verify 592 messages. 594 While this attack is feasible, it can be greatly mitigated by the 595 manner in which the verifier operates. For example, it might decide 596 to accept only a certain number of signatures per message, limit the 597 maximum key size it will accept (to prevent outrageously large 598 signatures from causing unneeded work), and verify signatures in a 599 particular order. 601 4.1.7. Denial-of-Service Attack Against Key Service 603 An attacker might also attempt to degrade the availability of an 604 originator's key service, in order to cause that originator's 605 messages to be unverifiable. One way to do this might be to quickly 606 send a large number of messages with signatures which reference a 607 particular key, thereby creating a heavy load on the key server. 608 Other types of DoS attacks on the key server or the network 609 infrastructure serving it are also possible. 611 The best defense against this attack is to provide redundant key 612 servers, preferably on geographically-separate parts of the Internet. 613 Caching also helps a great deal, by decreasing the load on 614 authoritative key servers when there are many simultaneous key 615 requests. The use of a key service protocol which minimizes the 616 transactional cost of key lookups is also beneficial. It is noted 617 that the Domain Name System has all these characteristics. 619 4.1.8. Canonicalization Abuse 621 Canonicalization algorithms represent a tradeoff between the survival 622 of the validity of a message signature and the desire not to allow 623 the message to be altered inappropriately. In the past, 624 canonicalization algorithms have been proposed which would have 625 permitted attackers, in some cases, to alter the meaning of a 626 message. 628 Message signatures which support multiple canonicalization algorithms 629 give the signer the ability to decide the relative importance of 630 signature survivability and immutability of the signed content. If 631 an unexpected vulnerability appears in a canonicalization algorithm 632 in general use, new algorithms can be deployed, although it will be a 633 slow process because the signer can never be sure which algorithm(s) 634 the verifier supports. For this reason, canonicalization algorithms, 635 like cryptographic algorithms, should undergo a wide and careful 636 review process. 638 4.1.9. Body Length Limit Abuse 640 A body length limit is an optional indication from the signer how 641 much content has been signed. The verifier can either ignore the 642 limit, verify the specified portion of the message, or truncate the 643 message to the specified portion and verify it. The motivation for 644 this feature is the behavior of many mailing lists which add a 645 trailer, perhaps identifying the list, at the end of messages. 647 When body length limits are used, there is the potential for an 648 attacker to add content to the message. It has been shown that this 649 content, although at the end, can cover desirable content, especially 650 in the case of HTML messages. 652 If the body length isn't specified, or if the verifier decides to 653 ignore the limit, body length limits are moot. If the verifier or 654 recipient truncates the message at the signed content, there is no 655 opportunity for the attacker to add anything. 657 If the verifier observes body length limits when present, there is 658 the potential that an attacker can make undesired content visible to 659 the recipient. The size of the appended content makes little 660 difference, because it can simply be a URL reference pointing to the 661 actual content. Recipients need to use means to, at a minimum, 662 identify the unsigned content in the message. 664 4.1.10. Use of Revoked Key 666 The benefits obtained by caching of key records opens the possibility 667 that keys which have been revoked may be used for some period of time 668 after their revocation. The best examples of this occur when a 669 holder of a key delegated by the domain administrator must be 670 unexpectedly deauthorized from sending mail on behalf of one or more 671 addresses in the domain. 673 The caching of key records is normally short-lived, on the order of 674 hours to days. In many cases, this threat can be mitigated simply by 675 setting a short time-to-live for keys not under the domain 676 administrator's direct control (assuming, of course, that control of 677 the time-to-live value may be specified for each record, as it can 678 with DNS). In some cases, such as the recovery following a stolen 679 private key belonging to one of the domain's MTAs, the possibility of 680 theft and the time required to revoke the key authorization must be 681 considered when choosing a TTL. The chosen TTL must be long enough 682 to mitigate denial-of-service attacks and provide reasonable 683 transaction efficiency, and no longer. 685 4.1.11. Compromise of Key Server 687 Rather than by attempting to obtain a private key, an attacker might 688 instead focus efforts on the server used to publish public keys for a 689 domain. As in the key theft case, the motive might be to allow the 690 attacker to sign messages on behalf of the domain. This attack 691 provides the attacker with the additional capability to remove 692 legitimate keys from publication, thereby denying the domain the 693 ability for the signatures on its mail to verify correctly. 695 The host which is the primary key server, such as a DNS master server 696 for the domain, might be compromised. Another approach might be to 697 change the delegation of key servers at the next higher domain level. 699 This attack can be mitigated somewhat by independent monitoring to 700 audit the key service. However, it may be difficult to detect the 701 publication of additional keys by such means until the selector(s) 702 added by the attackers are known. 704 4.1.12. Falsification of Key Service Replies 706 Replies from the key service may also be spoofed by a suitably 707 positioned attacker. For DNS, one such way to do this is "cache 708 poisoning", in which the attacker provides unnecessary (and 709 incorrect) additional information in DNS replies, which is cached. 711 DNSSEC [RFC4033] is the preferred means of mitigating this threat, 712 but the current uptake rate for DNSSEC is slow enough that one would 713 not like to create a dependency on its deployment. Fortunately, the 714 vulnerabilities created by this attack are both localized and of 715 limited duration, although records with relatively long TTL may be 716 created with cache poisoning. 718 4.1.13. Publication of Malformed Key Records and/or Signatures 720 In this attack, the attacker publishes suitably crafted key records 721 or sends mail with intentionally malformed signatures, in an attempt 722 to confuse the verifier and perhaps disable verification altogether. 723 This attack is really a characteristic of an implementation 724 vulnerability, a buffer overflow or lack of bounds checking, for 725 example, rather than a vulnerability of the signature mechanism 726 itself. This threat is best mitigated by careful implementation and 727 creation of test suites that challenge the verification process. 729 4.1.14. Cryptographic Weaknesses in Signature Generation 731 The cryptographic algorithms used to generate mail signatures, 732 specifically the hash algorithm and the public-key encryption/ 733 decryption operations, may over time be subject to mathematical 734 techniques that degrade their security. At this writing, the SHA-1 735 hash algorithm is the subject of extensive mathematical analysis 736 which has considerably lowered the time required to create two 737 messages with the same hash value. This trend can be expected to 738 continue. 740 The message signature system must be designed to support multiple 741 signature and hash algorithms, and the signing domain must be able to 742 specify which algorithms it uses to sign messages. The choice of 743 algorithms must be published in key records, rather than in the 744 signature itself, to ensure that an attacker is not able to create 745 signatures using algorithms weaker than the domain wishes to permit. 747 Due to the fact that the signer and verifier of email do not, in 748 general, communicate directly, negotiation of the algorithms used for 749 signing cannot occur. In other words, a signer has no way of knowing 750 which algorithm(s) a verifier supports, nor (due to mail forwarding) 751 where the verifier is. For this reason, it is expected that once 752 message signing is widely deployed, algorithm change will occur 753 slowly, and legacy algorithms will need to be supported for a 754 considerable period. Algorithms used for message signatures 755 therefore need to be secure against expected cryptographic 756 developments several years into the future. 758 4.1.15. Display Name Abuse 760 Message signatures only relate to the address-specification portion 761 of an email address, which some MUAs only display (or some recipients 762 only pay attention to) the display name portion of the address. This 763 inconsistency leads to an attack where the attacker uses an From 764 header field such as: 766 From: "Dudley DoRight" 768 In this example, the attacker, whiplash@example.org, can sign the 769 message and still convince some recipients that the message is from 770 Dudley DoRight, who is presumably a trusted individual. Coupled with 771 the use of a throw-away domain or email address, it may be difficult 772 to bring the attacker to account for the use of another's display 773 name. 775 This is an attack which must be dealt with in the recipient's MUA. 776 One approach is to require that the signer's address specification 777 (and not just the display name) be visible to the recipient. 779 4.1.16. Compromised System Within Originator's Network 781 In many cases, MTAs may be configured to accept, and sign, messages 782 which originate within the topological boundaries of the originator's 783 network (i.e., within a firewall). The increasing use of compromised 784 systems to send email presents a problem for such policies, because 785 the attacker, using a compromised system as a proxy, can generate 786 signed mail at will. 788 Several approaches exist for mitigating this attack. The use of 789 authenticated submission, even within the network boundaries, can be 790 used to limit the addresses for which the attacker may obtain a 791 signature. It may also help locate the compromised system that is 792 the source of the messages more quickly. Content analysis of 793 outbound mail to identify undesirable and malicious content, as well 794 as monitoring of the volume of messages being sent by users, may also 795 prevent arbitrary messages from being signed and sent. 797 4.2. Attacks Against Message Signing Policy 799 Summary of postulated attacks against signing policy: 801 +---------------------------------------------+--------+------------+ 802 | Attack Name | Impact | Likelihood | 803 +---------------------------------------------+--------+------------+ 804 | Look-alike domain names | High | High | 805 | Internationalized domain name abuse | High | Medium | 806 | Denial-of-service attack against signing | Medium | Medium | 807 | policy | | | 808 | Use of multiple From addresses | Low | Medium | 809 +---------------------------------------------+--------+------------+ 811 4.2.1. Look-Alike Domain Names 813 Attackers may attempt to circumvent signing policy of a domain by 814 using a domain name which is close to, but not the same as the domain 815 with a signing policy. For instance, "example.com" might be replaced 816 by "examp1e.com". If the message is not to be signed, DKIM does not 817 require that the domain used actually exist (although other 818 mechanisms may make this a requirement). Services exist to monitor 819 domain registrations to identify potential domain name abuse, but 820 naturally do not identify the use of unregistered domain names. 822 4.2.2. Internationalized Domain Name Abuse 824 Internationalized domain names present a special case of the look- 825 alike domain name attack described above. Due to similarities in the 826 appearance of many Unicode characters, domains (particularly those 827 drawing characters from different groups) may be created which are 828 visually indistinguishable from other, possibly high-value domains. 829 This is discussed in detail in Unicode TR 36 [UTR36]. Surveillance 830 of domain registration records may point out some of these, but there 831 are many such similarities. As in the look-alike domain attack 832 above, this technique may also be used to circumvent sender signing 833 policy of other domains. 835 4.2.3. Denial-of-Service Attack Against Signing Policy 837 Just as the publication of public keys by a domain can be impacted by 838 an attacker, so can the publication of Sender Signing Policy (SSP) by 839 a domain. In the case of SSP, the transmission of large amounts of 840 unsigned mail purporting to come from the domain can result in a 841 heavy transaction load requesting the SSP record. More general DoS 842 attacks against the servers providing the SSP records are possible as 843 well. This is of particular concern since the default signing policy 844 is "we don't sign everything", which means that SSP, in effect, fails 845 open. 847 As with defense against DoS attacks for key servers, the best defense 848 against this attack is to provide redundant servers, preferably on 849 geographically-separate parts of the Internet. Caching again helps a 850 great deal, and signing policy should rarely change, so TTL values 851 can be relatively large. 853 4.2.4. Use of Multiple From Addresses 855 Although this usage is rare, RFC 2822 [RFC2822] permits the From 856 address to contain multiple address specifications. The lookup of 857 Sender Signing Policy is based on the From address, so if addresses 858 from multiple domains are in the From address, the question arises 859 which signing policy to use. A rule (say, "use the first address") 860 could be specified, but then an attacker could put a throwaway 861 address prior to that of a high-value domain. It is also possible 862 for SSP to look at all addresses, and choose the most restrictive 863 rule. This is an area in need of further study. 865 5. Derived Requirements 867 This section, as yet incomplete, is an attempt to capture a set of 868 requirements for DKIM from the above discussion. These requirements 869 include: 871 The store for key and SSP records must be capable of utilizing 872 multiple geographically-dispersed servers. 874 Key and SSP records must be cacheable, either by the verifier 875 requesting them or by other infrastructure. 877 The cache time-to-live for key records must be specifiable on a 878 per-record basis. 880 The algorithm(s) used by the signing domain associated with a 881 given key must be specified independently of the signature itself. 883 6. IANA Considerations 885 This document defines no items requiring IANA assignment. 887 7. Security Considerations 889 This document describes the security threat environment in which 890 DomainKeys Identified Mail (DKIM) is expected to provide some 891 benefit, and presents a number of attacks relevant to its deployment. 893 8. Informative References 895 [I-D.allman-dkim-base] 896 Allman, E., "DomainKeys Identified Mail (DKIM)", 897 draft-allman-dkim-base-01 (work in progress), 898 October 2005. 900 [I-D.allman-dkim-ssp] 901 Allman, E., "DKIM Sender Signing Policy", 902 draft-allman-dkim-ssp-01 (work in progress), October 2005. 904 [I-D.crocker-email-arch] 905 Crocker, D., "Internet Mail Architecture", 906 draft-crocker-email-arch-04 (work in progress), 907 March 2005. 909 [I-D.kucherawy-sender-auth-header] 910 Kucherawy, M., "Message Header for Indicating Sender 911 Authentication Status", 912 draft-kucherawy-sender-auth-header-02 (work in progress), 913 May 2005. 915 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 916 April 2001. 918 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 919 Rose, "DNS Security Introduction and Requirements", 920 RFC 4033, March 2005. 922 [UTR36] Davis, M. and M. Suignard, "Unicode Security 923 Considerations", UTR 36, July 2005. 925 Appendix A. Glossary 927 Origin address - The address on an email message, typically the RFC 928 2822 From: address, which is associated with the alleged author of 929 the message and is displayed by the recipient's MUA as the source of 930 the message. 932 More definitions to be added. 934 Appendix B. Acknowledgements 936 The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony 937 Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon 938 Callas, and Stephen Farrell for valuable suggestions and constructive 939 criticism of earlier versions of this draft. 941 Appendix C. Edit History 943 Changes since -00 draft: 945 o Changed beginning of introduction to make it consistent with -base 946 draft. 948 o Clarified reasons for focus on externally-located bad actors. 950 o Elaborated on reasons for effectiveness of address book attacks. 952 o Described attack time windows with respect to replay attacks. 954 o Added discussion of attacks using look-alike domains. 956 o Added section on key management attacks. 958 Changes since -01 draft: 960 o Reorganized description of bad actors. 962 o Greatly expanded description of attacks against DKIM and SSP. 964 o Added "derived requirements" section. 966 Author's Address 968 Jim Fenton 969 Cisco Systems, Inc. 970 MS SJ-24/2 971 170 W. Tasman Drive 972 San Jose, CA 95134-1706 973 USA 975 Phone: +1 408 526 5914 976 Email: fenton@cisco.com 977 URI: 979 Intellectual Property Statement 981 The IETF takes no position regarding the validity or scope of any 982 Intellectual Property Rights or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in 984 this document or the extent to which any license under such rights 985 might or might not be available; nor does it represent that it has 986 made any independent effort to identify any such rights. Information 987 on the procedures with respect to rights in RFC documents can be 988 found in BCP 78 and BCP 79. 990 Copies of IPR disclosures made to the IETF Secretariat and any 991 assurances of licenses to be made available, or the result of an 992 attempt made to obtain a general license or permission for the use of 993 such proprietary rights by implementers or users of this 994 specification can be obtained from the IETF on-line IPR repository at 995 http://www.ietf.org/ipr. 997 The IETF invites any interested party to bring to its attention any 998 copyrights, patents or patent applications, or other proprietary 999 rights that may cover technology that may be required to implement 1000 this standard. Please address the information to the IETF at 1001 ietf-ipr@ietf.org. 1003 Disclaimer of Validity 1005 This document and the information contained herein are provided on an 1006 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1007 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1008 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1009 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1010 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1011 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1013 Copyright Statement 1015 Copyright (C) The Internet Society (2005). This document is subject 1016 to the rights, licenses and restrictions contained in BCP 78, and 1017 except as set forth therein, the authors retain all their rights. 1019 Acknowledgment 1021 Funding for the RFC Editor function is currently provided by the 1022 Internet Society.