Big gaping hole, I may assume that isp.com can determine the
author/originator but how to differentiate or not sign a spoof?
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael Thomas
Sent: Thursday, August 17, 2006 11:26 AM
To: Scott Kitterman
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] SSP Responsibility Delegation - Security
Concerns
Scott Kitterman wrote:
It seems to me that bringing a mailing list into the scenario changes
the
scenario slightly, but not in a significant way. I would envision two
basic modes of operation for a signer:
[]
I think people are missing the subtlties of the attack; the basic
problem is that there's
nothing that the signer can do to stop its subscribers from being gamed:
Suppose there is an ISP who signs for two customers: company.com and
mailinglist.com
using this third party delegation mechanism that it being touted.
company.com and
mailinglist.com make a SSP records that says that ISP.com is their
signer. Now lets
construct some messages:
// normal from company.com
From: foo(_at_)company(_dot_)com
Dkim-Signature: d=isp.com;
// what is the dkim-signature asserting here:
From: foo(_at_)company(_dot_)com
Sender: mailinglist.com
Dkim-Signature: d=isp.com
How does the recevier know who isp.com is signing on behalf of? The
answer
is that it doesn't.
So let's send this from mailinglist.com through their authorized
submission server:
From: president(_at_)company(_dot_)com
Sender: mailinglist.com
DKIM-signature: d=isp.com;
Is mailinglist.com allowed to assert president(_at_)company(_dot_)com? No. Does
the
signer have any way to allow the receiver to tell which address it's
signing
on behalf of? No. Is this a threat to company.com? Yes. Does ISP.com
have
any way to police this? No: it doesn't know whether
president(_at_)company(_dot_)com
is subscribed to a mailing list at mailinglist.com or not.
This is a *much* bigger security hole than just a submission
authentication problem.
It's allowing companies whose only common business link is their
provider to freely
spoof each other in a way that the ISP can't control. That's a problem.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html