These guys think so--------- In a recently concluded discussion by the Domain Keys Identified Mail (DKIM) Working Group, a group created under the Internet Engineering Tasks Force (IETF), some of those involved have decided to disregard phishing-related threats common in today’s effective social engineering attacks. Rather than validating DKIM’s input and not relying upon specialized handling of DKIM results, some members deemed it a protocol layer violation to examine elements that may result in highly deceptive messages when accepted on the basis of DKIM signatures. The details are simple and the original goals were good. DKIM was intended to authenticate domain relationships with an email message bound at a minimum to that of the From header field. The relationship was to provide a basis for message acceptance but failed to offer the intended protections whenever a message contains invalid or fake elements still considered to offer a valid signature. While it would not be a protocol violation to declare such messages with invalid or fake elements to not have a valid signature, there are some who think otherwise. Here is how DKIM can be exploited: 1. Obtain a free DKIM signed email account. 2. Send yourself a message of a sensitive nature. Perhaps it could be about a job offer related to an online social network seeking the eventual recipient’s resume. 3. Prepend any dummy From header field ignored by DKIM to mislead recipients with regard to the message’s origin. Certainly, the message may include a Web link offering additional details. This Web link may attempt some zero-day exploit or request additional personal details such as the recipient’s social networking page to escalate additional attacks. 4. Exploiting DKIM’s replay insensitivity, a malefactor can then resend the message as a mailing list to their intended victims where it will have a valid signature with a From header purporting to being from any email address a malefactor desires. The overhead related to DKIM’s cryptographically based authentication dwarfs the effort of NOT ignoring the presence of multiple From header fields. While SMTP still permits RFC822-compliant messages, DKIM was based on RFC5322, which stipulates the legal number of specific header fields. DKIM should also ensure against the use of fake A-Labels when it changed from using RFC3490 to using RFC5890. RFC5890 defines an additional 3,329 code-points as being illegal and now allows the German esset and the Greek final sigma when string prep was removed. Unfortunately, DKIM makes no effort to ensure the legitimacy of critical header fields nor the domain used to reference the public key confirming the DKIM signature. The decision to ignore additional From header fields prepended to an email and yet still return a valid signature result (the only output of DKIM) makes this an EVIL protocol. Evil because once recipients think they can now trust From header fields being displayed but the protocol has decided to ignore or pass over multiple From header fields while checking the signature places recipients at even greater peril. As quoted by Spam Resource---------- "Problem is, this hack supposedly exploits a "potential hole" that is not even open, by most measures. This involves taking a legitimate message and adding another from address to that message, fooling recipients into perhaps looking at, and believing, the wrong from header. Problem is, an email message with multiple from addresses is already prohibited under the current SMTP specification (which is currently RFC5322, a descendant of RFC822). Messages composed in this manner are already heavily filtered and not trusted. It really has little to do with DKIM or email authentication. Not only is this much ado about nothing, but I believe that Trend Micro's unwarranted hyperbole on the topic is harmful. And I'm not the only one who thinks so. Software engineer Barry Leiba calls Trend Micro's warning "severely flawed," "laughable," and "ridiculous." Dave Crocker, the author of RFC822, many other RFCs, and longtime participant in multiple anti-abuse and standards track forums and organization, agrees. He says that "the blog's description of the facts, its premise about the requirements, and its apparent understanding of DKIM's functionality all suffer from basic flaws." http://www.spamresource.com/
