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

[Douglas Otis]

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