[ietf-dkim] SSP Responsibility Delegation - Security Concerns

[Michael Thomas]

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.com
Dkim-Signature: d=isp.com;

// what is the dkim-signature asserting here:

From: foo at company.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.com
Sender: mailinglist.com
DKIM-signature: d=isp.com;

Is mailinglist.com allowed to assert president at company.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.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