idnits 2.17.1 draft-otis-dkim-harmful-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 23 characters in excess of 72. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2013) is 3966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4291' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC4408' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC4954' is defined on line 682, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-repute-email-identifiers-08 == Outdated reference: A later version (-13) exists of draft-kucherawy-dmarc-base-00 -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual D. Otis 3 Internet-Draft D. Rand 4 Intended status: Informational Trend Micro 5 Expires: December 19, 2013 June 17, 2013 7 DKIM is Harmful as Specified 8 draft-otis-dkim-harmful-03 10 Abstract 12 Currently, email lacks conventions ensuring SMTP clients can be 13 identified by an authenticated domain. Unfortunately many hope to 14 use DKIM as an alternative, but it is independent of intended 15 recipients and domains accountable for having sent the message. This 16 means DKIM is poorly suited at establishing abuse assessments of 17 unsolicited commercial email otherwise known as SPAM, nor was this 18 initially DKIM's intent. DKIM lacks message context essential to 19 ensure fair assessment and to ensure this assessment is not poisoned 20 (Who initiated the transaction and to whom). 22 DKIM was instead intended to establish increased levels of trust 23 based upon valid DKIM signatures controlling acceptance and what a 24 user sees within the FROM header field. But DKIM failed to guard 25 against pre-pended header fields where any acceptance based on valid 26 DKIM signatures is sure to exclude header field spoofing, especially 27 that of the FROM. This weakness allows malefactors to exploit DKIM 28 signature acceptance established by high-volume DKIM domains to spoof 29 ANY other domain, even when prohibited within the Signer's network. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 19, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Safe Incremental Deployment? . . . . . . . . . . . . . . . . . 5 73 3. Exploiting Trust . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Maintaining Trust . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Responding to Defects and Exploitation . . . . . . . . . . . . 9 76 6. Conflating DKIM Fragments with Email Messages . . . . . . . . 9 77 7. SMTP Can't . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. DKIM Vulnerability . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Barriers to an Authenticated Domain . . . . . . . . . . . . . 13 80 10. Domains as a Basis for Managing Traffic . . . . . . . . . . . 13 81 11. XMPP Shows the Way Forward . . . . . . . . . . . . . . . . . . 13 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 85 15. References - Informative . . . . . . . . . . . . . . . . . . . 15 86 Appendix A. DKIM Examples . . . . . . . . . . . . . . . . . . . . 17 87 Appendix B. Stats . . . . . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 Currently, IPv4 address reputation provides the primary basis for 93 defending open SMTP services (acceptance without prior arrangement). 94 Use of IP addresses in this role becomes impractical when dealing 95 with IPv6 [RFC2460] due to data requirements and an inability to 96 defend detection of subscription violations. There are currently 97 18,210,039,470,981,139 /64 equivalent IPv6 prefixes routed. 98 [v6-BGP-Rpts]. In comparison, for IPv4 there are 2,625,737,440 IP 99 addresses routed. While IPv4 is reaching its maximum, IPv6 has about 100 0.1% of the available /64 prefix routed and this continues to grow 101 rapidly. Unlike IPv4, there is no practical means to scan reverse 102 DNS namespace within IPv6 since each /64 prefix may contain any 103 number of PTR records ranging up to 184,000,000,000,000,000,000. 105 A technique commonly employed to automate IPv4 address categorization 106 of suitable hosts is to check whether reverse PTR records appear to 107 represent valid hostnames. Those that represent 4 decimal numbers 108 are often considered unacceptable, for example. Our processing of 109 reverse DNS namespace in cooperation with network providers now 110 excludes about 38%, or about 1,000,000,000 IPv4 addresses. Comparing 111 IPv6 /64 prefixes with the remainder of routable IPv4 addresses shows 112 there are 11.3 million times more IPv6 /64 prefixes needing 113 categorization. In addition, there is no practical means to 114 facilitate this effort. 116 IP address reputation requires logging associated connections to 117 permit review. Whether describing reputations as only positive or 118 only negative, errant exclusion or inclusion of either poses similar 119 risk. Tracking currently routed IPv6 /64 prefixes using a single bit 120 requires 6 million billion bytes or 5,650 Terra-bytes just to track 121 simple use. Even feedback by IPv6 address prefix will expose 122 mailboxes that detect subscription policy violations. 124 Some also suggest there will not be a significant increase in the 125 number of servers running over IPv6 and since their overall number 126 should be comparable, email should still be dealing with a similar 127 number of IP addresses. Unlike IPv4, IPv6 does not constrain the 128 number of IP addresses assigned to a network interface. This feature 129 allows each connection from a server to originate from a different IP 130 address, perhaps one for each user. The potential increase allowed 131 by IPv6 may prove explosive, even those only from good actors. 133 Members within organizations such as M3AAWG are suggesting SMTP error 134 response schemes to establish DKIM or SPF as acceptance requirements 135 to better ensure a domain offers a basis for acceptance to replace 136 that of the IP address used by SMTP clients. Due to the 137 understandable IPv6 reputation services' inability to scale, domain 138 based alternatives are being sought. Some at least understand DKIM 139 is unable to support negative reputation schemes. However, reliance 140 on a mechanism unable to sustain close scrutiny of negative 141 assertions makes sustained differentiation of positive and negative 142 views less tenable. 144 At this April's Rocky Mountain IPv6 Task Force summit in Denver, the 145 second day government track sessions raised concerns about there 146 being no means available to defend SMTP over IPv6. There are 147 proposals within the IETF aimed at establishing DKIM as a basis for 148 reputation schemes in the Repute WG (i.e. section 3.2 of 149 [I-D.ietf-repute-email-identifiers] which introduces DKIM domains 150 being used along with SMTP client IP addresses and rfc5321.helo also 151 identifying the SMTP client. Identifying the SMTP client encompasses 152 both "Who Initiated" and "To Whom" message elements to support fair 153 negative assertions. However, DKIM does not encompass this essential 154 information. In addition, DKIM's inability to detect invalid 155 prefixed header fields also means any positive DKIM reputation 156 assertion can prove highly harmful by increasing trust in possible 157 deceptions. 159 2. Safe Incremental Deployment? 161 [RFC5863] DKIM Development, Deployment, and Operation introduction 162 states: "DomainKeys Identified Mail (DKIM) allows an organization to 163 claim responsibility for transmitting a message, in a way that can be 164 validated by a recipient." Based on actual use of DKIM, Trendmicro 165 published a blog [TM-Blog] "Possible Phishing with DKIM". Dave 166 Crocker dismissed DKIM's phishing role in [Crocker-Blog] by stating: 167 "DKIM's sole job is to attach an identifier that can be believed, 168 specifically a domain name that can be unrelated to any other 169 identifier in the message. That domain name is used for associating 170 the reputation of the domain owner with the message."..."The DKIM 171 specification mandates that input to DKIM must be valid according to 172 RFC5322. In requiring this, it is placing a burden on the containing 173 system to ensure that a message is well-formed. It is not DKIM's job 174 to do the basic message validation; it's the job of the requesting 175 software." 177 Refuting this, [RFC6376] section 3.8 use of SHOULD does not mandate 178 compliance with [RFC5322] nor will non-compliance affect the validity 179 of a DKIM signature as it is currently defined. His response also 180 misconstrues the statement "DKIM was intended to authenticate domain 181 relationships with an email message bound at a minimum to that of the 182 From header field." as meaning "DKIM verifies the From header field." 183 This is wrong, as is the assertion of the signature associating the 184 reputation of the domain owner with the message instead of just a 185 signed message fragment. Most will assume a reference to "message" 186 implies the entire email message. This conflation appears in several 187 documents, including section 5.4 in [RFC5863]. 189 In essence, dismissing the phishing concern overlooks operational 190 strategies suggested in deployment documents where DKIM supplants 191 often problematic message filtering. Such likely use makes it 192 essential for DKIM validation to exclude messages containing 193 invalidly repeated header fields. This generalization is also used 194 in [RFC5863] which suggests messages having valid signatures from 195 trusted sources can be white-listed to avoid additional content 196 processing. Here again there is no mention of concerns related to 197 inclusion of pre-fixed header fields. Pre-fixed header field 198 concerns were not mentioned until section 8.15 in [RFC6376] was 199 added, but even then this section offers no mitigation strategy when 200 DKIM signatures ensure delivery by bypassing additional filtering. 201 Several email providers, including Yahoo, have implemented exactly 202 this strategy, delivering content straight to the in-box when a valid 203 and trusted DKIM signature is present in a message. 205 Barry Leiba's response [Leiba-Blog] to the assertion DKIM enables 206 phishing suggests the attack is overstated because: "1) It relies on 207 the sender's ability to get a DKIM signature on a phishing message, 208 and assumes the message will be treated as credible by the delivery 209 system. 2) It ignores the facts that delivery systems use other 210 factors in deciding how to handle incoming messages and that they 211 will downgrade the reputation score of a domain that's seen to sign 212 these sorts of things. 3) It ignores the fact that high-value 213 domains, with strong reputations, will not allow the attackers to use 214 them for signing. 4) The attack creates a message with two "from" 215 lines, and such messages are not valid. It ignores the fact that 216 delivery systems will take that into account as they score the 217 message and make their decisions." 219 Assertions about the phishing concern being overstated are wrong and 220 item 3 is irrelevant. As for item 1, sending yourself a message from 221 a high volume DKIM provider and then pre-fixing some header field and 222 relaying the modified message to any number of recipients is simple 223 and has a high probability of being accepted. As for item 2 and 4, 224 it is common for trust in a DKIM signature to cause message filtering 225 to be bypassed as suggested in [RFC5863]. As such, this assumes DKIM 226 validation checks for invalid header fields. Although such 227 validation is possible, seldom is the double listing of singleton 228 header fields ever used which also suggest this will not affect a 229 domain's signature rating. Having detection of invalidly repeated 230 header fields being optional places all other domains at risk. 232 Barry's response goes on to say: "Validity checking is an important 233 part of the analysis of incoming email, but it is a separate function 234 that's not a part of DKIM. All messages, whether DKIM is in use or 235 not, should be checked for being well-formed, and deviations from 236 'correct' form should increase the spam score of a message. That has 237 nothing to do with DKIM." 239 Barry's response is also logically incorrect. Undetected 240 introduction of pre-fixed header fields is not likely included in a 241 signature by a trusted domain. However, this trusted domain 242 signature is still likely to enable a message with pre-fixed header 243 fields to bypass content filtering as described by [RFC5863]. Since 244 DKIM MUST process the entire header field stack from top to bottom 245 and then bottom to top, failure to note when this stack does not meet 246 DKIM's input requirements and to then declare associated signatures 247 valid represents evidence of a negligent protocol that failed to 248 trivially validate its input. 250 Network architecture often assumes communication functions are 251 organized into nested levels of abstraction called protocol layers 252 with related meta-data organized in the same fashion. Rigid layering 253 is considered a desirable means to force compliance with existing 254 standards. In practice this requires careful review of overall 255 protocol operation. Suggesting that layering is inadequate may call 256 for an alternative organizational principle for protocol 257 functionality, especially with respect to a store-and-forward 258 transport. Meta-data being passed should not require resource 259 intensive operations to be needlessly repeated, as is the case with 260 the current DKIM specification. 262 Enforcing message structure compliance by a store-and-forward 263 transport is impractical. DKIM's aim is to achieve more 264 deterministic message acceptance through trust and less on Bayesian 265 processes. Not all errant structures are malicious, but use of DKIM 266 makes it imperative to ensure invalidly repeated header fields do not 267 produce valid signatures. This additional requirement imposed by 268 DKIM is necessary to prevent abuse of the alternative processing 269 enabled by DKIM. Optional double listing of these header fields will 270 not ensure some other domain permits inclusion of deceptive pre-fixed 271 header fields. It is also unreasonable to assume some other email 272 protocol layer will ensure message structure compliance just to 273 mitigate DKIM related abuse. This is a problem created by DKIM, that 274 DKIM itself should be prepared to handle to support its safe 275 incremental deployment. 277 3. Exploiting Trust 279 Trust established by a signing domain is being exploited to mislead 280 recipients about who authored messages. DKIM's trust related 281 function may be generalized as better ensuring delivery to in-boxes 282 as opposed to junk folder placement or silent discard. It is also 283 apparent receivers expect DKIM signature validation ensures invalid 284 header fields have not been pre-fixed. While it is possible for 285 signing domains to support this expectation by including non-existent 286 header fields in a list of header fields added to the signature's 287 hash, few implement this feature which offers a poor alternative for 288 the overlooked exclusion of invalidly repeated header fields. 290 Perhaps signers consider this double listing wasteful of storage 291 resources or they assume the validation process makes these checks 292 without this non-intuitive double listing of header fields that are 293 not permitted to repeat anyway. When a domain is very large, errant 294 filtering is likely to entail costly customer support which affords 295 this domain greater latitude and who are also likely sensitive to 296 wasting their storage resources. 298 Regardless of possible underlying motivations, it is clear checks for 299 valid header field message structure remains a general expectation of 300 DKIM's validation process. Although a valid header field check is 301 essential for ensuring a safe result, it simply does not occur in 302 most cases. Not every domain is seeking to establish the same level 303 of trust, where those not checking for pre-fixed header fields and 304 who have greater latitude place all other domains at risk. Checking 305 message structure is explicitly not to be handled by the transport. 306 Modification to SMTP implementations such as Sendmail, Exim, or 307 Postfix and the like are neither appropriate, nor likely beneficial 308 within a relevant time frame. 310 Larger domains often obtain their size by offering relatively easy 311 access. These domains afford malefactors a simple method to have 312 their deceptive messages reach their victim's in-box due to common 313 use exposing DKIM's vulnerability. DKIM's validation process does 314 not explicitly ensure against invalidly repeated header fields due to 315 the optional hash inclusion. This hashing allowance permits the 316 spoofing of other domains with pre-fixed header fields making DKIM 317 harmful by misleading recipients about who authored a message based 318 on acceptance established by a DKIM signature. DKIM validation MUST 319 be modified to ensure against invalidly repeated header fields to 320 ensure trust established by a signing domain is not exploited to 321 mislead recipients. 323 4. Maintaining Trust 325 Not every subsystem or protocol layer should be expected to repeat 326 previous security checks to establish proper layering, however 327 critical checks important for enforcing new relationships within a 328 message should not be assumed, especially those involving a trivial 329 effort. With high levels of abuse resulting from email's open 330 nature, delegating checks in a structured manner better conserves 331 essential resources. However, email's highly distributed store and 332 forward protocol could not function if rigid message structures were 333 enforced by the transport. Such enforcement does not scale and will 334 impede necessary change when new authentication or presentation 335 requirements involve small structural adjustments. For example, 336 internationalization introduced a format negotiation not assured to 337 survive beyond the next hop. 339 5. Responding to Defects and Exploitation 341 As with aviation, the success of email has risen to great heights. 342 As within the world of aviation, faults threatening security, that 343 when discovered, demand our attention and diligence to effect repair. 344 Email has become an integral component in general commerce and the 345 maintenance of security such as reporting system failures, break-in 346 attempts, and facilitating account access recovery. 348 Reporting or predicting failure should not be viewed as exhibiting a 349 lack of respect for achieved accomplishments. Noting and repairing 350 faults only signify the importance of email's prominent role. As 351 with most security related protocols, responding to noted defects is 352 fairly common. Not responding to discovered defects in a security 353 related protocol would be shocking. Simply publishing this draft 354 appears to have already increase the level of multiple FROM header 355 field abuse seen where it is now at 21% of signed DKIM messages. 357 6. Conflating DKIM Fragments with Email Messages 359 DKIM signs only fragments of an email message, so it is more proper 360 to refer to "DKIM Signed Fragments", and not "DKIM Signed Messages". 361 Normal DKIM signature validation offers a simple PASS/FAIL 362 associating it with a specific domain. When a recipient receives a 363 PASS status, only the last FROM header field message fragment is 364 ensured to have been included in the DKIM signature process. Other 365 message fragments, including the message body, are optional and may 366 not have been included. The FROM header field is normally visible 367 UNLESS there are multiple FROM header fields. In which case, the 368 signed FROM header field fragment is likely invisible, as is the DKIM 369 signature fragments that hide which other message fragments had been 370 encompassed by the DKIM signature process. 372 DKIM's trust related role is to better ensure message delivery to a 373 user's in-box. Unless DKIM ensures this trust is not used to 374 perpetrate deception, no positive assertions regarding a DKIM domain 375 is safe. As a result, DKIM can not be used with either positive or 376 negative reputation assertions in its current form. 378 The FROM header field is the Author identifier in section 11.1 of 379 [I-D.kucherawy-dmarc-base]. The DMARC specification offers normative 380 language that a message SHOULD be rejected when multiple FROM header 381 fields are detected. This requirement would not be necessary or 382 impose protocol layer violations if DKIM did not offer valid 383 signature results when repeated header fields violate [RFC5322]. 384 [RFC5322] declaring a message structure invalid will not preclude the 385 occurrence of invalid messages, and [RFC5321] clearly states it will 386 not enforce [RFC5322] message structure due to practical constraints. 387 Instead of relying on optional policies such as DMARC making partial 388 guesses that ignore DATE or SUBJECT spoofing for example, critical 389 violations of the message header field structure that pertain to 390 enhanced trust can be protected by DKIM simply defining any 391 associated signatures invalid. Unlike DMARC, proper signature 392 definition does not cross protocol layers, especially since no other 393 layer enforces [RFC5322] and no other layer determines the validity 394 of a DKIM signature. 396 Since multiple DKIM signatures can occur, simple annotation of which 397 fragments and domains associate with a valid signature is precluded. 398 The ONLY message fragment ensured by a DKIM signature is the FROM 399 header field. Just as DMARC concluded only the FROM header field is 400 closely observed by recipients, DKIM initially reached this 401 conclusion as well. While no absolute assurance of header field 402 validity is asserted, the domain together with it's reputation 403 permits recipients to increase their trust in what is observed in the 404 FROM header field. This trust further increases when the DKIM domain 405 is authoritative for the FROM header field domain. 407 When acceptance is predicated on the DKIM signature, as occurs with 408 DMARC, preserving trust associated with the FROM header field in 409 conjunction with the DKIM domain is destroyed whenever multiple FROM 410 header fields are permitted by not invalidating these DKIM 411 signatures. DMARC over reaches when rejecting email based upon 412 message format as with [RFC6854] group syntax in the FROM header 413 field. DMARC should not be required to second guess whether a DKIM 414 signature can be safely considered valid. 416 7. SMTP Can't 418 SMTP [RFC5321] recommends against rejecting messages based upon 419 perceived defects in the message structure. This liberal acceptance 420 permits evolutionary change in message specifications starting at 421 [RFC0822] that was based on [RFC0733] replaced by [RFC2822] and again 422 by [RFC5322], [RFC6152], [RFC6532], and [RFC6854]; the second to last 423 paragraph in section 3 of [RFC5321] provides a definitive statement 424 messages should not be rejected due to perceived defects in the 425 [RFC0822] message structure. The initial reference to [RFC0822] in 426 this paragraph offers two foot notes with the second referencing the 427 latest version of [RFC0822] which is [RFC5322] which itself has 428 recently been updated. The impact of initially removing text 429 specifically indicating which header fields are not to repeat is 430 unknown. This information was implied within the then-new ABNF 431 notation. Clarifying text for this requirement did not return until 432 the [RFC0822] revision 19 years later which also indicates this 433 specification's success at providing a foundation that allowed email 434 to flourish. 436 There are many SMTP servers that have been in operation for decades 437 with years passing between security patches. Such an accomplishment 438 is most remarkable considering the volume of traffic being handled, 439 often from highly malicious sources. This amazing stability and 440 scalability with high levels of security would not have been possible 441 if SMTP had been expected to validate message formats. 443 Expecting SMTP to validate message formats to protect against 444 vulnerabilities pertaining to protocols such as DKIM does not scale. 445 The general use of DKIM permits signature checks subsequent to 446 acceptance where only the status of signatures determines internal 447 placement. As such, it becomes critical to ensure a DKIM signature 448 is never declared valid having malformed header field stacks. To 449 accomplish this, the DKIM specification must change. 451 8. DKIM Vulnerability 453 DKIM permits a vulnerability by not checking the message header field 454 stack for invalid repeats when signing or verifying a signature. The 455 DKIM signature process must walk both down and then up the header 456 field stack while selecting the header fields to be included in the 457 hash process of the signature. The DKIM process will even ignore 458 prefixed FROM header fields which is the only header field always 459 included. 461 The WG concluded that "listing non-existent header fields as signed" 462 hack added in non-normative language together with opinions that 463 checking for invalidly repeated header fields is not to be considered 464 DKIM's problem. See section 8.15 of [RFC6376] where this issue was 465 expressed as not an attack against the trust DKIM intends to convey, 466 and thus not a concern for DKIM. Nevertheless, improperly formed 467 messages may display only the first of multiple header fields that, 468 as a result of erroneous assumptions of there being no invalidly 469 repeated header fields, the prefixed header fields are likely to be 470 displayed in lieu of those signed while not impacting DKIM's 471 signature validity. 473 DKIM incorrectly assumed the header field stack's starting condition, 474 which DKIM itself is best able to determine, and is an option in the 475 OpenDKIM implementation. This is likely to astonish most recipients 476 that DKIM failed to make a robust effort to maintain the trust it is 477 attempting to convey. Three members of the WG authored proposed 478 changes aimed specifically at addressing this issue [DKIM-MH-Attack]. 479 At the time, some expressed concerns about whether this might set 480 back DKIM's standardization process. As such, DKIM Signers may sign 481 malformed messages (e.g., violate [RFC5322]) and be in compliance 482 with DKIM specifications. In addition, receivers may verify these 483 messages as having valid signatures despite multiple instances of a 484 header field only permitted to occur once and also be in compliance 485 with DKIM specifications. See addendum for examples of the possible 486 abuse this permits. 488 Use of DKIM on such messages exposes a vulnerability in the 489 evaluation process. Rather than ensuring essential checks are made 490 prior to producing a result, a wasteful hack was later suggested 491 where extra non-existent header fields could be included in the list 492 of signed header fields. Any pre-pended header field added after 493 signing would thereby change resulting hashes and invalidate the 494 signature. Not all domains are attempting to achieve the same level 495 of trust and may be more sensitive to incurring incremental storage 496 requirements. Some domains may even inadvertently sign invalidly 497 repeated header fields because this check had not been required in 498 the DKIM process. These same DKIM domains are also likely to 499 establish themselves as being Too Big To Block. These TBTB domains 500 can then be used to spoof other domains that may have otherwise 501 established a high level of trust by implementing the hack where, due 502 to this defect in DKIM, can still do nothing in their defense from 503 the perspective of now deceived recipients. 505 This vulnerability in DKIM represents an exploit allowing serious 506 attacks caused by erroneous assumptions made in DKIM's signature 507 process. There is also a header field, which because of its label, 508 may potentially mislead recipients into believing it contains valid 509 "Authentication-Results" [RFC5451]. Common phrases such as 510 "Authentication-Results", "pass", and "fail", rather than use of 511 result codes belies introductory claims this header is not intended 512 for direct human consumption. 514 9. Barriers to an Authenticated Domain 516 Some advocate use of DKIM as a means to obtain domain references 517 based on the increased prevalence of this protocol. DKIM is 518 independent of the domain actually sending the message and the 519 recipient by design. Unfortunately, DKIM also does not attempt to 520 protect against likely abuses that are also beyond the control of the 521 signing domain in which DKIM signature validity conveys no assurance 522 pre-fixed header fields have not changed what recipients see. As 523 such, DKIM signing domains can not be held accountable for incidents 524 of abuse appearing to violate subscription policies or that spoof 525 other domains. 527 Because of DKIM's vulnerability to header field spoofing, it would 528 not be safe to express positive reputations either. Any such 529 assurance could be exploited by malefactors to deceive those trusting 530 DKIM results. In short, a DKIM signed domain as currently defined, 531 can not be safely used in any context, other than the most rigid 532 exclusion of any unsigned content which is well beyond any existing 533 implementation. DKIM can not be safely used for email reputation as 534 currently defined. 536 10. Domains as a Basis for Managing Traffic 538 A manageable basis for assessments can leverage a smaller number of 539 related domains, compared to IPv6 or even IPv4 addresses. Although 540 technically the domain name space can be larger than the massively 541 large IPv6 address space, in practice it is not. One hundred 542 thousand domains control 90% of Internet traffic out of approximately 543 100 million domains active each month. The top 150 domains control 544 50% of the traffic, and the top 2,500 domains control 75%. This 545 level of domain consolidation permits effective fast-path white- 546 listing. Improvements achieved using domains to consolidate the 547 threat landscape can easily justify added cryptographic 548 authentication burdens. Even APL resource records [RFC3123] can 549 authenticate EHLO using a single DNS transaction, but this would not 550 allow IPv6 email to be more easily managed when facing extensive use 551 of transitional technologies such as ISATAP, Teredo, 6to4, NAT64, and 552 DNS64, as well as the solutions offered by cryptographic technology. 554 11. XMPP Shows the Way Forward 556 In addition to SMTP [RFC5321] using StartTLS [RFC3207], XMPP 557 [RFC6122] uses StartTLS [RFC6120] over a different port with many of 558 the features used by web servers such as [RFC2560] as one means to 559 increase scalability. It seems plausible that by defining SMTP 560 access over a different port is where a new authentication and 561 international requirements can be resolved together. Of course, port 562 25 can be used where it might require StartTLS in the case of IPv6 563 connections. 565 Many administrators overlook a serious problem made much worse by 566 chatty protocols that impose processing delays. Examining server 567 logs will not reveal any problem either, because the limited resource 568 being consumed is the number of outstanding connections TCP is able 569 to support. Reaching this limit will prevent new connections from 570 being instantiated but this is not logged as an event. Over time 571 administrators may hear complaints email is not being delivered or 572 just see an ever growing percentage of spam. 574 12. IANA Considerations 576 This document requires no IANA consideration. 578 13. Security Considerations 580 This draft intends to describe serious security concerns raised with 581 use of DKIM that is exacerbated with IPv6 email. The contained 582 recommendations are expected to reduce these security concerns. To 583 better ensure security, the DKIM specification must change. 585 Recommendations [DKIM-MH-Attack] rejected by the DKIM WG were aimed 586 at repairing this defect by simply requiring the definition for a 587 valid DKIM signature to ensure no invalidly repeated header fields 588 are present. It is also clear that the non-normative language 589 describing the non-intuitive approach of listing non-existent header 590 fields has not been widely embraced, especially by domains sensitive 591 to storage requirements. The overall storage requirement was one of 592 the weighing factors in selecting between IIM and DKIM. IIM's 593 inclusion of the public key within the message was considered an 594 unnecessary waste of storage. It seems many also consider the 595 prophylactic listing of non-existent header fields an unnecessary 596 waste as well. Based upon the current data, the present DKIM 597 specification did not result in something that can retain trust, and 598 that leads to protocol layer violations as seen with DMARC. 600 Section 8.15 of [RFC6376] states: "It is up to the Identity Assessor 601 or some other subsequent agent to act on such messages as needed, 602 such as degrading the trust of the message (or, indeed, of the 603 Signer), warning the recipient, or even refusing delivery." Despite 604 DKIM ignoring critical aspects essential for retaining trust, DKIM 605 now suggests this is to be fixed by some undefined process. Since 606 virtually all DKIM domains will not employ prophylactic double 607 listing of signed header fields, an Identity Assessor is neither a 608 timely nor reasonable remedy either. To be absolutely clear, the 609 DKIM specification must change to ensure valid signatures do not 610 include invalidly repeated header fields. 612 14. Acknowledgements 614 The authors wish to acknowledge valuable contributions from the 615 following: Dave Crocker, and Barry Leiba. 617 15. References - Informative 619 [Crocker-Blog] 620 http://www.circleid.com/posts/ 621 searching_under_lampposts_with_dkim/, "Searching under 622 lampposts with DKIM", June 2011. 624 [DKIM-MH-Attack] 625 http://trac.tools.ietf.org/wg/dkim/trac/ticket/24, 626 "Multiple-header-attack alternative proposal", April 2011. 628 [I-D.ietf-repute-email-identifiers] 629 Borenstein, N. and M. Kucherawy, "A Reputation Response 630 Set for Email Identifiers", 631 draft-ietf-repute-email-identifiers-08 (work in progress), 632 June 2013. 634 [I-D.kucherawy-dmarc-base] 635 Kucherawy, M., "Domain-based Message Authentication, 636 Reporting and Conformance (DMARC)", 637 draft-kucherawy-dmarc-base-00 (work in progress), 638 March 2013. 640 [Leiba-Blog] 641 http://staringatemptypages.blogspot.com/2011/06/ 642 misconceptions-about-dkim.html, "Misconceptions about 643 DKIM", June 2011. 645 [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 646 "Standard for the format of ARPA network text messages", 647 RFC 733, November 1977. 649 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 650 text messages", STD 11, RFC 822, August 1982. 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, March 1997. 655 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 656 (IPv6) Specification", RFC 2460, December 1998. 658 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 659 Adams, "X.509 Internet Public Key Infrastructure Online 660 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 662 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 663 April 2001. 665 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 666 (APL RR)", RFC 3123, June 2001. 668 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 669 Transport Layer Security", RFC 3207, February 2002. 671 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 672 Architecture", RFC 4291, February 2006. 674 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 675 for Authorizing Use of Domains in E-Mail, Version 1", 676 RFC 4408, April 2006. 678 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 679 Extensions for Stateless Address Autoconfiguration in 680 IPv6", RFC 4941, September 2007. 682 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 683 for Authentication", RFC 4954, July 2007. 685 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 686 October 2008. 688 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 689 October 2008. 691 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 692 Message Authentication Status", RFC 5451, April 2009. 694 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 695 "DomainKeys Identified Mail (DKIM) Development, 696 Deployment, and Operations", RFC 5863, May 2010. 698 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 699 Protocol (XMPP): Core", RFC 6120, March 2011. 701 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 702 Protocol (XMPP): Address Format", RFC 6122, March 2011. 704 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP 705 Service Extension for 8-bit MIME Transport", STD 71, 706 RFC 6152, March 2011. 708 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 709 Identified Mail (DKIM) Signatures", RFC 6376, 710 September 2011. 712 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 713 Email Headers", RFC 6532, February 2012. 715 [RFC6854] Leiba, B., "Update to Internet Message Format to Allow 716 Group Syntax in the "From:" and "Sender:" Header Fields", 717 RFC 6854, March 2013. 719 [TM-Blog] http://blog.trendmicro.com/ 720 trendlabs-security-intelligence/ 721 possible-phishing-with-dkim/, "Possible Phishing with 722 DKIM", June 2011. 724 [v6-BGP-Rpts] 725 http://bgp.potaroo.net/v6/as6447/, "BGP Routing Table 726 Analysis Reports/IPv6/AS6447 views", May 2013. 728 Appendix A. DKIM Examples 730 From Random User Tue Mar 12 12:07:37 2013 731 X-Apparently-To: just4spamdlr@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:08:37 -0700 732 Return-Path: 733 Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com) 734 A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ-- 735 X-YMailISG: Po8J_9cWLDuz5QIo_tChc7OagZYPBIscsK7APx8FMj835hEX 736 clyJxoQr6Ojy40ccEugqmkym_ayJu65fKm.KJY73k6aprxb9s7Bj6P32lpml 737 6yGzxWFYdNXCwcxHtFGdhKe3v7Tjh8x051jkxjIqfuS0vo8J5rZOr.Z__6vD 738 4wiGFDUwFHNUWAwuz_pwp7pZ5HCivuuuyszYVvH0eIFsrQ9crR.rrk_3EQU2 739 Xkv_fInlGDFR8fafFPMOgQ7QOrHhy0zQUbptDEFGdh1QVOyLwIpjwEC7264k 740 4MqxUH7zz_M5JOQzj6dJslH0.iz5y9Sgp6y6kTUHAVP2f_t1hMeRvf3F7WJ6 741 1yY2rZJALIME1CtiNKQJoDctzgGFRnh_5mo415MvUcEIH7qqS5RFgWtXEQpd 742 JIpyYlECDXVUcuASoLmzbuGSiCEVLq7f4EiBTAsaMwXJ07OgXBR.QYDw3VfA 743 Z0AcfnFrUVHNLZtLaFukQKzdk9c6SpHFHSuCAsvLPuZeRy4Ij5ndXd7viyCS 744 IkAHsnhG_u3.nZr3zUDFOrqw8sEKphobj6ZJ8KEXtuhr_tx.94abE1JRJYi5 745 fukj2h8y9s.K10ZxoTClaw41_DD8fxESbyfyTRPytiEXUdK1WEjgS3rAZ0TA 746 WPJPDr063xLYk20UY0V.N5J15lBCtqZcde_9pdXwxVySyXo1KEQOaH3TNRBZ 747 AKMFuCC7NF56aklkiUgk2EWm8iYoHsFez5_HtOz1zmc1dv4mNFOPTaNrXF2X 748 qjFiwfdUipupIlAEc6pIdv0_le.xvz1jnaewEOyxo4dKd2XLVvybLfsLY16U 749 FzLS9MJJ1wC0Cmf3G2SbOmT4ZiAvPjyv8QnHzbSDDDy3hqg8F0uEE03sJ5dm 750 on5FxOHZZ1wCH7DL1QAXpZYxYWKV.h3q69dKQMl6HbnmfT_WZQY4X8uKXqkZ 751 o34v.YmvJxHSRCSmhFpug1EstpJ4gHVitl_eJzT_n6xYQwhNAuMZ9uRjN2xE 752 1Lf7NpgzRf9bFvOpJAlyLoK5Xvxbx711cMgEUfGIha_JtL1P7hyfncRszHDv 753 txgUYzcsVvRyAyVvwDAM.TEBsFhAtqqwOibqo2l5xCBj2yXRbKJ0EOC1JDMs 754 HA-- 755 X-Originating-IP: [192.83.249.65] 756 Authentication-Results: mta1225.mail.bf1.yahoo.com from=gmail.com; domainkeys=neutral (no sig); 757 from=gmail.com; dkim=pass (ok) 758 Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65) 759 by mta1225.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:08:36 -0700 760 Received: by rdaver.bungi.com 761 via smail with stdio 762 id 763 for Just4spamdlr@yahoo.com; Tue, 12 Mar 2013 12:08:33 -0700 (PDT) 764 (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5) 765 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 766 d=gmail.com; s=20120113; 767 h=mime-version:x-received:date:message-id:subject:from:to 768 :content-type; 769 bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=; 770 b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL 771 AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ 772 PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3 773 GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh 774 JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e 775 yJqA== 777 MIME-Version: 1.0 778 X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152; 779 Tue, 12 Mar 2013 12:07:37 -0700 (PDT) 780 Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT) 781 Date: Tue, 12 Mar 2013 09:07:37 -1000 782 Message-ID: 783 Subject: An example signed message 784 From: Random User 785 To: just4spamdlr@yahoo.com 786 Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff 787 Content-Length: 280 789 reporting valid signature 791 From Fake User Tue Mar 12 12:07:37 2013 792 X-Apparently-To: just4spamdlr@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:09:01 -0700 793 Return-Path: 794 Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com) 795 A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ-- 796 X-YMailISG: gFqc.ysWLDtqkdjDpSCH39uGWhgFfnsGdWobzNb5os6sP0We 797 _L38eAdX.VKZWQ2F75gFwoipcPyj4g0uKMm_vSayLjrnps9lBxMGLvtTE8kT 798 XYxIw6vZb4aFZ_jEcpoRntvJDkZQl4XSGWGakfmJ5G2blTWZ_i1BVkBvj0Sv 799 jEymvhoIXZTb_l8C0Jh69ot3MgrNBvjhrBmhCK3sziUtDPpKQPJb_lxCnYKN 800 O0SiArQ_TUXrCRFRNsyEiJxzVfSgJWIdsCV5BN3cp..NZ17X8fguB.YxNQjt 801 qjVcGMd4IjQioY.a4f1luQxuiCN1yWvYqiLpP6eOCQhMrHt9XOdk32HAXNuJ 802 GBraVtjrySTl9Db7PpRC46wlMs3iIUHl3z0d4o6293sMA5qFmnbczGoLRGFs 803 RUVlBJuRoJCSYZh5LOwbj0RPQNX2Nmw.LHwF7SY3XcZWFUjvUQQ2sdx63m_J 804 Mgy7JHAwBTVH6ytULsbXvu38a5GIYHccfNnDKVjtsrIg9qBDpVASHrRkncL0 805 MFLy5FHLb_XBW1TPztCFtlRViKr_HFxMob6aZIte6T57AMqlV2YAHwVNObwx 806 WE8ZWTkKNWbXqJYytd3vyuyAHfuseBFP_Jfmj0zVtg52EXpIlDiTANEOTamP 807 zeu23QbeRWJd_Gpz9bbGw_OorPdcV.WJOQ29DHpiYAQRgWjJNLjkd8dI.vuM 808 vs1Fr7LOiE3wRpSU5AW_hrR4anvGrnwSPOQaFmpNE0pl8n.Vomrp.5NU8cgU 809 QYI1UCSPoE_HK5Som2HMPYZFQv0pJSu1NeitXlRM3DHkIMvW4aVYqrHSNVjl 810 gGCFFx77c25QW.XAGtySBYWcTzcUlHP4fMa7Wli4u06C4N3pDPiQoXKOC10U 811 koXUMKFYmedaZYvEeQRPO3_8xHwKyZ.QInDsnQRwPFWYKvcWCJu4c5zxDMG4 812 h1AsyT3CM80nZXk8.ZGhzfTgo810Xjn_OJVgUfkG1z3..ReN990deaWJY8F5 813 _j6lRWLZZRzCMwOGpJ6I.jgaN5mNk38Kj6.NYLFCpMTEIt28jIRHD85cfpa3 814 iOL3drg1TIKQWrEhS9u3H29niQ_hjHbk7ys6uSJvowilRwO8eB2s.Wz0 815 X-Originating-IP: [192.83.249.65] 816 Authentication-Results: mta1266.mail.bf1.yahoo.com 817 from=gmail.com; domainkeys=neutral (no sig); 818 from=gmail.com; dkim=pass (ok) 819 Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65) 820 by mta1266.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:09:00 -0700 821 Received: by rdaver.bungi.com 822 via smail with stdio 823 id 824 for Just4spamdlr@yahoo.com; Tue, 12 Mar 2013 12:09:00 -0700 (PDT) 825 (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5) 826 From: Fake User 827 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 828 d=gmail.com; s=20120113; 829 h=mime-version:x-received:date:message-id:subject:from:to 830 :content-type; 831 bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=; 832 b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL 833 AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ 834 PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3 835 GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh 836 JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e 837 yJqA== 838 MIME-Version: 1.0 839 X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152; 840 Tue, 12 Mar 2013 12:07:37 -0700 (PDT) 841 Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT) 842 Date: Tue, 12 Mar 2013 09:07:37 -1000 843 Message-ID: 844 Subject: An example signed message 845 From: Random User 846 To: just4spamdlr@yahoo.com 847 Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff 848 Content-Length: 280 850 spoofed DKIM with valid signature 852 Appendix B. Stats 854 DKIM total: 5063 855 DKIM pass: 4354 856 DKIM fail: 709 857 DKIM pass w/multiple from: 916 (about 21% on average) 858 An increase appears concurrent with the publication of this draft. 859 More data will be made available subsequently. 861 Looking at roughly a few hours of spam 863 Authors' Addresses 865 Douglas Otis 866 Trend Micro 867 10101 N. De Anza Blvd 868 Cupertino, CA 95014 869 USA 871 Phone: +1.408.257-1500 872 Email: doug_otis@trendmicro.com 874 Dave Rand 875 Trend Micro 876 10101 N. De Anza Blvd 877 Cupertino, CA 95014 878 USA 880 Phone: +1.408.257-1500 881 Email: dave_rand@trendmicro.com