On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com
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