On 26/Apr/10 15:59, John Levine wrote:
I'm willing to accept a signature with l= so long as it covers the
entire message. I agree that partial coverage is not practically
distinguished from no coverage.
I note you refer to /current/ --rather than possible or commendable--
practice
Sorry, I don't understand what you're trying to say.
Please excuse my poor English...
Partial body coverage allows all sorts of sneaky tricks that make the
body presented to the user completely different from that the sender
signed. l=0 screams "phish me", attach a fake body to a genuine
signed set of headers.
I wish there were ways to know how often does that happen.
At any rate, all what I'm trying to say is that a few certified
fields, e.g. "From:", "To:", and "Date:", are more useful than a
broken signature, in most cases.
We hashed all this out in excruciating detail on this list a year or
two ago, so please review the archives.
Good hint. However, you were already saying so in Aug 2005:
We definitely had this argument before. You cannot expect signatures
to survive mailing lists (as opposed to courtesy forwards) unless you
loosen the signing algorithm to the point that it will accept
mutations that people wouldn't consider to be the same message, e.g.,
adding new MIME parts.
http://mipassoc.org/pipermail/ietf-dkim/2005q3/000274.html
Criticism toward approaches that are too tight to be practical has
been raised before. Let me quote Eric Rescorla from Oct 2005:
A related issue is the focus on forgery as the end-goal. The reason
that people are interested in stopping forgery is that they
believe that that can be used to block spam (see Section 2, where
this is explicitly stated). Indeed, if what you wanted to do
was stop message forgery as a general case, you would have to
consider the issue of forgery by other authorized users in
the same administrative domain, which generally leads to an
S/MIME style solution.
http://mipassoc.org/pipermail/ietf-dkim/2005q4/001090.html
That was also considered "very late in the day", and he replied to
such comment like so:
Huh? I raised these issues at the first MASS BOF and again at the
DKIM BOF in Paris. It's hardly my fault that they've never been
addressed adequately. That said, I don't see what fair has to
do with it. Either DKIM will do something useful or it won't,
and that's independent of the time when the question of its
usefulness was raised.
http://mipassoc.org/pipermail/ietf-dkim/2005q4/001124.html
Further answers were concerned about chartering issues, grand
opinions, reputation systems, World Hunger, and similar nuisances...
I haven't been able to track when has it been decided that DKIM is not
MIME-conformant. I'd agree that it's a bit late to introduce, say,
separate signatures for each entity. It doesn't seem too late to add a
mellowed out canonicalization, though. It could loosely take into
account MIME, considering that some servers add or drop some
attachments, and possible conversions. Very inappropriate for bank
transactions, but unbreakable. Would that be feasible? If not, l=0 is
the only practical setting for multipart messages, IMHO.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html