On May 11, 2009, at 3:55 AM, Charles Lindsey wrote: > On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins <[email protected] > > > wrote: > >> >> l: Body length count >> >> This opens up a whole host of security issues, related to being able >> to change the rendered content of the message entirely after signing >> without breaking the signature. Removing it would remove a security >> hole you can drive a bus through. Is it being used? Are there any >> situations where it has proved useful? > > Signing the body is not essential for the primary purpose of DKIM, > which > is to expose phishers and the like. Malicious modification of a > message > _after_ is has been posted is relatively rare.
If a signer uses l=0 (or, given MIME games that can be played, any other l= value) then the only thing you can say about any validly signed message from that sender is that the subject line of the message is the same as the subject line of a message that sender signed. I don't think that's a useful level of protection for any use case. It means that I can, for example, take one copy of a service notice from my bank, leave the headers the same and replace the URLs in the body of the message to links to my website, then send it out to a hundred thousand people - and it would be validly signed by the bank. (The only user-visible content I wouldn't be able to change is the subject line). If there is ever any user-visible sign in an MUA that an email was DKIM signed, or benefits to delivery for email being DKIM signed by a trusted signer, *and* some trusted signer actually uses l=0, I'll bet you'll start to see a lot more malicious modification and retransmission of messages. > So writing l=0 gives a way > to sign the headers only (saving quite a bit of overhead if that is > useful, plus removing all problems arising from changes of encoding > and > other mungings during transit. > Moreover, there are too many agents arounf > that insist on adding boilerplate to the end of messages (look what > the > mailing list expander for this list does, for example). Putting a > proper > l= value circumvents that problem (which is why it was out there in > the > first place). That assumes that the important signature in that case is the original authors, not the mailing lists, and that the mailing list itself isn't trusted. I think the normal model of a mailing list is not a simple mail forwarder, rather an agent that receives and validates mail then sends mail out to subscribers under the mailing lists signature. I could conceivably see this being an issue on an acm.org style forwarder, if there were one that modified the content it forwarded, but not a normal mailing list. I don't think that's a iikely use case, though. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
