[ietf-dkim] SSP Responsibility Delegation - Security Concerns

[Douglas Otis]

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: foo at company.com
> Dkim-Signature: d=isp.com;
> 
> // what is the dkim-signature asserting here:

foo at company.com represents a valid use of this address.


> From: foo at company.com
> 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: foo at company.com
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: president at company.com
> Sender: mailinglist.com
> DKIM-signature: d=isp.com;
> 
> Is mailinglist.com allowed to assert president at company.com? 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
> president at company.com 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