On Thursday 17 August 2006 11:26, Michael Thomas wrote:
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
Maybe I am missing something here, but it seems to me much like the old story
about the man who goes to the doctor and says, "Doctor, when I raise my arm
like this, it hurts". The doctor then says, "Then don't raise your arm like
that".
If you consider the controlled/uncontrolled perspective I mentioned last
night:
1. Uncontrolled - Sign mail submitted by authorized users of the MTA
without extra regard for identities used in the message (I say extra regard
since many mailing lists only accept mail sent by subscribers).
2. Controlled - Sign mail submitted by authorized users whose authority to
use the requisite identity (2822.From) has been verified.
The way I read what you are saying is that mailing lists are inherently
uncontrolled in this context. I agree with that. I think it's true of any
mail received from an MTA and not locally authenticated and controlled via an
MSA. Delegating signing authority to a forwarder that re-signs messages
would have similar problems.
The signing domain (d=) needs to be different for controlled/uncontrolled
traffic. Since d= is not visible to the user, there aren't any user
interface issues. If isp.com signs as d=msa.isp.com for locally submitted
controlled traffice and signs as d=lists.isp.com for mailing list traffic, I
don't think there's a problem. I do think we need to mention in security
considerations of the final specification, but I don't think it's a major
issue that impacts requirements or protocol design.
What am I missing?
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html