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: accounts(_at_)big-trader(_dot_)com //bogus header appended to a replayed
message
From: mallory(_at_)toobigtoblock(_dot_)com
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: "mallory(_at_)toobigtoblock(_dot_)com" and
not
"accounts(_at_)big-trader(_dot_)com". 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