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
