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