8.15. Attacks Involving Extra Header Fields ... ,--- Agents that evaluate or apply DKIM output need to be aware that a DKIM signer can sign messages that are malformed (e.g., violate [RFC5322], such as by having multiple instances of a field that is only permitted once), or that become malformed in transit, or that contain header or body content that is not true or valid. Use of DKIM on such messages might constitute an attack against a receiver, especially where additional credence is given to a signed message without adequate evaluation of the signer.
These can represent serious attacks, but they have nothing to do with DKIM; they are attacks on the recipient, or on the wrongly identified author. '--- This IS an attack on DKIM! Acceptance, annotations, or sorting based upon DKIM results that fail to exclude invalid pre-pended header fields represent a threat NOT corrected by ANY reputation assessment for most DKIM signing domains! A malefactor that obtains a DKIM signed message can ABUSE a signing domain by creating a phishing message through use of pre-pended header fields whenever invalid pre-pended header fields are inappropriately neglected by the DKIM verification process and are not precluded by the little used and wasteful double tagging. ,--- Moreover, an agent would be incorrect to infer that all instances of a header field are signed just because one is. '--- This incorrectly describes the problem! It is incorrect to infer the bottom instance of a header field is the ONLY field that matters with respect to protecting the integrity of a signing domain when verification ignores invalid pre-pended header fields. Both signing and verification can be attacked whenever invalid header fields are neglected. ,--- A genuine signature from the domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the signer list the field name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This in essence is an explicit indication that the signer repudiates responsibility for such a malformed message. '--- A high volume domain may sign harmless messages composed by one of their users. This domain may also ensure the From header field accurately reflects the assigned address of the Author. However, a DKIM message can be replayed and then sent anywhere. High volume domains are not normally targets of phishing attacks and seldom employ the new and dubious 'h=' double tagging of header fields. The double tagging strategy remains dubious when any domain is considered acceptable that does not impose the new double tagging strategy. In that case, all domains remain at risk of being phished. Even domains that use ADSP and impose double tagging! ,--- DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the "d=" value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a problematic message. It is up to the identity assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the signer), or by warning the recipient, or even refusing delivery. '---- Unless invalid pre-pended header fields are NOT ignored by the verification process, DKIM will prove deceptive. Especially when MUAs are not DKIM aware. When SMTP acceptance or annotations are based upon reputation assessments of valid DKIM signature results, no protection for recipients or signing domains can be offered when invalid pre-pended header fields are ignored during verification. ,--- All components of the mail system that perform loose enforcement of other mail standards will need to revisit that posture when incorporating DKIM, especially when considering matters of potential attacks such as those described. '--- As indicated in DKIM's introduction, other email components are not expected to change for safe incremental deployment of DKIM. As such, DKIM MUST stand on its own. For a correction that addresses this issue see: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html