On 20/Oct/10 13:23, Charles Lindsey wrote: > On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy > <m...@cloudmark.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
