-----Original Message-----
From: Meng Weng Wong [mailto:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
On Thu, Apr 29, 2004 at 07:54:30AM -0400, Margaret Olson wrote:
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.
What happens if you add accreditation to this scenario, and imc.org has a
way to check if pacbell.net validates from address identities? In other
words, is pacbell.net letting it's users type in any from address they want,
or only ones that pacbell believes they have a right to use? This strikes me
as a fairly trivial level of accreditation that most server operators ought
to be able to meet. In this example I'm assuming that there is 2821
authentication, so you know that this is a pacbell authorized server.
If IMC finds that the origin is not trust worthy, it can either flag that (a
negative flag) so that recipients know that IMC may be accredited but it is
disowning this message, or it IMC can drop the message. (Negative flags have
no spoof value).
This would (eventually) allow an MUA to display "not trustworthy" if the
edge decides to accept untrustworthy messages. This may be as big a hurdle
as getting the MUA to display the on behalf of, but it does remove some
level of required analysis from the end user.
I'm not sure if this helps or just moves the problem, but I thought I would
throw it out there. It in essence throws the 2822 validation responsibility
onto the shoulders of the originating server's domain, but in a very
explicit way.
Margaret.