> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Thursday, July 07, 2011 3:09 AM > To: DKIM > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > The signer most certainly CAN attack, but what he is attacking is not > DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in > fact, his weapon of attack.
But all of those attacks exist today even without DKIM, so I don't see how DKIM becomes the weapon. Even more simple attacks involve use of the display name, something none of this work has even tried to handle (nor should it). It seems to me we're anticipating improper application of a DKIM "pass" here by MUAs or other agents and thus making the leap to calling DKIM a "weapon". In that light, MIME is also a weapon. And so is RFC5322. And so is HTML. The current 8.15 text explains what a DKIM "pass" does and doesn't tell us rather clearly. I'm wary of enumerating specific "attacks" and would prefer to use more general terms, as we have done here; such an effort might be taken as exhaustive. > I carefully included two scenarios in my paragraph, which you quote above, > because they are subtly different attacks. The 1st is the more pernicious > IMHO and the hardest to counter, since the 'h=from:from:' defence does not > work. I therefore regard it as ESSENTIAL that our Security Considerations > give warning of that scenario. Moreover, it is also necessary to draw > attention to the 'working upwards' signing order, which is at the heart of > both scenarios, since that might not otherwise be clear to the reader. In your scenario, the modules that operate on the signature result are able to observe that the signer took responsibility for a malformed message and can take appropriate action, degrading the signer's reputation, interfering with inbox delivery, or both. > I would be happy to reword my paragraph to make it clear that these > attacks are not against DKIM (although that point is also made strongly in > a later paragraph). How about the following? > [...] I believe the current text is adequate in that it lays out the semantics of a "pass" more clearly. I don't think calling out the two-froms-one-signed case explicitly will improve what's there. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
