[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

[Douglas Otis]

Jim,

Today I'll publish a rough-cut draft for the recognition options that  
have been suggested.  Here is a quick review of your threat summary.



1.1.  Terminology and Model

It would be better to put a place holder for the signer-practices  
query as well.  An alternative to an authorization strategy would be  
effective against many modes of attack.  Once a recognition strategy  
is considered, this signer-practices mechanism changes substantially.



2.1.  Characteristics

This talks about falsifying the "origin address" of messages.  Should  
the base DKIM draft be seen as a means to ensure the identity of the  
author, which I assume this "origin address" is intended to imply?   
Any suggestion that a particular header _may_ have the email-address  
restricted by DKIM  invites open-ended authorization mechanisms that  
have in the past been used to unfairly shift the burden of  
accountability, and may lead to highly dangerous assurances.



2.3.1.  Externally-located Bad Actors

As the majority of abusive email is being sent through compromised  
systems, why should DKIM ignore what can be done to identify these  
sources within the sending Administrative Unit?  That should be a  
primary focus.



2.3.3.  Within Recipient's Administrative Unit

Rather than recommending [I-D.kucherawy-sender-auth-header] headers,  
the MDA could sign and avoid many receiving Administrative-Unit attacks.



3.1.  Use of Arbitrary Identities

"It also does not guarantee the accountability of the signer, since  
that is limited by the extent to which domain registration requires    
accountability for its registrants."

This is a poor use of the word accountability.  Accountability  
implies being held to an expectation.  The signer is always  
accountable for their actions, however their actions may not always  
be trustworthy.

reworded:
A valid signature can be used to properly assign accountability,  
however a valid signature does not imply that the signer can be trusted.



3.2.  Use of Specific Identities

This could be further illustrated by "online-example.com" where  
people do not understand the significance of "-" from that of the  
".".  Continue by also reviewing unicode extensions related to  
RFC2047 and RFC3492, (the Unicode TR 36 reference in the  
international domain names section seems to imply this does not  
affect non-internationalized domains).  Add further examples where  
the domain name is in Puny-Code.  Considering that in most cases the  
native character-repertoire would be different from that of the raw  
Puny-Code, visual examination of the domain name becomes virtually  
meaningless.  Unless DKIM avoids reliance upon visual examination,  
little is gained.  Any DKIM assurances that a signature was verified  
and was in compliance with some practice will only increases the  
success of targeted attacks.



3.2.1.  Exploitation of Social Relationships

"DKIM would be effective in mitigating these acts by limiting the  
scope of origin addresses for which a valid signature can be obtained  
when sending the messages from other locations."

What mechanism is this describing?  After completing section 3.2,  
3.2.1 can not make a statement of effectiveness, nor is this a direct  
function of DKIM.



3.2.2.  Identity-Related Fraud

This does not make any clear statement other than to say that the  
"address of origin" may contribute to fraud.  How does this relate to  
DKIM?



3.2.3.  Reputation Attacks

DKIM will not defeat a DSN with an invalid return-path, as the  
content of the message would be expected to have been changed.  One  
practice similar to or part of the "joe-job" (Spam appearing to be  
from an innocent third party, and named after a victim Joes.com) is  
to invoke a bounce where the return-path is also invalid and used to  
eventually deliver the message.   This would work much like not  
putting a stamp on a letter where the return-address contains the  
desired recipient.  Unless DKIM signatures are checked within the  
SMTP session, an invalid signature may generate the "desired"  
bounce.  As reputation should be based upon verifiable source  
identifiers within the message, reputation would not be effective at  
dealing with invalid addresses when not used by the recipient  
creating the DSN.  Reputation does not deal with message replay abuse  
either.



4.1.  Attacks Against Message Signatures

Why would a Signed message replay have a low impact when the  
likelihood is high?  What identity is being used to accrue  
reputations? The same issue would be involved with compromised  
systems within the originators Administrative Unit.  The Display name  
abuse is only indicated as having a Medium impact, but for the  
majority of recipients, this would represent a significant risk,  
especially if there was any assurances made.



4.1.9.  Body Length Limit Abuse

"Recipients need to use means to, at a minimum, identify the unsigned  
content in the message."

What is this assuming?



Consider dropping the following sections for now:

4.2.3.  Denial-of-Service Attack Against Signing Policy
4.2.4.  Use of Multiple From Addresses
5.  Derived Requirements

-Doug