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: [EMAIL PROTECTED] > Dkim-Signature: d=isp.com; > > // what is the dkim-signature asserting here: > > From: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > Sender: mailinglist.com > DKIM-signature: d=isp.com; > > Is mailinglist.com allowed to assert [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] 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
