[ietf-dkim] draft-ietf-dkim-ssp-02.txt

[Hector Santos]

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=*)

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"  ???

> 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?
Which specification are you talking about?   Is this really a valid 
message?

> (Hard to define compliance with the "discardable" assertion isn't it?  
 > Too bad this was not discussed on the WG list.)

It like you forced a non-compliance a ASP. :-)

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.

Plus, you didn't indicate if the Sender= was bound to the signature or not.

>>> 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.

> 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.

>> 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?   You just illustrated this above.

>> 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?

> 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?

> 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.


-- 
Sincerely

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