[ietf-dkim] Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP)

[Douglas Otis]

Perhaps this can help with context.

On Nov 2, 2005, at 10:32 AM, Scott Kitterman wrote:
> On 11/02/2005 13:19, Douglas Otis wrote:
>> On Nov 2, 2005, at 9:47 AM, Hector Santos wrote:
>> >
>> > Table 1.0 - DKIM Verification States illustrates all possible
>> >             outcomes for signature verification against SSP.
>> >
>> >              
>> +------------------------------------------------------+
>> >             |            Sender Signing Policy  
>> Result              |
>> > +-----------+---------------------------------------------- 
>> +-------|
>> > | result    |  WEAK  | NEUTRAL | STRONG  | EXCLU  | NEVER  |  
>> NONE  |
>> > | verify    |   OPT  | OPT/3PS | REQ/3PS |  REQ   |         
>> |       |
>> > +-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | NONE      | accept | accept  | reject  | reject | reject |  
>> accept|
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | PASS      | accept | accept  | accept  | accept | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | PASS 3PS  | reject | warn    | accept  | reject | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | FAIL      | warn   | warn    | warn    | warn   | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | FAIL 3PS  | reject | warn    | warn    | reject | reject |  
>> warn  |
>> >  
>> +------------------------------------------------------------------+
>>
>> This chart represents multi-level ratings added together with  
>> email-address reputations to determine whether a message is to be  
>> accepted.  As with any reputation scheme, a negative reputation is  
>> bad.  All columns that permit third-party signing should be  
>> considered NOT RECOMMENDED to protect the reputation of the email- 
>> address.
>>
>> It is interesting that an invalid signature is offered greater  
>> access than no signature.  The invalid signature is even granted  
>> greater acceptance than a valid third-party signature.  Where  
>> there is no policy, a third-party signature is given reduced  
>> acceptance to that of no signature?
>>
>> This seems force the use of SSP and completely ignore the  
>> reputation of the signing-domain, does it not?
>
> That's a feature, not a bug.

This chart is not finalized, but the direction raises serious  
concerns.  This chart appears to be an attempt to hold the email- 
address domain owner culpable.  It is also disheartening to see the  
email-address domain owner offers a reporting address, but not the  
signer.  There are alternatives to SSP, but following this direction...

When reputation of the email-address domain owner takes precedence  
over that of the signer, this could coerce  the authorization into  
becoming "closed" ('!').  To lessen disruption caused by the "closed"  
authorization, the PRA algorithm could be used.  With Jim suggesting  
Sender-ID may solve the replay issue, this algorithm will need to be  
licensed anyway.  Any "open" authorization offers no protection for  
either the email-address domain owner or the recipient whatsoever  
anyway.  (It would seem the protection being sought is for the  
provider.)  Being culpable for authorization takes the burden of  
reputation the provider would normally carry and places the  
reputation burden onto the hapless email-address domain owner,  
perhaps in the form of user-feedback.


Fenton-DKIM-Threat-02

3.1.  Use of Arbitrary Identities
...
  DKIM is effective in mitigating against the use of addresses not
  controlled by bad actors, but is not effective against the use of
  addresses they control.

----

This effectiveness would be dependent upon the use of '!' (EXCLU)  
authorization.  Such setting however would be incompatible with  
several practices.  To be compatible with today's common practices,  
authorizations would need to be '~' (NEUTRAL) or "open-ended."

It would seem the statement "is effective" should be changed to "may  
be effective only when the '!' authorization is being employed.  This  
'!' authorization is not compatible with many possible uses."

-Doug