Background on preceding DKIM work--
RFC4686 Introduction states:
,---
The DKIM protocol defines a mechanism by which email messages can be
cryptographically signed, permitting a signing domain to claim
responsibility for the use of a given email address.
'---
While several threats to DKIM were considered, multiple From header
fields were neglected. This document only focused on use of multiple
addresses within the From header field.
RFC5585 Introduction states:
,---
DKIM allows an organization to take responsibility for a message in a
way that can be verified by a recipient. [..] It permits verification of
the signer of a message, as well as the integrity of its contents. DKIM
will also provide a mechanism that permits potential email signers to
publish information about their email signing practices; this will
permit email receivers to make additional assessments of unsigned
messages. DKIM's authentication of email identity can assist in the
global control of "spam" and "phishing".
'---
It should be noted that Signing Practices are referenced off a domain
found in the From header field which also assumes only one will be present.
RFC2119 definition
,---
SHOULD
This word, or the adjective "RECOMMENDED", mean that there
may exist _valid_ reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
'___
Section 3.8 Input Requirements states that verifiers SHOULD take
reasonable steps to ensure that the messages they are processing are
valid according to RFC5322, RFC2045, and any other relevant message
format standard.
Section 8.14 Attacks Involving Addition of Header Fields
acknowledges:
,---
Many email implementations do not enforce [RFC5322] with strictness as
discussed in Section 5.3 (Normalize the Message to Prevent Transport
Conversions), DKIM processing is predicated on a valid
mail message as its input. However, DKIM implementers should be aware
of the potential effect of having loose enforcement by email components
interacting with DKIM modules.
'___
and further states:
,---
An MUA then might elect to render to the user the
value of the first, or "top", From: field. This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result. Such code in an MUA can
be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters. Such is
the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated. (This can also be taken as a
demonstration that DKIM is not designed to support author
validation.)
'___
This indicates the DKIM specification is seriously flawed. While DKIM
may not offer author validation, it was intended to establish an
accountable domain for the signed message content that at a minimum
includes the From header field. There are NO valid reasons for a valid
signature to include multiple From header fields! Allowing multiple
From header fields is _EVIL_ and destroys DKIM's intended purpose as
defined by prior work.
Free email providers likely use DKIM to gain increased acceptance by
taking advantage of their "too big to block" volumes. For these
domains, their reputation is understood to offer little assurance of
their overall integrity while perhaps limiting what is allowed in the
domain portion of the From header field.
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 through the aid of DKIM.
Those that phish by taking advantage of this neglected flaw are unlikely
to affect the acceptance of any exploited high volume domain. DKIM
could have avoided offering false assurances by not ignoring illegal
multiple header fields per RFC5322 and defining such messages as
resulting in invalid signatures. Unfortunately, when essential input
checks are skipped, acceptance based upon DKIM's now potentially
deceptive results may play an evil role that cannot be repaired through
the use of reputation.
The general goal of DKIM cryptographically binding at a minimum the From
header field of the message content to a domain was to act as a trust
basis for acceptance. DKIM also purports to allow incremental
deployment without requiring additional undefined filtering be
introduced in mail transfer or mail user agents. Clearly, the
incremental deployment statement conflicts with the original goals due
to the neglected input validation flaw.
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
This version of DKIM also introduced use of RFC5890 instead of RFC3490,
which allows use of the German esset and the Greek final sigma, drops
string-prep, and defines 3,329 invalid code points. Unfortunately, this
version of the DKIM also failed to exclude use of Fake A-Labels, which
when presented to the user may also prove highly deceptive.
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
Regards,
Douglas Otis
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
