[ietf-dkim] Comments on SSP Review BASIC ISSUES

[Douglas Otis]

On Dec 4, 2007, at 4:43 PM, Steve Atkins wrote:

> If it starts being deployed and we discover that the SSP false- 
> positive rate is too high we'll lose a huge amount of time rolling  
> back deployment of SSPv1 and working on a more realistic SSPv2.
>
> The SSP false-positive rate will be driven primarily by the DKIM  
> false-negative rate. As that's a critical piece of data needed to  
> complete the SSP design to a level of quality suitable for  
> widespread deployment the wisest course of action would seem to be  
> to wait until we have wider DKIM deployment and more DKIM  
> operational experience, and then to gather that data.

Any domain asserting All or Strict will also likely cause false- 
positives when their domain signs for headers other than the From but  
the From also contains their domain.  A domain dedicated to  
transactional messages could ensure other headers are not signed  
(perhaps by deprecating i= parameter use to make all signatures  
ambiguous within the domain).  This domain could also ensure only  
trustworthy entities hold their private keys.  One wonders whether  
keys should have had a scope assertion to constrain which headers are  
qualified to be signed.  The header scope assertion could be placed  
within SSP with a negligible increase in overhead.  As it is now, SSP  
will be checked in the case where the From header is not signed.  An  
SSP scope could indicate whether an exception should be made.

If a key is restricted with g=, a signature for anything other than  
the From could be noted and serve as a filtering input.  It seems  
doubtful, in the general case, rejecting or placing these messages  
into a junk folder will be the best choice.  As it is now, poor  
treatment of these messages is likely become common.  This issue may  
also prevent domain's wishing to assure recipients, to be unable to  
consistently use the i= parameter. :^(

A key or SSP scope policy could indicate only From headers are valid,  
and applied as a follow-on solution when ignoring i= parameters prove  
problematic.  Being generous in what is accepted for valid signatures  
from the From domain seems like the best solution.

John Levine's suggestion of using i= identities as opaque identities  
is very attractive, but this also prevents a domain of ever indicating  
they sign everything when the definition of signed MUST include  
matches with the i= parameter.  Perhaps there should be a draft  
created to offer a u= extension to hold opaque identifiers.  This  
would offer a consistent signed location where the domain and  
identifier are assured to be related.

-Doug