On Thu, 2006-08-17 at 08:26 -0700, Michael Thomas wrote: > > 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.
For a DKIM domain to offer a service safely listed as a designated domain, the 2822.From is valid or it is not signed. In the case of a mailing-list, this would abuse an account. The 2822.From addresses will not have been validated and a validation process should be rather limited on a per account basis. A slew of non-validated 2822.From addresses should cause the account to become disabled without permitting this messages to be sent. In the case of a company, arrangements through an account could avoid each local-part of the company's domain being validated. Perhaps just postmaster@ validation would suffice. This account should still be restricted in the addresses within the domain permitted by the account. > // normal from company.com > > From: [EMAIL PROTECTED] > Dkim-Signature: d=isp.com; > > // what is the dkim-signature asserting here: [EMAIL PROTECTED] represents a valid use of this address. > From: [EMAIL PROTECTED] > Sender: mailinglist.com > Dkim-Signature: d=isp.com Account disable due to frequent attempts to send messages where the 2822.From had not been validated. Perhaps isp.com offers special accounts for mailing lists signed using: From: [EMAIL PROTECTED] Sender: mailinglist.com Dkim-Signature: d=lists.isp.com lists.isp.com should not be a designated domain as this would not be representative of validated 2822.From addresses. This domain should not be certified as a DKIM signing domain suitable for designation. > How does the receiver know who isp.com is signing on behalf of? The > answer is that it doesn't. Either the signing domain ensures the 2822.From addresses are valid, or the signing domain should not be certified as a DKIM signing domain suitable for being designated. If the domain is suitable, then it can be assumed the 2822.From is valid in every case. > 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. Again, this account should be disabled when the 2822.From addresses have not been permitted. Permissions should only occur after a validation on a limited basis per account. > Does the signer have any way to allow the receiver to tell which > address it's signing on behalf of? No. No. Messages where the 2822.From has not been verified are not signed. Setting up a DKIM signing domain suitable for being a designated domain will requiring tracking what is permitted on a per account basis. This may also require a means to validate the receipt of the 2822.From address by the account. > Is this a threat to company.com? Yes. No. Either this is prevented or a different signing domain is used. When there is no designated domain, there is no expectation the 2822.From is valid. It would seem Hector would advocate a separate flag indicating whether the 2822.From is valid as a separate assertion from by whom it should be signed. My view differs in this case. Either the 2822.From is valid or don't list a designated (authoritative) domain in the policy. A flag that signals a required signature without an assertion the 2822.From is valid offers little protective value. > 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. ISP.com should limit the use of the 2822.From addresses to those pre-arranged and validated. A mailing list should be trapped and disabled as an abusive account. This should also curtail many of the bot-net abuses. > 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. If ISP has not validated the use of a 2822.From address, it should not be permitted. Again, this can work in much the same way as is done to validate an email-certificate, or to subscribe to a mailing-list. To accommodate the use of a mailing-list a different type of account would be used and signed using a different domain such as lists.isp.com. The goal that Hector is seeking represents a desire to list who should sign without making any assertion regarding the validity of the 2822.From. While not agreeing with that use, a policy could be structured to accommodate that use as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
