-----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 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