On May 22, 2009, at 5:31 PM, John Levine wrote:
Surely you do not suppose that a signature which covers only the
From header (and that is a perfectly valis signature according to
the document) is to be accepted as equally valuable to a signature
that covers everything.
Probably not, but that's because a dimwit who puts on cruddy
signatures is unlikely to earn a very good reputation. I really
REALLY do not plan to waste any time inventing heuristics to
evaluate the "quality" of a DKIM signature and I doubt anyone else
does, either. If you want people to accept your mail, be sure to
sign only good mail, and be sure to sign it in a way that bad guys
can't fake.
John,
I would agree signatures currently should cover the message body, but
this might also include the message body length. A properly
structured message should not be prone to attack without the attack
being rather obvious. When the body of the message has an open-ended
length, the number of attempts to produce a collision might be within
what now seems like a small number of attempts. With millions of
computers under centralized control, the time required to defeat an
open-ended DKIM body hash with a reasonable set of signatures might be
fairly brief. For most of these systems, users might not even be
aware of the role their computer play in the attack. Anyone that
signs a fairly generic message, where users could think they are being
cc'd with comments added in the phish, might prove fairly effective at
creating victims.
The ability to keep the message format from being messed up by what is
likely to become a deluge of provider ads would also be a benefit.
After all, this was one of the driving benefits being sought when
developing DKIM. It seems that DKIM combined with RFC 5451 and the
loss of the l= parameter, this benefit is likely lost as well. That
would be a shame. It would also be a shame to have people still
wondering who sent which part of a DKIM signed message.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html