Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]