[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8

[Douglas Otis]

On Feb 5, 2008, at 10:46 PM, Hector Santos wrote:
>
> Both SSP-00 and SSP-01, offered DKIM signer who wished to operate in  
> this mode, powerful 100% zero false positive protocol inconsistency  
> and fraud protection.
>
> With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection  
> against 3rd party fraud.

An "all" assertion never implied all unsigned messages should be  
rejected.  This assertion also never ensured receivers that third- 
party handling was avoided.  Any damaged signature must be handled as  
if not signed.  Otherwise, spoofed signatures permit a means to thwart  
policies that give credit for invalid signatures.

> The NEVER concept can still be covered using DKIM=DISCARDABLE and a  
> NULL DKIM public key.

Disagree.  This is attempting once again at establishing that no email  
is sent by the domain.  The rub being that this assertion does not  
require DKIM to be involved.  If done, this assertion should be made  
directly rather than requiring still more DNS transactions.

> The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.

Disagree.  Domains wishing to protect important transactional or  
commerce related messages are unlikely to consider their messages  
"discardable".  Rather than assuring receivers that their domain  
avoids services that might damage a signature, "discardable" permits  
discarding messages whenever a signature is not valid.

When was changing the assertion from "strict" discussed?

When would discarding a message be a recommended action?

Why is SSP attempting to define receiver actions?

> But anything related to 3rd party signers was completely eliminated  
> in SSP-02/ASP.  Even though SSP-02 DKIM=ALL is a "always sign for  
> 1st party authors" concept, it is basically a DKIM=DISCARDABLE  
> without semantics on REJECTION.  DKIM=DISCARDABLE failures is  
> explicit with the REJECTION control.  DKIM=ALL failures are not.

The assertion of "all" will likely result in few sources being  
considered acceptable sources for this domain's email.  When lacking a  
valid signature, it would be clear that some other domain is involved.

> In short, DKIM=ALL is the SPF version of SOFTFAIL where you can  
> record it, but you do not take any REJECTION action on it.  Just  
> like SPF.

Disagree.  SPF's SOFTFAIL essentially admits registration failures are  
beyond the control of the transmitting domain.  DKIM's ALL admits  
other domains might handle messages that should otherwise be signed.   
"Strict" suggested that the domain attempted to preclude any  
destructive handling, but this assertion has been removed.

-Doug