hsantos at santronics.com
Mon Feb 4 10:15:46 PST 2008
Douglas Otis wrote:
> 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
> (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,
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.
Hector Santos, CTO
More information about the ietf-dkim