Folks,
The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is raising
nothing new about the topic.
A quick summary of the technical point at the core of Doug's concern is that the
presence of multiple rfc5322.From header fields does appear to represent a
plausible attack vector, but it also violates RFC5322 -- and RFC822, if anyone
is worried about the history of this issue. DKIM (RFC4871) requires that the
signing engine be handed a valid RFC5322 message. Hence the burden of ensuring
that there is only one From: field rests outside DKIM.
For reference, Doug posted a related blog recently and I posted a response
yesterday:
<http://www.circleid.com/posts/searching_under_lampposts_with_dkim/>
Others are posting responses also. The Comment mechanism, to the Circleid
article, is being used to list these additional responses.
Inline comments...
On 6/21/2011 6:50 PM, Douglas Otis wrote:But,
RFC4686 Introduction states:
...
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.
Any possible omissions in an Informational threats document -- done 6 years ago
and before the signing specification (RFC4871) was written -- is of marginal
relevance, at best.
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.
It also should be noted that Signing Practices (ADSP) issues are irrelevant to
the candidate RFC4871bis effort, which pertains only to the signing specification.
This indicates the DKIM specification is seriously flawed.
It indicates that there is an issue, not that it is DKIM's responsibility to
solve it.
While DKIM may notoffer author validation,
Does not. Not may not. It's a simple and direct fact.
> it was intended to establish an accountable domain for
the signed message content that at a minimum includes the From header field.
And it does that. But it does not make any assertions about the /validity/ of
any of the data it signs, nevermind any of the data it does NOT sign.
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.
It actually has no discernible effect on DKIM's utility, nor have there been
reports from the field of problems in 6 years of deployed use.
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.
This appears to be a political rant.
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.
That statement well might be correct, but that's OK, since DKIM does not make
assertions about "source" validity, except in terms of the separate DKIM signing
identifier (in the DKIM-Signature: header field.) The signer is sometimes
referred to as a source. However DKIM makes no assertions concerning the Author
or Originator [RFC5598].
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.
The general goal is to attach an identifier than is reliable and valid, and it
does that. The identifier can be used for developing a reputation assessment of
message streams signed with that identifier.
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.
I have no idea what the above means.
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
And it nicely shows that the working group considered the issue.
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.
Excellent. Now it is also DKIM's job to fix problems with Unicode...
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
wrong citation.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
