[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]
dotis at mail-abuse.org
Wed Dec 21 14:00:04 PST 2005
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.
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
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
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
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
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
More information about the ietf-dkim