-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles Lindsey
Sent: Friday, October 15, 2010 9:06 AM
To: DKIM
Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton <fenton(_at_)cisco(_dot_)com>
wrote:
Here's some text I propose for section 8.14, in place of the current
text. Bear in mind that this is in the context of the Security
Considerations section of the spec, so it is really a discussion of
the
threat and how it is dealt with, rather than normative text.
OK, we're gradually moving towards an acceptable text, but we're not
there
yet.
... Most of this is good advice, but section 5.3 is in the
context of section 5, "Signer Actions", and is therefore the wrong
place
to add normative language for verifiers. So I have added a new
section
6.1.1 ...
+1
8.14. Attacks Involving Addition of Header Fields
Many email implementations do not strictly enforce the message
syntax
specified in [RFC5322]. One potentially exploitable consequence of
this
is that an attacker who is capable of modifying a message in transit
could insert additional header fields that, if properly placed,
could be
rendered to the recipient in preference to the originally signed
header
fields.
I don't quite see what an attacker can usefully do by modifying
messages
in transit. If they message was already signed (say by ebay), then the
attacker must somehow get ebay to sign a message with a useful (to
him)
text in its body. So what is the benefit to him of making it appear
From:
someone who is not Ebay (except maybe to ensure that replies get sent
to
him - since I assume that MUAs that only display the first header will
also Reply-To that header)?
The particular danger that comes to my mind would be where the signing
domain uses l= (yes, I know there is a warning against doing this....
why don't we just deprecate "l="?). If evil ne'er-do-well can get a
short, somewhat generic signed email from a low level person at an
organization then they can potentially leverage this with the multiple
headers to generate a spear phishing attack. I have not trod to far down
this path to construct a proof of concept but a google for DKIM + l=
yielded examples (Assuming you are willing to wade through a bunch of
results) of domains using "l=", most likely out of ignorance (a fertile
breeding ground for abuse).
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html