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

Douglas Otis wrote:
> On Feb 5, 2008, at 10:46 PM, Hector Santos wrote:
> > 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.  
Not in SSP-02, but it was implied in all other previous drafts.

> This assertion also never ensured receivers that third-party 
> handling was avoided.  
Sure it did, in SSP-00, SSP-01, it was very clear.  We had policies that 
either expected it or did not expect it.
This was removed in SSP-02, *intentionally neglectful* of the security 
issues this removal creates.
> Any damaged signature must be handled as if not 
> signed.  
SSP-02 removes all semantics for REJECTION in policies other than 
DKIM=DISCARDABLE where there is a explicit statement for REJECTION.  The 
implication is sure the DISCARDABLE has clear instructions for REJECTION 
and all others do not.
When signature fails and the only different is the policy and one 
implies to receivers "These Failure is rejectable" for DKIM=DISCARDABLE 
and "The same failures are not rejectable" in DKIM=ALL, not only does 
this lack common sense, it is foolish to believe that this inconsistency 
will be tolerated by the general case receivers, thus making it much 
more difficult to consider DKIM in general.
I am not guessing here, I have a hard time accepting the idea of adding 
DKIM to our package because of this.  Its going to make life more 
difficult, not less, for my customers,  I would be irresponsible to add 
something filled with flaws, false hope and high potential for more 
support issues than less.   ASP is not helping the ANTI-SPAM problem, it 
 is adding to it.
> Otherwise, spoofed signatures permit a means to thwart policies 
> that give credit for invalid signatures.
Exactly, that is what SSP-02 now provides!

> > 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.  
No, it is establishing the reality in the world where real companies and 
people who have domains which are never meant and used for email but it 
is forged, exploited and abused by bad guys, bulk mailers, spammers 
anyway.  Is this not a reality?
> The rub being that this assertion does not 
> require DKIM to be involved.  
If this was a Return-Path domain for which there is an STANDARD 
ASSERTION of MX involvement, I can see your point. But we are not 
talking about the Return Paths, but From: header domains and in this 
case, it is a DKIM involvement to consider the From: domain for MX 
correctness.
> If done, this assertion should be made
> directly rather than requiring still more DNS transactions.
Two things:

First, I believe you were one of the principles in getting the 
questionable MX lookup within the SSP-01/SSP-02 steps.  It isn't even 
optional (SHOULD or MAY), but a MUST requirement.   You shouldn't be 
surprise if RECEIVER ignore this MUST for the same conflictive reason 
you stated above that it is could be done as a separate protocol or 
procedure outside of DKIM/SSP.
Second, how can you disagree with what is obviously possible where you 
have no control or ignoring the fact you accessed a PUBLIC key?
If th public key is NULL, the DKIM signature is automatically invalid 
and if an ASP DISCARDABLE policy is used, it means REJECTION.
> > The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
> Disagree.  
But it is written in stone:

   discardable

   All mail from the domain is signed with an Author
   Signature.  Furthermore, if a message arrives without a valid
   Author Signature due to modification in transit, submission via
   a path without access to a signing key, or other reason, the
   domain encourages the recipient(s) to discard it.

Does it not mean what it says?  I never was for explicit statements like 
this and I don't think most WG participants ever was.  All previous 
documents provided guidelines as either being "Suspicious" or 
"non-compliant" which for the most part is essentially code for 
"rejection"  but IMV, its not normally good practice to be so direct 
with REJECTION statements in email.
> Domains wishing to protect important transactional or 
> commerce related messages are unlikely to consider their messages 
> "discardable".  
Exactly, which in the end of the day, we all know that ASP is just a 
white wash attempt to kill the entire idea of SSP.
> When was changing the assertion from "strict" discussed?
Other than the ASP group attempt to get rid of it, it never happen here 
openly in the WG.
> When would discarding a message be a recommended action?
When it is consistent with what was declared by the domain as unexpected.

> Why is SSP attempting to define receiver actions?
It not about telling the receiver what to do but to HELP the receiver 
determine with zero false positive factors of what is expected and not 
expected - its about protocol consistency.
If the DOMAIN says it doesn't expect 3rd party signatures, it would be 
incredibly dumb for a Receiver to ignore those factors, not just for the 
good of the domain which has implicitly stated it would not take 
responsibility for a message it did not write or sign,  but for the 
receiver and its users as well to not use this unique detections to get 
rid of something that is clearly fraud or unauthorized or unexpected by 
the domain.
> > 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.  
Doug, you were militantly vocal against SPF for the same SOFTFAIL 
reasons.  As sure as the New York Giants are Super Bowl Champions, then 
you will be having belated recognized issues with ASP::DKIM=ALL failures 
as well.  :-)
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html