-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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