On 20/Oct/10 13:23, Charles Lindsey wrote:
On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
These topics are distractions from the effort of solidifying the DKIM
specification for advancement along the standards track. That's what I
believe he means by "irrelevant for the current discussion".
The scam I have described involves the use, by the phisher, of a
DKIM-signed (by himself) email with two From: headers, which is intended
to fool verifiers into not spotting that the first signature should have
triggered an ADSP lookup which would have revealed that the first From:
was 'discardable'.
Naturally, the phisher signs with a throaway domain that has not yet
acquired any reputation, good or bad.
Since the scam involves the use of DKIM, and since the only fix I am aware
of requires a change to the DKIM standard, then it is highly relevant to
the current discussion.
IMHO, this issue has to be addressed refining the signing spec. For
example, the initial paragraph of section 5.4 could be modified so as
to read:
The From header field MUST be signed; that is, it MUST be included
at least once in the "h=" tag of the resulting DKIM-Signature
header field, and SHOULD be included twice (see Section 8.14). In
addition, the signer MUST ensure that at most one instance of the
From field actually exists in the header.
The current PS silently assumes that there is a single From, and I
guess most interoperability and testing has been done in such
conditions. Hence an amendment like the text above can be understood
as a clarification --rather than a change-- of the protocol.
Verifiers would then discard any From field after the first one,
whether signed or not. Of course, a combo-verifier is always free to
return some error due to bad message syntax, even if all signatures
verify (although I'd consider it cleaner to return non-DKIM errors for
non-DKIM failures.)
JM2C
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html