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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html