ietf-mxcomp
[Top] [All Lists]

RFC2822 attack scenario

2004-04-29 08:01:54

On Thu, Apr 29, 2004 at 07:54:30AM -0400, Margaret Olson wrote:
| 
| But they could still present the from as microsoft.com, and it would 
| take changing all the MUAs to show and end user that this was 
| unverified or verified but unaccredited, and an corresponding level or 
| education to teach people what those two things mean. Is that easier 
| than preventing 2822 forgeries directly?
| 

I hope I'm not breaking any laws by discussing this, but on a technical
note, to play Devil's Advocate, I want to suggest the equivalent 2822
attack scenario:

Spoofer creates message with headers

  Sender: 
spoofer(_at_)adsl-64-168-75-162(_dot_)dsl(_dot_)snfc21(_dot_)pacbell(_dot_)net
  From:   "Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com>
  To:     ietf-mxcomp(_at_)imc(_dot_)org

IMC performs 2822 checks, authenticates the Sender address, and
rewrites the headers as usual, producing:

  Sender: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
  From:   "Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com>
  To:     ietf-mxcomp(_at_)imc(_dot_)org

A receiving MTA/MUA performs 2822 checks, authenticates the Sender
address, and accepts the message.

The result of this attack scenario is indistinguishable from a regular
message from Harry to the list.

Replace "mailing list" with "forwarder" and the attack extends to
forwarding services.

Replace "To: ietf-mxcomp(_at_)imc(_dot_)org" with "To:
unsubscribe-ietf-mxcomp(_at_)imc(_dot_)org" and the attacker has just 
unsubscribed
everyone from this list.  Or are we going to suggest that the entire
installed base of MLMs only operate against the authenticated address?

This is why I believe the ultimate solution to 2822 authentication must
involve cryptography.

Of course, that's a long way off.  Observe that imc.org itself doesn't
confirm mailing list subscriptions using a double-opt-in mechanism, and
we see how much inertia is out there.

So, until Yahoo starts pushing DK harder, or until some other signature
mechanism comes along, we have no choice but to do 2822 authentication
using imperfect means which we already know, going in, can be gamed.
But if that gets a major constituent onboard and cooperating, maybe that
is worth the cost.  Maybe the benefits in the cases when it works as a
whitelisting function outweigh the costs of gaming.  The important
thing is that we shouldn't give the impression that 2822/LMAP will be
100% effective at cutting out the bad stuff, because it isn't.

Is that a tradeoff people are willing to make?