ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

2009-05-11 11:33:00
On 5/11/09 5:09 PM, Steve Atkins wrote:
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.
     


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.
   

Sorry- I'm not quite sure what you're saying here.  That an ACM.ORG-like 
forwarding address is likely or that they would tag something to the 
bottom of a message?

Eliot

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>