> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Thursday, July 07, 2011 12:31 PM > To: DKIM > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > I think Murray is wrong. There is no benefit to the Bad Guy in using two > From: fields if he is not going to sign one of them. By signing, he hopes > to gain sufficient extra credibility to get through.
My favourite counterexample, which I've used many times already, is Mailman. It doesn't even check DKIM signatures, but you can still fake your way through its authorization process such that a different From: is shown to the user for some MUAs. This still supports the notion that we fear people will misapply DKIM results as the basis for the attack. Your proposed changes here won't remedy that. > Oh yes there is! Because identity assessors will undoubtedly give more > credence to messages where the signature domain is the same as the author > (i.e.From:) domain, even if they do not go to the extent of doing full > ADSP, and that is just what the BadGuy hopes will happen. Whose? Mine don't, and the text doesn't support that notion either. > And if implementors are not warned of this attack, they will tend to take a > report of "signed by the domain that DKIM regards as the appropriate > From:" at its face value and act accordingly. Where in the bis document is that notion supported or even suggested? I think the opposite is done in several places. > Signers who are BadGuys don't give a damn about the reputation of their > domains. Having displatched a million or so phishes with "d=badguy.com", > they will abandon that domain and use "d=son-of-badguy.com" for the next > batch. All that can be said of the reputation of badguy.com is that it is > a new domain, never seen before (but new domains are appearing all the > time, and must be assumed more-or-less innocent until proven > otherwise). Certainly true, and certainly fodder for a BCP for using DKIM or even reputation, but not for the DKIM protocol specification (especially since we declared reputation out-of-scope ages ago). _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
