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