idnits 2.17.1 draft-otis-dkim-threats-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1167. ** 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 (October 24, 2005) is 6759 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) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-02) exists of draft-allman-dkim-ssp-01 -- No information found for draft-crocker-csv-intro - is the name correct? == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-04 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-workgroup D. Otis 3 Internet-Draft Trend Micro, NSSG 4 Expires: April 27, 2006 October 24, 2005 6 Review of Threats Associated with Email and DomainKeys Identified Mail 7 (DKIM) 8 draft-otis-dkim-threats-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document is intended to provide an alternative perspective to 42 the document prepared by Jim Fenton for DomainKeys Identified Mail 43 (DKIM), although it borrows from his substantial effort. This review 44 removes emphasis on email-address domains, as DKIM allows signatures 45 to be independent of the email-address. This document also considers 46 the impact of adding an opaque-identifier and implementing abusive 47 message replay abatement. This document considers threats against 48 Internet mail and threats created when employing a signature-based 49 method for establishing an accountable domain for a message, in 50 particular DKIM. This document also ranks threat levels, modes of 51 access, Bad Actors and their capabilities, and possible motivations 52 for various attack scenarios. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Scope of DKIM . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 7 60 5. Ranking of Bad Actors . . . . . . . . . . . . . . . . . . . . 7 61 6. Capabilities of Bad Actors . . . . . . . . . . . . . . . . . . 8 62 6.1 General capabilities . . . . . . . . . . . . . . . . . . . 8 63 6.2 Advanced capabilities . . . . . . . . . . . . . . . . . . 9 64 7. Bad Actor's Points of Access . . . . . . . . . . . . . . . . . 9 65 7.1 Bad Actors with Access in the Administrative Unit . . . . 10 66 7.1.1 Access in the Signing-Domain's Administrative Unit . . 10 67 7.1.2 Access in the Recipient's Administrative Unit . . . . 10 68 7.2 Bad Actors with External Access . . . . . . . . . . . . . 11 69 8. Representative Bad Acts . . . . . . . . . . . . . . . . . . . 11 70 8.1 Use of Arbitrary Identities . . . . . . . . . . . . . . . 11 71 8.2 Use of Specific Identities . . . . . . . . . . . . . . . . 12 72 8.2.1 Exploitation of Social Relationships . . . . . . . . . 12 73 8.2.2 Identity-Related Fraud . . . . . . . . . . . . . . . . 12 74 8.2.3 Reputation Attacks . . . . . . . . . . . . . . . . . . 13 75 9. Attacks on Message Signing . . . . . . . . . . . . . . . . . . 13 76 9.1 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.2 Invalid Signatures . . . . . . . . . . . . . . . . . . . . 14 78 9.2.1 Canonicalization and Message Normalization . . . . . . 14 79 9.3 Body Length Parameter . . . . . . . . . . . . . . . . . . 14 80 9.4 Multiple Signatures . . . . . . . . . . . . . . . . . . . 14 81 9.5 Use of "throw-away" domains . . . . . . . . . . . . . . . 15 82 9.6 Message Replay Attack . . . . . . . . . . . . . . . . . . 16 83 10. Threats to Delivery . . . . . . . . . . . . . . . . . . . . 19 84 11. Urgent Response to Threats for Consumer Protections . . . . 19 85 11.1 Restricted Two-Party Communication . . . . . . . . . . . . 19 86 11.2 Unrestricted Multiple-Party Communication . . . . . . . . 20 87 11.3 Opportunistic Protection without Domain-wide Policy 88 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 20 89 12. Sender Signing Policy . . . . . . . . . . . . . . . . . . . 21 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 91 14. Security Considerations . . . . . . . . . . . . . . . . . . 23 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 15.1 Normative References . . . . . . . . . . . . . . . . . . . 23 94 15.2 Informative References . . . . . . . . . . . . . . . . . . 24 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 96 Intellectual Property and Copyright Statements . . . . . . . . 25 98 1. Introduction 100 Message signing, as exemplified by DomainKeys Identified Mail (DKIM) 101 [I-D.allman-dkim-base], is a mechanism to allow an assertion of an 102 accountable domain for an email message in transit. The assertion is 103 made by means of a digital signature included within a header. This 104 signature also validates the integrity of selected headers and 105 message body content subsequent to signing the message. This review 106 is based upon the work of Jim Fenton, but differs from the 107 perspectives regarding the role of an email-address and how replay, 108 intra-domain, and DoS attacks may be handled. 110 For example, on the DKIM list Jim suggested Sender-ID's path- 111 registration and authorization mechanism could be a possible solution 112 for a message replay abuse problem. Unfortunately path-registration 113 imposes upon DKIM problematic limitations that would also be very 114 disruptive. Path-registration would also essentially constrain 115 mailbox-addresses to specific providers. In addition, path- 116 registration already exposes email-address domain owners to risks 117 where path authorization may form the basis for accrual of unfair 118 reputations. Within shared environments, requisite checks to ensure 119 email-address domain exclusivity may not have been made. Such checks 120 may be beyond the control of the email-address domain owner, while 121 those who are in control remain unaccounted. 123 With DKIM, once an accountable domain has been established for a 124 message and where the reputation of this domain can be defended, the 125 recipient may assess the reputation accrued by the signing-domain 126 when deciding whether to accept the message. This assessment can be 127 made using locally-maintained white-lists, and reputation/ 128 accreditation services. By applying a signature, the conduct 129 permitted by the signing-domain may be accurately accrued to 130 establish a valid reputation. Good conduct is generally maintained 131 when there are expectations that future messages will be accepted by 132 the recipient from the signing-domain. 134 2. Scope of DKIM 136 DKIM verifies the association of a specific domain with a message 137 using a signature and a public key. This mechanism also ensures 138 selected headers and body content have not been altered since the 139 domain's association. The DKIM effort is not intended to address 140 threats associated with message confidentiality nor provide a 141 signature suitable for long-term archival. The scope of DKIM does 142 not include semantics for reputation or accreditation services or 143 white-listing practices. DKIM does not provide a direct method to 144 verify the identity of a message's author. DKIM does not provide 145 safe mechanisms for authorizing messages associated with different 146 domain signatures. 148 3. Vulnerabilities 150 Email is exposed to several security related threats where 151 exploitation of a vulnerability often results in substantial damages. 152 The following table provides a general overview of vulnerabilities 153 and side-effects created by defensive strategies. 155 +------------------------+---------------------+------------+----------+ 156 | Vulnerability | Damage | Prevalence | Severity | 157 +------------------------+---------------------+------------+----------+ 158 | Unfair Reputations | Loss of Service | Low | Medium | 159 | Collateral IP Blocking | Loss of Service | Low | Medium | 160 | Filtering Errors | Loss of Service | Low | Medium | 161 | Junk Folder | Loss of Service | Low | Medium | 162 | Delete w/o DSN | Loss of Service | Low | Medium | 163 | DoS | Loss of Service | Low | Medium | 164 | Name Blocking | Loss of Service | Low | High | 165 | Message Spoofing | Defrauded User | Medium | High | 166 | OS Flaws | Compromised System | Medium | High | 167 | Stolen Passwords | Compromised Account | Medium | High | 168 | Malware Payloads | Compromised System | High | High | 169 | Timing Analysis | Compromised Key | Low | High | 170 | Network Exploits | Compromised Privacy | Low | High | 171 +------------------------+---------------------+------------+----------+ 173 An Unfair Reputation regards assessments made against the email- 174 address. These unfair assessments may occur when the email-address 175 domain owner is assumed to control the use of their email-address 176 domain. The email-address domain owner may have been obliged to 177 authorize the shared systems of a service provider when registering 178 prescribed email paths. Checks are often not performed by an 179 unaccounted provider that should ensure only the owner is able to 180 utilize their email-address domain. The public nature of system 181 authorizations and prevalence of compromised systems place the email- 182 address domain owners at great risk when reputation is based upon the 183 email-address. 185 Collateral IP Blocking occurs when email systems are being shared and 186 many email-address domains utilize common IP addresses. When one of 187 these email-address domains displays abusive conduct, an IP address 188 based reputation service may list the IP address and consequently 189 block all other email-address domains sharing the IP address. 191 Filtering Errors may occur when erroneously relying on a phrase or 192 name. These errors cause the normal processing of the message to be 193 altered. Abusers often spoof many elements within their message 194 largely to avoid being filtered and this may increase the filtering 195 program's sensitivity to otherwise innocent domains. This type of 196 erroneous sensitivity could be viewed as another type of unfair 197 reputation. The message may be "bounced", placed into the "Junk 198 Folder", or deleted without the issuing of a Delivery Status 199 Notification (DSN). With the breakdown of email policy enforcement, 200 email filtering has become a common alternative to manual, and also 201 highly error-prone, deletion of unwanted email. 203 The Junk Folder has become the catch-all repository of questionable 204 email. The increased use of multi-level acceptance criteria also 205 increases the portion of email placed into the Junk Folder. Ideally, 206 acceptance criteria would provide a binary go/no-go result. Stronger 207 methods of authentication that singularly identify an accountable 208 entity may assist in achieving such a goal. 210 Deletion without Delivery Status Notification may occur when messages 211 have been accepted but then, perhaps through the use of analytical 212 heuristics, the message is subsequently identified as unwanted. In 213 the case of message deletion, the provider does not notify the sender 214 since even the bounce-address is typically considered invalid. This 215 mode of operation represents a significant reduction in the integrity 216 of email delivery. 218 Denial of Service attacks may not be intentional, and could be the 219 result of unsolicited bulk email. An enterprise attempting to run 220 their own email service may find their networks unable to deal with 221 the vast amount of unwanted email. Being able to reject unwanted 222 email early in the exchange is critical when network resources are 223 limited. Signatures carried within the message will not allow for 224 early rejection and thus not offer any DoS protection. Simply 225 dropping the connection may result in a storm of retries. DoS 226 protections based upon a domain, rather than an IP address, can be 227 achieved by verifying the EHLO name, as it still permits early 228 rejection while also avoiding IP address collateral blocking, see 229 [I-D.crocker-csv-intro] and [I-D.crocker-csv-csa]. Domain-based 230 assessments derived from the EHLO or a domain signature could utilize 231 a name based reputation service, commonly referred to as a Right- 232 Hand-Side Black-hole List (RHSBL). Attacks from unlisted domains 233 would be retained together with the IP addresses within a local list. 235 Name Blocking may result from unfair reputation accrual. Such 236 accrual could occur when feedback is based upon email-address domains 237 held accountable for having authorized a system sending abusive 238 email. The damage would be much worse than that caused by collateral 239 IP address blocking. In the case where the IP address is blocked, 240 the email-address domain owner would be able to obtain services 241 elsewhere as a remedy. In the case of Name Blocking, there may not 242 be any remedy, which represents a serious problem. This problem may 243 become endemic with email-address authorization mechanisms. 245 Message Spoofing uses many techniques to mislead either the recipient 246 or a message filter. Often the email-address domain appears random, 247 or contains several randomly generated domain labels. Such randomly 248 generated labels may still be valid when a DNS wildcard resource 249 record is used. In the case where some level of authentication is 250 asserted by the MUA, the domain used to achieve the authentication 251 may rely upon the recipient seeing the "pretty-name" rather than the 252 actual email-address. For various reasons, methods that attempt to 253 select a visible header to authorize an email-address domain, still 254 may permit hidden headers. The complexity of the selection 255 algorithms may also confuse the average recipient, where any 256 indication of the message having been authorized may be exploited. 258 Operating System flaws will always exist. Some operating systems 259 offer better secured internal communication and program execution. 260 Minimizing the exposure of system services to external access reduces 261 the number of exploits possible. Automated system monitoring is 262 often needed to react to attack attempts. Otherwise, the scale of 263 deployment may require overwhelming manual monitoring. 265 Stolen Passwords are a common problem. There are many enterprises 266 that use protocols that send passwords in the clear. With the 267 prevalence of wireless networks with weak protections, passwords sent 268 in the clear should be considered the same as publishing them. In 269 addition, many of the programs that compromise systems also do 270 keyboard and paste buffer logging sent covertly to the criminals 271 stealing sensitive information. Even access to a microphone near the 272 keyboard may reveal passwords. Once access is gained, even with a 273 low privilege, many applications automatically assert the password 274 when sending or receiving messages. 276 Malware Payloads may be carried in items that receive special 277 handling. Examples could be pictures or scripts embedded within a 278 message or referenced via URLs. It could also be attachments added 279 to the message, often where the name of the attachment has been 280 obfuscated to convince the recipient they can safely invoke the 281 operating system's default handling routines. 283 Timing Analysis is an attack method that takes advantage of knowing 284 the algorithm used for processing the signature. When the private 285 portion of the key is involved in the process, care must be taken to 286 ensure the time performing the operation is not revealed. This 287 timing enables techniques that deduce the private key. Even with 288 random latency variations introduced by the network, this variation 289 can be significantly reduced by finding the median from additional 290 measurements. 292 Network Exploits are also becoming more common. These attacks 293 exploit various elements of the network infrastructure, often 294 misdirecting network traffic. This may involve falsified 295 configuration information, falsified connection redirects or hijacks, 296 poisoned domain name servers, and even corrupted routing elements. 298 4. Security Requirements 300 The use of private keys within the signing MTA server increases the 301 level of security required to safely provide the DKIM signing 302 services. External access to non-essential services should be 303 prevented using appropriate measures. The Operating System should 304 also be monitored for execution of unauthorized programs and access 305 attempts to otherwise protected services. When the server is running 306 within a virtual machine, special care must be exercised with respect 307 to timing attacks on private keys where even processing loads may 308 reveal sensitive information. The generation of a signature should 309 be staged to mask the actual time expended as a means to protect the 310 private key. As email is often held in queues during processing, 311 results may be held for an assured duration to conceal the time 312 related to signing. 314 5. Ranking of Bad Actors 316 The problems confronted by DKIM can be generalized as the result of 317 abusive acts by individuals taking advantage of the open nature of 318 email. For the purposes of this document, these abusive individuals 319 will be referred to as Bad Actors. Bad Actors have become more 320 sophisticated, and their motivations have become increasingly 321 criminal in nature. 323 At the low end of severity, Bad Actors may represent unsophisticated 324 individuals taking advantage of many commercially available tools. 325 These tools may facilitate messages being sent in bulk, or may employ 326 criminal strategies that avoid being identified and subsequently 327 blocked. Unsolicited messages sent in bulk often becomes the basis 328 used for blocking future exchanges. As newer methods of 329 identification are attempted, often these bulk distribution tools 330 represent a significant portion of applications adopting the newer 331 protocol extensions. The adoption of the extensions is often based 332 upon another strategy where changing identities becomes a small cost 333 for sustaining their nefarious enterprise. 335 The next level of severity could be considered a surreptitious 336 service provider that specializes in sending unsolicited email. 337 These Bad Actors often employ infrastructure specifically designed to 338 obfuscate their identity. Their infrastructure may include open- 339 proxies, open-relays, and the use of multiple points of access which 340 take advantage of asymmetric routing as a means to disguise source IP 341 addresses. Their infrastructure may also be established using 342 thousands of compromised systems that may have been leased. 344 Another technique used by Bad Actors is to send to low priority 345 backup MTAs with the expectation messages will be bounced and the 346 intended recipient is contained within the bounce-address. This 347 bounced message technique is another method used to obfuscate the 348 source IP address of the message. Although this IP address is 349 typically found in the Received headers, the reputation of this 350 Received header IP address is not always checked. Bad Actors 351 offering such services often provide email address lists to their 352 clientele that may have been obtained from compromised systems, 353 harvested, purchased, or discovered by means of dictionary attacks. 355 The highest level of severity would be represented by criminals who 356 intend to commit fraud and who are financially-motivated. These Bad 357 Actors are becoming organized and specialized with rapidly growing 358 sophistication and threaten not only email, but the network itself. 359 These Bad Actors should be expected to employ all of the above 360 mechanisms, in addition to attacks on Internet infrastructure, such 361 as DNS cache-poisoning attacks, and IP routing attacks via 362 compromised network routing elements, and more. 364 6. Capabilities of Bad Actors 366 6.1 General capabilities 368 In general, Bad Actors described above should be expected to have 369 access to the following: 371 1. An extensive corpus of messages from targeted domains 373 2. Knowledge of the practices used by targeted domains 375 3. Access to public keys and associated authorization records 376 published by the targeted domains 378 and the ability to do at least some of the following: 380 1. Generate substantial numbers of unsigned messages that might 381 represent either an intentional or unintentional denial of 382 service attack 384 2. Transmit messages using any envelope information desired 385 3. Transmit messages using any message headers desired 387 4. Submit messages to MTAs from multiple locations within the 388 Internet 390 5. Sign messages on behalf of domains from registrars that protect 391 the domain owner's privacy or that have poor vetting practices 393 6. Generate substantial numbers of messages with invalid signatures 394 which may be an attempt to create a denial of service attack by 395 overwhelming DKIM verification 397 7. Resend messages which may have been previously signed by other 398 domains 400 6.2 Advanced capabilities 402 Certain classes of Bad Actors may have substantial financial 403 motivation, and therefore could be expected to have more capabilities 404 at their disposal. These include: 406 1. Access to significant computing resources, perhaps through the 407 conscription of many compromised systems. This could allow Bad 408 Actors to perform various types of brute-force attacks. 410 2. Manipulation of IP routing. This could be used to submit 411 messages from specific IP addresses or difficult-to-trace 412 addresses, or to cause diversion of messages to a specific 413 domain. 415 3. Influence over portions of DNS using mechanisms, such as cache 416 poisoning. This might be used to influence message routing, or 417 to falsify DNS-based key or policy advertisements. 419 4. Ability to eavesdrop on some existing traffic, perhaps from a 420 wireless network, a cable or DSL modem, or a compromised server 421 or router. 423 The last three of these mechanisms could permit Bad Actors to 424 redirect traffic and masquerade as a desired destination. Such 425 redirection provides a means to deceive the recipient or those 426 attempting to send messages, and may be used to obtain access-related 427 information among other sensitive data. 429 7. Bad Actor's Points of Access 431 In the following discussion, the term "Administrative Unit", taken 432 from [I-D.crocker-email-arch], is used to refer to a portion of the 433 email path under common administration. Recipients usually establish 434 mutual authentications with Administrative Units receiving and 435 verifying their email using shared secrets and server certificates. 436 Administrative Units that perform message signing also usually 437 establish mutual authentication using shared secrets and server 438 certificates. 440 7.1 Bad Actors with Access in the Administrative Unit 442 Bad Actors can obtain access anywhere in the Internet. Bad Actors 443 that have privileged access within the Administrative Unit of the 444 signing-domain or the recipient domain have capabilities beyond those 445 elsewhere, as described in following sections. 447 7.1.1 Access in the Signing-Domain's Administrative Unit 449 Bad Actors may gain access using compromised accounts or systems 450 within the Administrative Unit corresponding to the signing-domain. 451 Although submission of messages generally occurs prior to the 452 application of a message signature, DKIM could still be effective at 453 isolating compromised accounts, and should be effective at isolating 454 compromised message signing systems when each system utilizes 455 specific keys. Defense in such cases would be improved by monitoring 456 for account abuse and system integrity, in addition to limiting 457 access to local system services. 459 DKIM can be effective at improving email security within the 460 Administrative Unit, especially in the case where an Administrative 461 Unit has systems coupled by the Internet. DKIM signatures can 462 validate legitimate externally-originated messages considered within 463 the Administrative Unit. 465 7.1.2 Access in the Recipient's Administrative Unit 467 Bad Actors may gain access using compromised systems within the 468 Administrative Unit of the message recipient. Since messages 469 typically undergo DKIM verification one time within a possible 470 successions of systems carrying messages to their destination within 471 the Administrative Unit, DKIM may not detect invalid messages from 472 compromised systems that are subsequent to the DKIM verification. 473 Bad Actors may also masquerade as a system within the succession as 474 another means of introducing invalid messages. Defense in such cases 475 would be improved by verifying DKIM at the last system in the 476 succession, using authentication mechanisms like SMTP AUTH, by 477 monitoring system integrity, in addition to limiting access to local 478 system services. 480 7.2 Bad Actors with External Access 482 DKIM focuses primarily on Bad Actors that do not have privileged 483 access within the Administrative Units of the signer or the 484 recipient. Outside these Administrative Units, the trust 485 relationships required for authenticated message submission do not 486 exist and do not scale adequately to be practical. 488 Bad Actors with only external access will usually attempt to exploit 489 the open nature of email. Most Administrative Units will accept 490 messages with a valid email address for a local domain, often after 491 investigating the reputation of the source IP address. Bad Actors 492 may generate messages without signatures and rely upon techniques 493 that obfuscate their source IP address. 495 When signing-domains accrue reputations serving as a basis for 496 acceptance, Bad Actors may take advantage of registrars that protect 497 the privacy of domain owners, or that do not verify the domain 498 owner's identity in a reliable manner. Bad Actors may then use these 499 domains without an initial negative reputation to generate messages 500 with valid signatures. Bad Actors may send messages containing a 501 diversity of email addresses to avoid filtering techniques. Often 502 this ploy by Bad Actors is attempted while posing as mailing lists, 503 greeting cards, or other agents which legitimately send or re-send 504 messages on behalf of others. 506 8. Representative Bad Acts 508 One of the most common bad acts attempted is the delivery of messages 509 which obfuscate their true source within the network or associated 510 domain. The purpose of obfuscation might be to gain acceptance or to 511 defraud the recipient. The severity of this problem ranges from 512 messages merely being unwanted, to defrauding the recipient or 513 compromising their system with a payload of malware. 515 8.1 Use of Arbitrary Identities 517 Arbitrary Identifiers typify those bad acts aimed at obfuscation to 518 gain acceptance of messages. Such methods use a wide range of 519 techniques as previously described. 521 DKIM may be effective for abating the misuse of a domain which 522 asserts all messages are signed by the domain. The effectiveness of 523 DKIM at preventing domain misuse would depend upon the prevalence of 524 recipients validating DKIM signatures and obtaining domain-wide 525 assertions. For cases where a domain is not being misused, or when 526 signed by a domain controlled by Bad Actors, the recipient would then 527 be reliant upon reputation or accreditation services for protection. 529 8.2 Use of Specific Identities 531 A second major class of bad acts involves the assertion of specific 532 identities in email. 534 8.2.1 Exploitation of Social Relationships 536 One reason for falsifying an associated domain is to encourage a 537 recipient to act on a particular email message that appears to be 538 from an acquaintance or previous correspondent trusted by the 539 recipient. This tactic has been used by email-propagated malware 540 which emails to addresses in the compromised system's address book. 541 In this case, the sender's email address and related signatures may 542 not have been falsified, so DKIM would not be directly effective in 543 preventing this act, but could facilitate the isolation of the 544 compromised system when an opaque-identifier has been included, see 545 [I-D.otis-mass-reputation]. Using opaque-identifiers would allow 546 rapid correlations of malware sources by third-parties monitoring for 547 this type of threat. 549 It is also possible for address books to be harvested and used by an 550 attacker to send messages from elsewhere. DKIM may be effective at 551 mitigating these acts when the recipient verifies the DKIM signature 552 and when the sending domains assert all messages are signed by the 553 domain. It is also possible for the recipient to retain a binding of 554 the opaque-identifier with the signing-domain associated with the 555 sender's email-address, see [I-D.otis-mass-reputation]. 557 8.2.2 Identity-Related Fraud 559 Bad acts related to email-based fraud often involve the transmission 560 of messages misusing visible associated domains as part of the fraud 561 scheme. The misuse of a specific associated domain sometimes 562 contributes to the success of the fraud by convincing the recipient 563 that the message is valid. 565 To the extent the success of the fraud is enhanced by the misuse of a 566 specific visible associated domain, Bad Actors may have significant 567 motivation and resources to circumvent measures that target specific 568 headers for unauthorized use. There could be exigent cases where a 569 domain-wide assertion becomes beneficial if it prohibits the 570 appearance of the domain in any originating header unless also signed 571 by the domain. This would be accomplished with a domain-wide 572 assertion made by the signing-domain, similar to the assertion that 573 all messages are signed by the domain, see [I-D.otis-mass- 574 reputation]. 576 8.2.3 Reputation Attacks 578 Another motivation for using a specific associated domain in a 579 message is to harm the reputation of the domain. For example, a 580 commercial entity might wish to harm the reputation of a competitor, 581 perhaps by sending a copy of their competitor's signed promotion as 582 unsolicited bulk email. A reputation service would categorize abuse 583 primarily by the recipient, and not the message content. A 584 reputation service would not be able to differentiate between valid 585 and invalid uses of a signed message. 587 While reputation services must accrue behaviors based upon verified 588 identifiers, there must also be a means to mitigate ongoing abuse. 589 Without a means to abate ongoing abuse, the reputation service, which 590 must be responsive to the needs of their subscribers, would have 591 little choice but to list the domain being attacked and expect them 592 to undergo a rehabilitation process. Rehabilitation may involve a 593 demonstration of having a means to respond to abuse. See the 594 following section on Message Replay Attacks. 596 9. Attacks on Message Signing 598 Bad Actors can be expected to exploit all of the limitations of 599 message authentication systems. They are also likely to be motivated 600 to degrade the usefulness of message authentication systems in order 601 to hinder their deployment, when the systems prove effective. Some 602 categories of bad acts are described below. Additional postulated 603 attacks are described in the Security Considerations section of 604 [I-D.allman-dkim-base]. 606 9.1 DoS Attack 608 Checking either the authorizations associated with a message 609 signature or the verification of the signature will not afford any 610 Denial of Service protections. There are only two choices available 611 where DoS protections are possible. The DoS protections could be 612 based upon the remote IP address or upon the verification of the EHLO 613 name. In the case of the EHLO name, the problem associated 614 collateral blocking is overcome, and a subsequent reputation check on 615 the signing-domain may be skipped when the EHLO name is within the 616 signing-domain. 618 If the strength of the EHLO is not considered adequate, it may be 619 possible to added a signature, the last digit of the year, and the 620 week number prefixed to the EHLO name delineated with an '_'. The 621 hash of the EHLO would could include a string that represents all but 622 the lower three bits of the remote IP address. After all, the EHLO 623 is currently permitted to fail verification. 625 9.2 Invalid Signatures 627 Messages with invalid signatures would be handled as messages without 628 signatures. Such messages would be handled in the normal fashion 629 where the reputation of the remote IP address would be assessed. 630 Rejections based upon the remote IP address often creates a problem 631 when the address is being shared. When a Bad Actor sharing the IP 632 address sends abusive email, other entities may be collaterally 633 blocked when a negative reputation is then applied. Such blocking 634 may encourage those that find themselves blocked to adopt message 635 signing as an alternative basis for reputation assessment. 637 9.2.1 Canonicalization and Message Normalization 639 Until signatures are known to be reliably valid throughout the email 640 infrastructure, invalid signatures should be treated in the same 641 manner as a message without a signature. As with any message, these 642 messages may be introduced by Bad Actors. The intent may be to have 643 the message appear as though it was legitimately sent, but "broken" 644 in transit. This should not affect how the message is handled, and 645 the reputation of the remote IP address should still be assessed. 647 To minimize the number of broken messages and thus improve the 648 reliability of the message signature, message normalization is 649 required to ensure line-lengths are compliant prior to signing. The 650 current simple canonization is rather fragile, whereas the relaxed 651 canonicalization allows for several exploits. On the DKIM list, Earl 652 Hood has recommended what appears to be a suitable replacement for 653 the no-white-space method. This technique removes white-spaces 654 preceding end-of-lines and streaming white-space at the beginning and 655 end of the message body. 657 9.3 Body Length Parameter 659 The Body Length parameter available as an option within DKIM must be 660 used with great caution. Recipients that find the message length has 661 increased, should discard the portion of the message that prevents 662 signature validation when included as signed content. The concept 663 behind this option was to accommodate the appending of information by 664 providers or some list servers. As this option can be easily 665 exploited, especially through a list server, mandating the deletion 666 of added information would be the only solution that prevents this 667 option from inviting an abusive message replay problem. 669 9.4 Multiple Signatures 671 The DKIM draft offers little guidance with respect to multiple 672 signatures. Multiple signatures, rather than offering greater 673 information, may obfuscate the role played by the signer. There have 674 been suggestions that signatures be sequenced by way of a count 675 added, or by their header order within the message. Unfortunately 676 these techniques do not clarify which signature is significant with 677 respect to the initial signer. Any miscreant could either rearrange 678 signature headers, add sequence numbers that appear as if signatures 679 have been dropped, or add several "throw-away" signatures where 680 reputation accrual may be diffused. Multiple signatures also provide 681 plausible deny ability when a reputation service attempts to locate 682 the accountable domain. An association with an email-address may not 683 clarify the role of the signer, as the signing may be done by domains 684 that are independent of any message headers. There should also be a 685 limit with respect to the number of signatures allowed within a 686 message, as each signature represents added message overhead. 688 It may be advisable to have signature headers that clarify the role 689 of the signer. The current signature header could be considered the 690 "Originating" signer. A list server may add their signature as a 691 "Remailing" signer. The receiving domain within the recipient's 692 Administrative Unit may wish to add their "Verifying" signature as 693 verification that various checks have been completed. Any previous 694 signatures of the same role would be deleted and perhaps logged 695 within the Received headers. The "Verifying" signature should not be 696 considered valid beyond the Administrative Unit. 698 For additional protection against message replay attacks, a practice 699 could be established that restricts these three roles to a single 700 signature per message. A Remailing signature may encompass the 701 Originating signature. A Verifying signature may encompass both the 702 Originating signature and the Remailing signature. When adding a 703 signature that encompass previous signatures, the signature 704 information associated the 'b=' tag with could be overwritten with 705 "remailing-checked", "verifying-checked" or "invalid." The typical 706 recipient could rely upon the Verifying signature provided by the 707 Administrative Unit at the MUA, but would not have access to 708 signatures that could be used to stage a message replay attack. 710 In a situation where message replay attacks become problematic for 711 messages sent to a specific domain, the signing domain may wish to 712 preclude sending signed messages to these domains. The receiving 713 domain may wish to prevent the possibility that any of their users 714 could be capable of such an attack by obfuscating Originating and 715 Remailing signatures and adding the Verifying signature. 717 9.5 Use of "throw-away" domains 719 Bad Actors may also introduce messages with valid signatures from 720 domains they control, perhaps "throw-away" domains registered under 721 false pretenses or using registrars that protect the privacy of the 722 domain owner. In other words, the existence of a message signature 723 does not imply the conduct of a signing-domains is trustworthy. The 724 already common use of such domains require domain-based accreditation 725 or reputation systems. A reputation service may not be able to 726 differentiate between a new and a throw-away domain. A Bad Actor 727 could also acquire a domain previously used for legitimate purposes. 728 Reputation services may extend the weighing of behaviors to include 729 that of the registrar. Current name based reputation systems are 730 known as Right-Hand-Side reputation services. Even without the use 731 of a name-based reputation service, local reputation, mostly in the 732 form of white-lists, can be maintained by domains to improve the 733 deliverability of email from domains where existing relationships 734 have been established. 736 Accreditation and reputation, or even local white-lists, require a 737 verifiable identity upon which to base the accrual of behaviors and 738 possible feedback reports. Message signing provides an identity 739 which is intended to be sufficiently reliable for this purpose. A 740 verifiable identity is necessary for accreditation and reputation 741 systems to operate, provided there is a means established to either 742 prevent or abate message replay attacks. 744 Providers operating shared email services, mailing lists, and other 745 legitimate agents may commonly sign messages with headers containing 746 differing domains. This common practice offers valuable freedoms for 747 typical users. This practice may allow a Bad Actor to sign messages 748 containing divergent domains and to also appear legitimate. 749 Nevertheless, the assessments of the signing-domain should remain the 750 primary factor when deciding whether to accept the messages. When 751 the signing-domain is provided by a registrar that ensures domain 752 owner privacy and has not obtained a recent reputation, little 753 confidence in the signing-domain can be obtained. As with message 754 replay abatement, such mysterious signing-domains may be given a 755 Transient Negative Completion reply. Over time, the signing-domain 756 will become known, or the administrators of the signing-domain may 757 contact the relevant reputation and accreditation services. 759 9.6 Message Replay Attack 761 Attacks based upon abusive retransmission of an otherwise valid 762 message is referred to in this document as a "message replay attack". 763 DKIM is able to provide an option that offers a means to promptly 764 abate this type of replay, while also identifying all culpable 765 sources, see [I-D.otis-mass-reputation]. This could be accomplished 766 using an opaque-identifier revocation mechanism that is checked when 767 the message appears to be coming from a different domain, or when the 768 recipient has changed. Abusive replay abatement is essential for the 769 protection of the signing-domain's reputation. 771 Message replay must be allowed to occur, even at high levels. 772 Legitimate replays may result when a message is distributed through a 773 list server, for example. As valid message replay is performed at 774 systems unrelated to the signing-domain, this replay process must be 775 monitored for abuse, and strategies will be needed to deter efforts 776 attempting to elude an abatement process. There are methods that can 777 be used to mitigate the precautions needed to deal with a potential 778 replay problem. The EHLO verification, essential for name based DoS 779 protections, could also mitigate replay abatement. A signed hash of 780 a salted [RFC2821] RCPT TO header could be another replay abatement 781 mitigation strategy. 783 Part of this mitigation strategy may involve delaying the complete 784 processing of messages identified as having potential replay risk. 785 This delay is needed to allow abuse-monitoring the requisite time to 786 react, which could be done within minutes. This processing delay may 787 occur at the transmitter, or the receiver, or at a combination of 788 both. Transient Negative Completion replies indicating the request 789 was aborted with an error in processing should cause the message to 790 be held at the transmitter, see [RFC2821]. The receiver may opt to 791 queue a limited number of messages identified as having a replay 792 risk, and once that limit has been reached, a Transient Negative 793 Completion reply is issued. This mechanism could be further 794 mitigated by white-lists of trusted message resenders, such as list 795 servers. 797 When a message appears to be coming from a different domain and has 798 an invalid hash of the [RFC2821] RCPT TO, as yet another option, 799 messages may be held within a queue for a brief period to allow time 800 for an opaque-identifier revocation to occur, see [I-D.otis-mass- 801 reputation]. While opaque-identifiers may normally reflect the 802 account used to gain access, serializing the opaque-identifier per a 803 recipient of bulk email may also isolate the culpable recipient. 805 Revocation of keys would not be a practical solution, as this will 806 likely impact the delivery of many unrelated messages and will not 807 likely be as prompt. However, revocation of the opaque-identifier 808 could also act as acknowledgement to a reputation or accreditation 809 service that the signing-domain has responded to the reported abuse. 810 Even the listing of revocations could become a service by delegating 811 the revocation zone. Lengthy delays in responding would provide 812 little protection against such acts and likely precipitate a negative 813 reputation as well as increased abuse. 815 Bad Actors may obtain a reply from an individual within a signing- 816 domain that carries a copy of their desired content. The reply may 817 then be used to distribute the desired content in bulk where no 818 account has been obtained from the signing domain. The person 819 replying may be unaware of the risk. When Bad Actors obtain an 820 account from a provider that offers services to the public, and they 821 send a small number of messages with desired content to addresses 822 controlled by Bad Actors, the activity of the account will appear 823 normal, but messages obtained can be used for abusive replay. 825 Some other suggestions to abate message replay abuse burden the 826 recipient. These suggestions are usually based upon content 827 filtering of messages that have been signed. Once an unwanted 828 message is discovered through filtering, signature finger-prints may 829 then be used to identify any replicate message. There is no 830 assurance Bad Actors will not limit the number of replicate messages 831 sent to a specific domain. In such a case, filters would not be 832 greatly advantaged by the signature. There is also a suggestion that 833 the signature finger-print itself accrues a reputation. It is then 834 expected the recipient would obtain the services of a signature 835 finger-print reputation service. The amount of centralized data 836 exchanged to support a signature finger-print reputation scheme would 837 represent a significant increased burden for the recipient that would 838 be difficult to scale for either the service or the recipient. 840 Other suggestions attempt to burden the sender. Some suggestions 841 have the signing-domain employ outbound content filtering. Although 842 outbound filtering could be a reasonable practice, the effectiveness 843 of filtering is never 100%. Bad Actors attempting to accumulate 844 signed messages sent to themselves would be advantaged by outbound 845 filters. Messages that manage to evade outbound filters are also 846 likely to evade inbound filters employed in other domains. Another 847 strategy suggests to enforce greater accountability for accounts 848 whose messages are to be signed by DKIM. Even with exorbitant fines 849 exacted and with extensive vetting processes, there remains the 850 problem created by the millions of compromised systems. The stricter 851 policies would increase the harm created by the compromised systems. 853 Perhaps the greatest suggested burden placed upon the sender is to 854 register the paths for all their valid email. An onerous enough task 855 is made more difficult with the path registration being predicated 856 upon an email-address domain within a specific header selected in a 857 non-compliant fashion, and not the signature itself. See the section 858 on Sender Signing Policy below. This mingling of mail-address domain 859 paths with a signing-domain path is actually attempting to solve two 860 different problems simultaneously. Neither message replay abuse, nor 861 the misuse of an email-address is effectively prevented. For many 862 years from now, there will be recipients that use forwarded accounts, 863 or users wishing to send messages to simple exploding list servers. 864 These uses, as well as hundreds of others, will create a multitude of 865 exceptions that must be accommodated. Each method of accommodation 866 represents a means for exploitation. 868 10. Threats to Delivery 870 DKIM relies upon more of the network infrastructure. Normal email 871 exchanges depend upon the recipient's DNS to locate MTAs that accept 872 delivery for the recipient. DKIM adds reliance upon the signing- 873 domain's DNS for distributing public-keys. With DKIM's Sender 874 Signing Policy (SSP) [I-D.allman-dkim-ssp], as currently defined, 875 delivery also depends upon allowances made for "third-party" signers 876 when the [RFC2822] Sender, Resent-From, or Resent-Sender headers are 877 used by the signing-domain. Such increased dependency, especially 878 with respect to policy assertions, represents additional avenues for 879 attack and will negatively impact many commonly used email services. 881 While DNSSEC [RFC4033][RFC4034][RFC4035] offers protection from 882 various attacks on DNS, its greater overhead may increase DKIM DoS 883 vulnerabilities. There could be increased susceptibility at the 884 recipient's DNS resolver, especially when wildcard public-keys or 885 policies have been published. Synthetic labels may allow an attack 886 with increased requisite interaction and caching prior to verifying 887 the signature. 889 An SSP policy which excludes third-party signing, and is the only 890 mode that can repudiate Bad Actors, may cause messages to become lost 891 when remailed, or mailed. For example, such a policy could prevent 892 messages containing an email-address in the [RFC2822] From header 893 from surviving mailing lists that sign messages, or when sent as 894 signed news articles or invitations. Such a consequence will 895 discourage the vital adoption of the only policy that affords 896 protection from Bad Actors. 898 11. Urgent Response to Threats for Consumer Protections 900 11.1 Restricted Two-Party Communication 902 While "phishing" attacks may be creating an exigent situation 903 requiring an urgent response, parsing a complex policy record for 904 qualifiers and lists of authorized "third-party" signers is not 905 something that can be incorporated quickly. A simpler record is 906 required to allow immediate incorporation into MTAs as a means to 907 offer the most expedient response to this type of threat. This 908 lookup should be offered as a service by the industry to combat this 909 specific threat. 911 A Two-Party listing service should simply return a record to indicate 912 the queried domain prohibits the use of this domain within any email 913 parameter or header unless also signed by this domain. This would 914 limit the use of the listed domain to two-party exchanges. 915 Exceptions for messages containing the prohibited domain would be 916 made when the only recipient is the prohibited domain. 918 11.2 Unrestricted Multiple-Party Communication 920 When multiple-party email exchanges are to be protected, an assertion 921 that all emails are exclusively signed by the domain should be based 922 upon the header specified by [RFC2822] as having introduced the 923 message into the email transport system. Compliance with [RFC2822] 924 email transport introduction allows common services to be retained 925 without specific white-listing. No information has been lost with 926 respect to the signing domain and the email-address contained within 927 the From header. The receiving domain may assess such messages 928 according to the relationships indicated. However, acceptance should 929 be primarily based upon the reputation of the signing-domain. Where 930 it is absolutely critical that the From header for a specific domain 931 be protected, the Two-Party listing service should be used. By 932 removing any disruption in services resulting from a domain signing 933 all their messages and making assertions on that basis would allow 934 immediate repudiation of Bad Actors. The current SSP policy 935 necessitates a disruption in some services in order to repudiate 936 messages from Bad Actors. 938 Authorizing third-party signing defeats protection from Bad Actors. 939 SSP's use of the From header to designate which domain establishes 940 signing policy is disruptive and limits the scope of messages that 941 can be afforded protection. Messages being remailed where they are 942 signed and reintroduced into the email transport system following 943 [RFC2822] conventions, may be designated by SSP policies as being 944 signed by "third-party" domains. Rather an adhering to [RFC2822] 945 conventions for establishing the header having introduced the message 946 into the transport, the often visible From header was used as a basis 947 instead, while risking the loss of a substantial number of otherwise 948 valid messages and limiting the adoption of a protective policy. 950 11.3 Opportunistic Protection without Domain-wide Policy Assertions 952 SSP designating the From, or when multiple-addresses exist, the 953 Sender header for establishing signing policy is primarily to abate 954 attempts at falsifying the author's email-address when third-party 955 signing is not permitted. Such falsification is often the case in 956 "phishing" attacks. The success of such an effort remains doubtful 957 as many MUAs display just the "pretty-name." Policy based upon the 958 visible header also does not deal with threats associated with 959 domains that have a similar appearance and with MUAs susceptible to 960 character-set attacks. 962 Attempts to base policy on the [RFC2822] From header significantly 963 decreases protections afforded by DKIM by imposing dire consequences 964 when indicating emails are signed exclusively by the domain. While 965 white-lists of authorized third-party signers may mitigate some 966 unintended message loss, such an authorization strategy burdens the 967 recipient, is expensive to maintain, and is not practical. 969 DKIM can offer significant protection for multiple-party email 970 commutations without the separate publication of signing policy. 971 There is an alternative method that can be used to extend protection 972 to recipient. This strategy would take advantage of the situation 973 that protection is often desired for prior correspondents. With the 974 messages being signed, the message itself offers a secure means to 975 communicate what elements within the message can be relied upon to 976 uniquely identify the message's author. 978 For domains that assure those granted access are limited to specific 979 email-addresses, any email-address from this domain can then be used 980 to uniquely identify the author. Domains that do not limit the 981 email-address can alternatively offer an opaque-identifier within the 982 signature to uniquely identify the account used to gain access. The 983 recipient could request that bindings of the requisite identifiers be 984 saved. With these bindings saved, the recipient can then be alerted 985 when these identifiers have changed in subsequent messages. In some 986 cases, it would be possible to automatically retain the bindings at 987 the MTA rather than just the MUA. 989 By retaining binding for those specific email-addresses considered 990 important to the recipient, greater analysis can occur to defeat 991 "pretty-name", character-set, and domain look-alike attacks. When an 992 identifier appeared to have changed, the recipient should be shown 993 the email-address and other identifiers using a consistent character- 994 set and asked if the information should replace or be merged with 995 current bindings, or perhaps be ignored, or flagged as a spoofing 996 attempt. 998 12. Sender Signing Policy 1000 DKIM Sender Signing Policy (SSP) [I-D.allman-dkim-ssp] attempts to 1001 introduce several constraints on an email-addresses found in one of 1002 two headers in conjunction with DKIM signatures. These constraints 1003 may indicate that a signature is required either of some third-party 1004 domain, or of a first-party domain, or no signature is required at 1005 all. The SSP also introduces a constraint placed upon the [RFC2822] 1006 From header that may be conditionally relegated to the Sender header 1007 when there are multiple email-addresses within the From header. 1008 Conditionally relegating the From to the Sender header may confuse 1009 recipients for two reasons. The Sender header may be indicated by 1010 some MUAs as being the significant email addresses. It also may not 1011 be obvious to the recipient when there are multiple email-addresses 1012 within the From header. 1014 It is also not clear how a third-party signature should be handled in 1015 the case where there are multiple signatures added to the message. 1016 Should a message that has a first-party signature and a policy that 1017 third-party signatures are prohibited, then cause a message to be 1018 rejected when a signature is added by a third-party? What happens 1019 when the first-party signature has expired, but the third-party 1020 signature is still valid? 1022 Unless the domain-wide assertion that all emails are signed follows 1023 normal email conventions with respect to which header introduced the 1024 message into the email transport system, there will be messages that 1025 are not be protected by the SSP From/Sender assertion. This failure 1026 to provide full protection in such cases was created by a desire to 1027 ensure the significant header related to policy is always visible. 1028 Nevertheless, to establish protections without disrupting email 1029 services, it would be beneficial to have an Introduction assertion. 1030 With an Introduction assertion, all messages that would normally be 1031 considered to have been introduced by a domain using [RFC2822] 1032 definitions would be assured protection. This approach would suffer 1033 from far fewer policy conflicts by other domains and provide much 1034 greater delivery integrity. 1036 The SSP strategy also fails to consider there are other methods that 1037 may be used to qualify email and assumes the From/Sender headers are 1038 always significant. An MUA that uses SPF Classic may indicate a 1039 message has been qualified based upon the [RFC2821] MAILFROM, but 1040 this parameter is not checked against the DKIM signing-domain, and 1041 yet the recipient may see a message as verified as a result of the 1042 MAILFROM. 1044 Once normal email conventions are allowed, a new assertion is 1045 required to protect those domains that have become "phishing" 1046 targets. This new assertion would prohibit other domains the use 1047 parameters and headers that could contain an email-address considered 1048 to have introduced the message. It would cover the MAILFROM, From, 1049 Sender, Reply-To, and corresponding Resent-* headers. Such a domain- 1050 wide assertion would curtail exploits still possible with an SSP 1051 policy that erroneously assumes what the recipient considers 1052 significant. 1054 Using non-compliant conventions with respect to the significant 1055 header also disrupts normal email practices. A domain making a 1056 domain-wide assertion that all messages are signed may be unable 1057 receive protection for some of their messages, and may find that some 1058 of their messages have been subsequently prohibited by other domains. 1059 Even appending a Sender or Resent-* header will not offer a solution, 1060 as the From header may retrain significance. 1062 Attempting to bind specific headers to a signing-domain has an 1063 unfortunate consequence that some mechanisms may unfairly extend 1064 accountability to the email-address. Any authorization of third- 1065 party signers with respect to a specific header's email-address is 1066 highly problematic. This authorization is likely to be assumed as 1067 having authenticated the email-address causing unfair reputation 1068 accrual. The SSP mechanism may also require an extensive number of 1069 lookups. This mechanism will require lookups walking up the label 1070 tree, to qualify the local-part of an email address, and, with a 1071 pending proposal, to also authorize specific third-party signers. 1073 13. IANA Considerations 1075 This document defines no items requiring IANA assignment. 1077 14. Security Considerations 1079 This document describes the security threat environment in which 1080 DomainKeys Identified Mail (DKIM) is expected to provide some 1081 benefit. 1083 15. References 1085 15.1 Normative References 1087 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1088 April 2001. 1090 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1091 April 2001. 1093 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1094 Rose, "DNS Security Introduction and Requirements", 1095 RFC 4033, March 2005. 1097 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1098 Rose, "Resource Records for the DNS Security Extensions", 1099 RFC 4034, March 2005. 1101 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1102 Rose, "Protocol Modifications for the DNS Security 1103 Extensions", RFC 4035, March 2005. 1105 15.2 Informative References 1107 [I-D.allman-dkim-base] 1108 Allman, E., "DomainKeys Identified Mail (DKIM)", 1109 draft-allman-dkim-base-01 (work in progress), 1110 October 2005. 1112 [I-D.allman-dkim-ssp] 1113 Allman, E., "DKIM Sender Signing Policy", 1114 draft-allman-dkim-ssp-01 (work in progress), October 2005. 1116 [I-D.crocker-csv-csa] 1117 Crocker, D., "Client SMTP Authorization (CSA)", 1118 draft-crocker-csv-csa-00 (work in progress), October 2005. 1120 [I-D.crocker-csv-intro] 1121 Crocker, D., Otis, D., and J. Leslie, "Certified Server 1122 Validation (CSV)", October 2005. 1124 [I-D.crocker-email-arch] 1125 Crocker, D., "Internet Mail Architecture", 1126 draft-crocker-email-arch-04 (work in progress), 1127 March 2005. 1129 [I-D.otis-mass-reputation] 1130 Otis, D., "MASS impacts upon reputation", 1131 draft-otis-mass-reputation-03 (work in progress), 1132 September 2005. 1134 Author's Address 1136 Douglas Otis 1137 Trend Micro, NSSG 1138 1737 North First Street, Suite 680 1139 San Jose, CA 95112 1140 USA 1142 Phone: +1.408.453.6277 1143 Email: doug_otis@trendmicro.com 1145 Intellectual Property Statement 1147 The IETF takes no position regarding the validity or scope of any 1148 Intellectual Property Rights or other rights that might be claimed to 1149 pertain to the implementation or use of the technology described in 1150 this document or the extent to which any license under such rights 1151 might or might not be available; nor does it represent that it has 1152 made any independent effort to identify any such rights. Information 1153 on the procedures with respect to rights in RFC documents can be 1154 found in BCP 78 and BCP 79. 1156 Copies of IPR disclosures made to the IETF Secretariat and any 1157 assurances of licenses to be made available, or the result of an 1158 attempt made to obtain a general license or permission for the use of 1159 such proprietary rights by implementers or users of this 1160 specification can be obtained from the IETF on-line IPR repository at 1161 http://www.ietf.org/ipr. 1163 The IETF invites any interested party to bring to its attention any 1164 copyrights, patents or patent applications, or other proprietary 1165 rights that may cover technology that may be required to implement 1166 this standard. Please address the information to the IETF at 1167 ietf-ipr@ietf.org. 1169 Disclaimer of Validity 1171 This document and the information contained herein are provided on an 1172 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1173 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1174 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1175 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1176 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1177 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1179 Copyright Statement 1181 Copyright (C) The Internet Society (2005). This document is subject 1182 to the rights, licenses and restrictions contained in BCP 78, and 1183 except as set forth therein, the authors retain all their rights. 1185 Acknowledgment 1187 Funding for the RFC Editor function is currently provided by the 1188 Internet Society.