Although DKIM is reviewed within IETF's security area, input validation by DKIM remains dangerously neglected. DKIM's Introduction indicates it can be implemented independent of clients. As such, few assumptions are safe in how users become aware of DKIM's intended protections or acceptance policies.
The Security Considerations Section 9.14. Attacks Involving Addition of Header Fields states: ,--- To resist this specific attack the signed header field list can include an additional reference for each field that was present at signing. For example, a proper message with one From: field could be signed using "h=From:From:..." Due to the way header fields are canonicalized for input to the hash function, the extra field references will prevent instances of the cited fields from being added after signing, as doing so would render the signature invalid. '--- Double listing in the "h=" tag can not fully mitigate risks related to appended header fields when messages are signed by a different domain than the domain found in the appended From header field. Users may depend upon their employer's or their provider's policies using methods similar to those used with ADSP which requires Author Domain Signatures. Whether policies result from a domain publishing ADSP records or through private arrangements, these policies may still be circumvented with appended header fields. For example: From: [email protected] //bogus header appended to a replayed message From: [email protected] dkim-signature: d=toobigtoblock.com... //valid signature likely accepted subject: Your account may have been compromised. More information regarding this problem is available at: http://example.com/malware.exe This message will appear properly signed by "toobigtoblock.com" when policy adopting DKIM header field conventions are based upon the first signed From header field containing: "[email protected]" and not "[email protected]". In this case "toobigtoblock.com" may not care about appended From header fields and thereby expose big-trader.com to being spoofed. Users may see what appears to be properly signed messages that appear to be from big-trader.com and might even be sorted into the same folder as messages actually signed by big-trader.com. Goals stated in DKIM's Introduction are only met when few assumptions are made about how users become aware of DKIM results. To prevent appended header fields from being trivially deceptive regardless which domain signed the message, modify section 4.5. "The DKIM-Signature Header Field" below the paragraph defining the "h=" tag by adding: ,--- Always treat the "h=" tag of "from" as having been listed twice. '--- This change removes reliance on third-party signing domains to also provide "h=" lists protecting against deceptive appended From header fields. The From header is the only field that must be signed and only one is valid per RFC5322. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
