[ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt

[Douglas Otis]

On Jul 12, 2007, at 7:34 AM, Hallam-Baker, Phillip wrote:

>>> E) The message has a signature by a Third-Party domain.
>
> If all you are doing is spam control a signature from an  
> accountable third party is sufficient and you would not need to  
> check policy. If bank of america sends a message to the list where  
> it gets munged and resigned that is going to be acceptable at some  
> level.

Not exactly.  A Third-Party signature coincident with the SMTP client  
excludes replay abuse, which is likely problematic with respect to spam.

> If we want the ability to insist on being able to distinguish this  
> case we will need to do a lot more. I would much prefer to wait  
> till a recharter. In particular I think it will be much easier to  
> do that type of policy after the email infrastructure has made  
> accomodation to DKIM.

Third-Party authorization should not be delayed, nor is there a  
reason to wait.

There are three fairly important issues dramatically affected by the  
methods DKIM allows to authorize Third-Party domains.

1) Replay Abuse

2) Key Security

3) DSN handling

This is detailed in an extension to SSP, which slightly modifies the  
current SSP proposal:

http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt

Third-Party authorizations by-name safely scales.  This authorization  
strategy permits a signing domain to readily coincide with that of  
the SMTP client.  When the authorized signing domain is coincident  
with an SMTP client within the same domain, replay abuse is precluded  
as a risk.  The ensures adequate resources are available to handle  
exceptions where there would be risk of replay abuse.

By using an authorization by-name scheme, rather than exchanging keys  
for this purpose, the impact of a compromised key is limited to just  
that domain.  Reports of a compromise would not list every selector/ 
domain of where a public half of this service provider's keys had  
been published.  Without an authorization by-name SSP record, every  
customer of the service provider wishing to authorize the service  
might need to be included within such a report.  This type of report  
would be devastating news for DKIM.  DKIM keys will be distributed to  
several servers connecting to the Internet, and are fairly vulnerable  
as a result.

The use of transparent authorization techniques must be discouraged,  
as this will represent a significant problem when dealing with  
security breaches or even establishing best practices.

When a record is signed by a Third-Party domain, versus not being  
signed, this is a natural place to first query for a TPA-SSP record,  
rather than just an SSP record.  The use of a wildcard at this  
location eliminates any subsequent SSP record query.  This  
authorization by-name technique safely scales, unlike any IP address  
path registration scheme.  This authorization by-name helps curtail  
possible replay abuse as well.  Authorization by-name also greatly  
simplifies the process an email-address domain administrator  
confronts when they desire to authorize a service provider.  This  
also greatly limits the email-address domains exposure to possible  
security breaches as well.

As a bonus, by including a signed header contained the MAILFROM  
address,  authorization by-name can also ensure that DSNs of  
differing domains are safe to submit.

-Doug