[ietf-dkim] Some concerns with SSP impact on very small businesses
dotis at mail-abuse.org
Tue Jan 8 18:49:15 PST 2008
On Jan 8, 2008, at 12:02 PM, Siegel, Ellen wrote:
> With SSP in play, once the ISP (e.g. yahoo.com) decides to publish
> an SSP record things start to go downhill. The above configuration
> will always trigger a lookup since the signature will never come
> from the ISP domain, and the Verifier will only look for the SSP
> policy in the From: address domain (yahoo.com).
Agreed. A DKIM signature does not establish compliance for an email-
address unless the selector is referenced at or above the email-
> Since it's unlikely that any third party signature used by
> outsource.com on behalf of their customers (whether it's
> outsource.com directly, or unique signatures per-customer) will be
> included in the list of Verifier Acceptable Third Party signatures
> at a given Verifier, a record with either dkim=all or dkim=strict
> will cause the joesbikeshop email to be consistently labeled as
> suspicious even though it is authenticated and even though the
> address belongs to the author of the email.
Correct, but such a domain is unlikely to publish a restrictive
policy. Such a policy would reduce the utility of the domain's email
by making use of mailing-lists problematic. Mike's suggested partial
signatures might offer a somewhat successful solution, but this would
be a rather dangerous strategy that could defeat the purpose of using
> In other words, once the major ISPs start publishing SSP records
> there will be no way for people matching the above profile to avoid
> having their mail marked as suspicious by SSP unless they stop using
> their ISP email, which is most cases is the one that's recognized
> and trusted by their customers.
TPA-SSP is a solution allows vanity domains to authorize third-party
email providers such as "outsource.com". These third-party domains
should be authenticating identities using RFC 4409 and ensuring
exceptions for From header are limited to email-addresses associated
by procedures approximating that used to assign S/MIME certificates.
A vanity domain could publish SSP "strict+TPA" and create a TPA-SSP
for outsource.com's signature. The TPA-SSP label is created by a
utility that does a SHA-1 hash and base32 encoding of "outsource.com"
that is published below the "_ssp." domain.
There would not be any need for a vanity domain share a private key or
to delegate one of their subdomain's to outsource.com, or for
outsource.com to apply different signatures based upon From header
> Until we get to the point where domain registrars make creating
> authentication related DNS records foolproof so that essentially
> anyone can do it, and until domain hosting services provide email
> clients that are as familiar and robust as those of the major ISPs,
> SSP is going to make life very painful for a significant segment of
> the population once ISPs start publishing records with anything
> other than dkim=unknown.
SSP currently does not offer enough flexibility for ISPs to make
restricted policy assertions. TPA-SSP however could allow email
providers partition their domain and to assist owners of vanity
domains obtain restrictive policy protections.
Ideally, SSP would provide a convention to assert the use of a TPA
extension initially. Not having a TPA extension defined may create an
upgrade venerability for some domains. Whatever assertion that might
be used to replace "strict" or "all" to mean "strict+TPA" or "all+TPA"
is not assured to be recognized otherwise.
> How big is this segment? It mainly consists of some individuals,
> small businesses, and non-profits too small to manage their own
> domains who want more professional email and more delivery
> consulting than a simple ISP account can provide. Some fraction of
> these do not even have a domain, and most of the rest have one but
> don't have sufficient access or technical expertise to manage it
> themselves (i.e., they may have a mostly static website, but
> generally don't use it for anything else including email).
At the relative cost of a CNAME, TPA-SSP permits subdomain signatures
to partition a domain's policies without altering the domain used in
an email-address. TPA-SSP offers a solution that avoids the use of
domain delegation or sharing private keys when asserting restrictive
policies across third-party MTAs. The number of places where TPA-SSP
might be used is rather vast, as even dealing with mailing-lists
signing with DKIM represents an administrative quagmire. Partial
signatures should not become a recommended solution for a mailing-list
problem, nor should verifier based white-listing of domains be used
TPA-SSP offers a practical and simple method for domain owners to
assert policy in a highly flexible manner, while avoiding difficulties
associated with sharing private keys or delegating one's domain. Even
if administration of private key sharing or domain delegation could
become practical, such a provider would be holding private keys for
perhaps thousands of other domains. Such providers would become a
prime target, where a security breach would be devastatingly difficult
to report and to defend against. Such breaches by prime targets would
significantly lower DKIM's credibility as a secure solution. : (
I would refer to you the DKIM.org website, but this site erroneously
references version 00 as an early proposal for SSP, rather than as an
extension of SSP.
More information about the ietf-dkim