ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: Include new "known message replay" threat?

2006-03-19 09:21:40
In preparing for the WG meeting I realized that there had been no
response to this.  Read on for my attempt to collect a free beer :-) .

Stephen Farrell wrote:

I think I mentioned this before but maybe didn't explain well. (And
I didn't see it when combing the current issues, so I feel free to
raise it again, otherwise I couldn't:-)

Chosen message replay as currently defined requires the attacker to
get a specific message signed, and that's fine. The idea here is
slightly different in that we lower the barrier for the attacker and
only require him to be able to make some guesses about the message
that'll get signed.

An example, example.com sign everything; attacker knows some (innocent)
users in that domain; attacker wants to get a message containing "update
your account", with a hypertext link, so he sends a mail to a bunch of
these users with that HTML fragment hoping that one will reply, in such
a way that the resulting mail is usable for his nefarious purposes.
This really seems like a corner case to me, but since we're trying to
err on the side of including things, perhaps it should be mentioned.

Different people will respond differently, but all reply messages will
be signed, and some may be usable as if the attacker had chosen the text
himself.  I'm sure better examples can be derived (and I offer to buy a
beer for the best in Dallas), the point is that the attacker might be
able to achieve the same effect as a chosen message replay but with
just a little more effort and without any internal collusion, zombies
or whatever.  That would presumably mean that this attack would be
mounted against enterprise domains more often than chosen message
replay.
Not that long ago, I might have said that just having the attacker's
text in the context of a reply message isn't good enough to accomplish
anything significant for the attacker.  After all, the attacker can't
separate their text from the rest of the message without breaking the
signature.   But the number of "reflection attacks" and other attacks
where the attacker's message is  crafted to look like a bounce message
indicate that this really is an effective technique.  It seems that some
people will click on any URL in any context.

So my attempt at a beer (and given the lack of replies so far, my
chances seem fairly good) is that the attacker might use this technique
in a "reflection attack" where they stimulate a bounce message toward
the actual target from a domain that signs everything.

Some kind of egress content filtering is probably the best counter
against this, and I don't see any changes for DKIM base resulting.
But if there's agreement that this is a different threat, then I think
it'd merit inclusion.

OTOH, this could be included just as a variant of chosen message
replay, which'd be easier on the editor since it'd only add a
paragraph to that section.
Yes, I'd prefer that we just add a paragraph to the chosen message
replay section.  Here's what I have in mind (insert following paragraph
2 of section 4.1.4):

A variation on this attack involves the attacker sending a message with
the intent of obtaining a signed reply containing their original
message.  The reply might come from an innocent user, or might be an
automatic response such as a "user unknown" bounce message.  In some
cases, this signed reply message might accomplish the attacker's
objectives if replayed.  This variation on chosen message replay can be
mitigated by limiting the extent to which the original content is quoted
in automatic replies, and by the use of complementary mechanisms such as
egress content filtering.

(end of proposed text)

I'm a little uncomfortable with adding what might be seen as a
dependency on content filtering here; as far as I know we have no
similar reference elsewhere.  How do others feel?

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

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