Re: [ietf-dkim] Some concerns with SSP impact on very small businesses

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- 
address's domain.
> 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  
DKIM.
> 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  
content.
> 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  
either.
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. : (
See:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt

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