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

On Feb 6, 2008, at 4:11 PM, Hector Santos wrote:

> 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.
The SSP-01 draft stated that at least an acceptable third-party  
signature is not present before a message is to be considered  
"suspicious".  Even so, SSP should not dictate to verifiers what they  
should think.  Removing the "MUST BE considered Suspicious" is a  
welcome change.  Too bad Jim, Eric, and Mark decided SSP should then  
dictate permitted actions instead.  Especially actions that seriously  
erode the integrity of email delivery. : (
> > 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.
No. This assurance was limited to that of the now missing "strict"  
assertion.
SSP-01 strict:
All mail from the domain is signed; messages lacking signed a valid  
Originator (Author) Signature MUST be considered Suspicious.  The  
domain does not expect to send messages through agents that  may  
modify and re-sign messages.
> This was removed in SSP-02, *intentionally neglectful* of the  
> security issues this removal creates.
DKIM signatures might be damaged by various gateways.  Enterprise mail  
gateways may perform Content-Type header fix-ups which damage a  
signature, for example.  Information provided by SSP must be balanced  
against factors that are beyond the control of the signing domain.   
Nothing safely allows messages to be discarded.  The information  
needed to assess compliance does not result from a "discardable"  
assertion.  It is impossible to assess compliance against a  
"discardable" assertion, as no one knows what signer behaviour this  
assertion defines.
Suggested assertion definition-

strict:
 All mail from the domain is signed where agents that may damage  
signatures are avoided.
Whether the message is rejected, a DSN per RFC3464 is generated, etc.,  
there is no reason for SSP to define subsequent actions.  Least of  
all, actions where messages are silently discarded as a principal  
result.
> > 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.
Disagree. Suspicious never included clear instructions for rejection.

> 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.
It would be futile for an SSP draft to define all factors a verifier  
might use in deciding whether to reject or discard a message.  The SSP  
draft should be limited to clarifying the actions taken by the sending  
domain.  Those running the DKIM/SSP verification process will be  
adapting to changing conditions.  Verifiers actions can not be  
enumerated by a signer's policy assertions.
> 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.
DKIM is not an anti-spam technology.  Spammers can sign.  DKIM is an  
optional extension that is likely used by domains being spoofed or  
troubled by abuse.  To be successful, DKIM must not reduce the  
integrity of their email delivery of legitimate messages.
> > Otherwise, spoofed signatures permit a means to thwart policies  
> > that give credit for invalid signatures.
> Exactly, that is what SSP-02 now provides!
Disagree. DKIM/SSP offers a means accurately categorize messages into:

a) valid first-party signatures

b) without valid first-party signature from a domain that signs all

c) without valid first-party signature from a domain that guards their  
signature
d) valid third-party signature

e) valid third-party signature from a domain that signs all

f) valid third-party signature from a domain that guards their signature

SSP does nothing to promote a category of messages with invalid  
signatures.  The verifier is free to decide how they handle each  
category of messages based upon all factors at their disposal.  Surely  
you are not going to claim that DKIM offers value only for messages  
within category "a"?
> > > 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?
This was to be handled by category "c" where SSP should mandate use of  
MX records when the domain is being used to send DKIM signed  
messages.  Not having an MX record can then replace your concept of a  
NULL public key.  After all, the location of a public key is not  
defined.
> > 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.
An MX record is used to determine a valid domain during SSP record  
discovery.  SSP still needs to make publishing an MX record mandatory  
for domains signing DKIM and publishing SSP records.  In this way, the  
lack of an MX record clearly delineates whether the domain is used to  
send email when SSP policy is published.
> 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.
There is no valid reason that SSP not mandate the publishing of MX  
records at the domain publishing SSP policy.  If so, the ability to  
detect a domain that does not send email becomes a product of the SSP  
discovery process without costing any additional transactions.  It  
seems wasteful, if negligent, to not add this minor requirement.
> Second, how can you disagree with what is obviously possible where  
> you have no control or ignoring the fact you accessed a PUBLIC key?
Why a key is not found can not be assured.  The location should change  
every time the key is rolled.  Microsoft DNS may not update a CNAME  
references when being published subsequently by a different server, as  
example.  There are many reasons for an expectation of a public key to  
be unreliable.
> If th public key is NULL, the DKIM signature is automatically  
> invalid and if an ASP DISCARDABLE policy is used, it means REJECTION.
Does "discardable" mean 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?
strict:
 All mail from the domain is signed where agents that may damage the  
signatures are avoided.
Would a domain that intended to publish strict also wish to encourage  
recipients to discard unsigned (or invalid) messages?  Most high value  
targets want to know about attempts to defraud their customers, and  
want these messages to generate a DSN at least.  Perhaps SSP should  
also have a "rejectable" assertion as well?  After all, this  
information could then help authorities compile evidence of a crime.   
Any suggestion to discard these messages would be a major blunder  
since DKIM is not an anti-spam technology.  DKIM is about ensuring the  
message source and improving delivery integrity.
> 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.
The actions taken can be defined in BCPs once DKIM and SSP have been  
around for awhile.  The motivation behind the "discardable" assertion  
is to hide problems.  This assertion will slow or halt progress in  
overcoming unexpected problems.
> > 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.
This seems rather cynical, but you could be right.

> > 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 should unexpected situations be ignored and discarded?

> > 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.
Although a domain should be able to use SSP to indicate their  
behaviour, SSP should not be used to dictate verifier actions.  The  
verifier remains the arbiter of their actions based upon all related  
factors.  SSP assertions should be defined in a manner that might  
allow the verifier to determine whether the message received is  
consistent with the domain's asserted behaviour.  With that in mind,  
"discardable" means the signing domain does what exactly?
> 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.
Agreed.  That is what "strict" was about.  However, there may be other  
factors a verifier might apply in deciding the disposition of the  
message.  There is no reason SSP should enumerate actions that might  
involve extraneous factors.  That should wait for a BCP draft.
> > > 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.  :-)
SOFTFAIL is never having to admit the protocol itself is broken. : )

-Doug




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