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

Doug,

ASP cracks opens the door to DKIM abuse and your unintentional "typos"example proves it. Do you think software is going to know thedifference now if your 3rd party signature was a typo, syntacticallyvalid but unexpected or otherwise?

ASP has removed a 100% ZERO FALSE POSITIVE PROTECTION mechanism and itwill not help DKIM signers if they can buy into this ASP in its flawedstate.


--
Sincerely

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


Douglas Otis wrote:

On Feb 4, 2008, at 10:15 AM, Hector Santos wrote:
Douglas Otis wrote:
Agreed.
But this 3PS type of message signature was the concern.
From: person(_at_)example(_dot_)com
Sender: other-person(_at_)(_dot_)example(_dot_)com
DKIM-Signature:  d=expample.com i=other-person(_at_)example(_dot_)com (g=*)
Sorry, this example needs correction. Should be-

From: person(_at_)example(_dot_)com
Sender: other-person(_at_)example(_dot_)com
DKIM-Signature: d=example.com i=other-person(_at_)example(_dot_)com (g=*)
But this isn't a 3rd party signature. The signing domain is the sameas the from domain, or did you try to throw in a "near-phish" domain,or is that a typo? "exPample.com" ???
Agreed. This is not _really_ a third-party signature. The definitionfor "Author Signature" used in SSP might make a signature with the_same_ domain non-compliant (a third-party) when evaluating an SSP "all"or "discardable" assertions.
See SSP-02 section 2.8.  Author Signature

 An "Author Signature" is any Valid Signature where the *identity* of
 the user or agent on behalf of which the message is signed (listed in
 the "i=" tag or its default value from the "d=" tag) *matches* an
 *Author Address* in the message.

Compare this with ASP-00 section 2.8.  Author Signature

 An "Author Signature" is any Valid Signature where the signing *domain*
 (listed in the "i=" tag if present, otherwise its default value,
 consisting of the value of the "d=" tag) *matches* the *domain* of an
 Author Address.
You seem to have internalized the ASP "Author Signature" definition.This definition causes less astonishment.
This message is clearly signed by example.com per RFC 4871, but wherea SSP policy assertion of either "all" or "discardable" might causethis ABSOLUTELY valid message to be dropped as being non-compliant.
I don't see what you are talking about here. Where is the problem?
The comparison with local-parts may cause messages signed per RFC 4871to be considered non-compliant.
Which specification are you talking about? Is this really a validmessage?
SSP-02. The definition within ASP appears correct, whereas the AuthorSignature definition within SSP is not.
But if you really meant the above being a near-phish, exPample.com,then this goes to illustrate how ASP will harm the primary domain.
Sorry for the typo.  This issue was not about look-alike domains.
Plus, you didn't indicate if the Sender= was bound to the signature ornot.
The From email-address being protected by the policy scheme MUST BEincluded within the signature's hash per RFC 4871. Although the displayname of the Sender header should not be highlighted as being confirmedby the signature when the header is not included within the signature'shash, neither DKIM nor SSP is about how information is to be shown tothe recipient. DKIM is about determining the source domain and SSPshould be about whether the message appears to be compliant with thedomain's asserted actions.
SSP stipulations changes RFC 4871 signature handling to not use thei= parameter when there might be such a conflict with the From header.
Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i=must be the same
Agreed, however the issue was with respect to the local-partother-person(_at_)example(_dot_)com not meeting the requirements for "AuthorSignature" in SSP, however it does meet these requirements in ASP.
Its hard to continue a thought process in what is a flawed concept.
Even then, all I see above is either a typo or an intentional 3PSbased on a near-phish. If that is the case, then you just showedquite clearly, how the author domain EXAMPLE.COM has just beenexploited with less means of protecting it.
Sorry about the additional "." and  "p".
DKIM is silent upon what might be displayed.
The logical association implies for this to be:

   ([i] == d) != From
which is the fundamental basis for a 3rd party Signing operation.Like wise, the logical association for a 1st party signature is:
   ([i] == d) == From
You appear to be describing a comparison stated in ASP, and not thecomparison in SSP.
Huh? the above logic has been the basis for 3rd vs 1rd party signature(respectively) since the beginning.
True, but this is not how SSP has defined a "first party" (author)signature.
We need to keep our eye on the prize here and that is DOMAINprotection,
Agreed.
You do? How can you support ASP when it doesn't help protect domainsfrom 3rd party abuse?
The example given had typos and I am truly sorry for that. When theFrom and Signature domains are the _same_, the signing domain stillremains in control of their own protection.
to assist it in keeping with its new asserted DKIM-BASE "social andethical" responsibility. SSP is basically a fraud detection orprotocol consistency checker. If everything is koshser, I believeno one has ever said SSP allows a message to pass or skip any othertesting.
It would seem better to describe this as a means to evaluatecompliance with Sender assertions pertaining to what the transmittingindicates as their handling practices. This view makes less sensewhen the assertion is "discardable".
Now you really lost me. :-)
Are you suggesting even DISCARDABLE is no good? You want to furtherwater down SSP or whatever you wish to call it ASP?
SSP assertions should not be viewed as "actions a verifier may take".The term "strict" and its definition was in keeping with a philosophythat assertions reflect the "actions of the signing domain".
Even when there is a desire to absolve a receiving system for discardingmessages, discarding messages is not in keeping with SMTP. Discardingwhat appears to be possible fraud is counter intuitive when spoofing thedomain potentially represents a criminal act. At least a DSN per RFC3464 might alert the domain of possible fraud or the failure ofsignature related infrastructure. "Please sweep failures under the rug"is not in keeping with a desire to control abuse or to preservedelivery's integrity. There is no need to encourage or absolve the useof an easy solution. IMHO, "discardable" is shameful. Why not alsohave "report all failures using RFC 3464" as an assertion as well?"Strict" was a far better choice that concluded an extensive debate.
The concern is when the message is signed by the author's domain, buton-behalf-of someone else with the author's domain. When this domainapplies their signature, their signing policy MUST evaluate whether"other-person(_at_)example(_dot_)com" is able to include "person(_at_)example(_dot_)com"with the From header. It would be ridiculous to expect to have thispolicy applied by a possible verifier. As you said, DKIM is aboutestablishing responsibility _at_ the domain. When the domain is heldaccountable, as designed in RFC 4871, the local-part introducing themessage does not matter. The local-part might be highlighted by theMUA to indicate who introduced the message, but as far as signingpolicy should be concerned, local-part is immaterial.
I think I agree with the statement but I am not seeing the problem,maybe because the above example had typos?
Yes I think we are in agreement.
The local-part is only material when the key is g= restricted.
I'm going to take your word on this. It sound's reasonable, but Ithink overall, this is now really a moot point because ASP has madeDKIM-BASE a less attractive idea to pursue. Too much fraud ispossible now.
What aspect of the ASP definition of the Author Signature permits fraud?

The example was in error and was not indicative of the definition.

-Doug



_______________________________________________

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