On 6/23/11 5:16 AM, Ian Eiloart wrote:
On 21 Jun 2011, at 19:47, Douglas Otis wrote:
Hi Rolf,
The general goal of DKIM was to establish a domain relationship as
a trust basis for acceptance. DKIM was also to allow incremental
deployment without requiring undefined additional filtering
performed by mail transfer or mail user agents. When essential
format checks are skipped, this deficiency allows acceptance based
upon DKIM's domain to be potentially deceptive where its results
may play an evil role that cannot be repaired through the use of
reputation.
Free email providers likely use DKIM to take advantage of their
"too big to block" volumes. For these domains, their reputation is
understood to offer little assurance of their overall integrity. By
allowing a pre-pended From header field to not affect the validity
of a DKIM signature according to the specification means the
UNDERSTOOD source of a message can NEVER be trusted.
Those that phish by taking advantage of this flaw are unlikely to
affect the acceptance of any exploited high volume domain. DKIM
could have avoided the offering of false assurances by not ignoring
illegal header fields per RFC5322 and defining such messages as
resulting in invalid signatures. At this time, it would be prudent
to NOT recommend use of DKIM due to this and a lack of required
Fake A-label detection.
This seems like a completely bogus argument to me. You're saying that
some domains can't be trusted, therefore none can be trusted. That's
a logical fallacy.
Not at all. Acceptance policies and results for DKIM MUST align with
what is being displayed in the message. Otherwise malefactors may be
able to exploit open and large volume domain's signatures and their lack
of duplicates in the signed header list (which most don't do). The
pre-pended header fields could then be that of any high value domain.
These messages might have been accepted on the false premise of being
from a high volume domain when based upon valid DKIM signature indications.
Dave and Murray have made some strange arguments about whether DKIM
should ensure valid signatures not contain multiple From header fields
and then say such checks are some other undefined protocol's burden.
There is a significant difference between SHOULD and MUST. Using
the term SHOULD in regard to generic message format compliance (which
only recommends compliance per RFC2119) does not clarify whether there
are cases where it would be okay for valid signatures to contain
multiple From header fields. Would insistence that a different protocol
make these checks be a good reason to ignore their occurrences?
From: Accounts Manager <big-bank.com> (displayed and not signed)
DKIM-Signature: h=from,subject,date, d=free-email-provider.com ...
Subject: Please review your account status immediately
From: someone(_at_)free-email-provider(_dot_)com (not displayed but signed)
...
<html content>
<corporate logos>
You can review your account at <bogus-link>.
</html content>
Even if big-bank.com were to use multiple headers in their 'h=' list,
the evaluation of the signature would be based upon that of
free-email-provider.com which only lists single headers.
Dave also insists rfc822 prohibited the use of multiple From headers,
but it only states multiple headers are discouraged. Explicit
limitations expressed using ABNF syntax does not occur until rfc2822,
some 19 years later. Not to fault Dave who was only the author. It was
a different era where rfc822 was a substantial accomplishment having a
primary goal of facilitating gateway translations that often mandated
only minimums.
As it is now, one can not expect SMTP will reject messages that violate
rfc5322, although that is what appears to DKIM expect. Unless someone
can give examples were it would be okay to have multiple From header
fields within a valid DKIM signed message, it would be much safer to
have the DKIM specification stipulate the singular requirement as a MUST.
Sure, gmail.com can't be trusted because they'll sign even spoofed
emails. So, my server won't be configured to give a pass to emails
signed by gmail.com However, that doesn't mean that I can't be more
lenient with respect to emails signed by, for example, subdomains of
.gov.uk, which might well be better managed.
What if free-email-provider.com ensures their signed From headers
contain their domain or one confirmed using a ping-back? Do you
understand the nature of the concern?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html