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

[Hector Santos]

Doug,

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

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

-- 
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.com
>>> Sender: other-person at .example.com
>>> DKIM-Signature:  d=expample.com i=other-person at example.com (g=*)
> 
> Sorry, this example needs correction. Should be-
> 
> From: person at example.com
> Sender: other-person at example.com
> DKIM-Signature: d=example.com i=other-person at example.com (g=*)
> 
>> But this isn't a 3rd party signature. The signing domain is the same 
>> as  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 definition 
> for "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 where 
>>> a SSP policy assertion of either "all" or "discardable" might cause 
>>> this 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 4871 
> to be considered non-compliant.
> 
>> Which specification are you talking about?   Is this really a valid 
>> message?
> 
> SSP-02.  The definition within ASP appears correct, whereas the Author 
> Signature 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 or 
>> not.
> 
> The From email-address being protected by the policy scheme MUST BE 
> included within the signature's hash per RFC 4871.  Although the display 
> name of the Sender header should not be highlighted as being confirmed 
> by the signature when the header is not included within the signature's 
> hash, neither DKIM nor SSP is about how information is to be shown to 
> the recipient.  DKIM is about determining the source domain and SSP 
> should be about whether the message appears to be compliant with the 
> domain's asserted actions.
> 
>>>>> SSP stipulations changes RFC 4871 signature handling to not use the 
>>>>> i= 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-part 
>>> other-person at example.com not meeting the requirements for "Author 
>>> Signature" 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 3PS 
>> based on a near-phish.  If that is the case, then you just showed 
>> quite clearly, how the author domain EXAMPLE.COM has just been 
>> exploited 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 the 
>>> comparison 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 DOMAIN 
>>>> protection,
>>> Agreed.
>>
>> You do?  How can you support ASP when it doesn't help protect domains 
>> from 3rd party abuse?
> 
> The example given had typos and I am truly sorry for that.  When the 
>  From and Signature domains are the _same_, the signing domain still 
> remains in control of their own protection.
> 
>>>> to assist it in keeping with its new asserted DKIM-BASE "social and 
>>>> ethical" responsibility.   SSP is basically a fraud detection or 
>>>> protocol consistency checker.  If everything is koshser, I believe 
>>>> no one has ever said SSP allows a message to pass or skip any other 
>>>> testing.
>>> It would seem better to describe this as a means to evaluate 
>>> compliance with Sender assertions pertaining to what the transmitting 
>>> indicates as their handling practices.  This view makes less sense 
>>> when the assertion is "discardable".
>>
>> Now you really lost me. :-)
>>
>> Are you suggesting even DISCARDABLE is no good?   You want to further 
>> water 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 philosophy 
> that assertions reflect the "actions of the signing domain".
> 
> Even when there is a desire to absolve a receiving system for discarding 
> messages, discarding messages is not in keeping with SMTP.  Discarding 
> what appears to be possible fraud is counter intuitive when spoofing the 
> domain potentially represents a criminal act.  At least a DSN per RFC 
> 3464 might alert the domain of possible fraud or the failure of 
> signature related infrastructure.  "Please sweep failures under the rug" 
> is not in keeping with a desire to control abuse or to preserve 
> delivery's integrity.  There is no need to encourage or absolve the use 
> of an easy solution.  IMHO, "discardable" is shameful.  Why not also 
> have "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, but 
>>> on-behalf-of someone else with the author's domain.  When this domain 
>>> applies their signature, their signing policy MUST evaluate whether 
>>> "other-person at example.com" is able to include "person at example.com" 
>>> with the From header.  It would be ridiculous to expect to have this 
>>> policy applied by a possible verifier.  As you said, DKIM is about 
>>> establishing responsibility _at_ the domain.  When the domain is held 
>>> accountable, as designed in RFC 4871, the local-part introducing the 
>>> message does not matter.  The local-part might be highlighted by the 
>>> MUA to indicate who introduced the message, but as far as signing 
>>> policy 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 I 
>> think overall, this is now really a moot point because ASP has made 
>> DKIM-BASE a less attractive idea to pursue.   Too much fraud is 
>> possible 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