Michael Thomas provided an early draft of his pseudo code for DKIM
verification.
http://www.imc.org/ietf-mailsig/mail-archive/msg01974.html
I modeled this algorithm it does not completely protect against all the
possible
outcomes.
To see this, consider all the possible verification result states.
There are two parts to the verification:
$result.verify
$result.policy
Where
$result.verify is the public key signature verification result,and
$result.policy is the Originating/Address/Sender Signing Policy.
The possible values for $result.verify are:
NONE
PASS
PASS 3PS (3rd party Signed)
FAIL
FAIL 3PS (3rd party Signed)
The possible values for $result.policy are based on the defined DKIM
signing policies.
NONE (no policy [1])
o=? WEAK (signature optional, no third party, see [2])
o=~ NEUTRAL (signature optional, 3rd aparty allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
[1} a NONE policy is possible where there is no declaration for a SSP.
[2] Arvel suggested another policy called WEAK which satisfies a
signature optional but not allowing 3rd party signers.
Taken together you have 5 x 7 or 35 possible outcomes. Since the USER
policy is not well defined (I dont' understand it), I will leave it out
for now leaving us with 30 possible outcomes.
I will draw the outcome table in text mode. View it in fixed pitch mode.
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verifcation 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 |
+------------------------------------------------------------------+
The table is based on the current specification. It applies logic to
honor the OA SSP.
For example, an EXCLUSIVE policy can only be accepted when the non-3rd
party signature verification is successful (PASS). If the signature
verify fails, a possible warning may be shown, but the idea of how it is
displayed to the MUA is not the main point with the table. The goal is
the determination for the automation for acceptance and rejection which
of course can be local policy based.
Analysis of Spoofing, Phishing, Reply Attacks:
When a SSP exist, DKIM systems will need to honor the SSP at the verify
level as well as any (re)signing level. This is the only way a high
trust will be gained where a possible message acceptance, rejection or
notification to the MUA can be provided with a high level of confidence
in the result.
The key benefit comes with a SSP EXCLUSIVE policy. Since only the OA domain
the only possible signer, any 3rd party signing must be restricted.
The DKIM verification states with the highest potential for attacks is when
no SSP exist ($result.policy = NONE). If the OA has no DKIM policy,
then any other DKIM signing system can begin an attack by seeking a
domain which is not DKIM compliant. At best, the MUA can be warned with
a possible message:
"This message is DKIM validated, however, please note the
original author (show address) has no DKIM signing policy."
See Reply Attack Analysis below.
Attacks are still possible at other states when the policy is relaxed
(no signing required) and 3rd party signing is allowed.
Spoofing:
DKIM spoofing (using a From: from a known OA SSP system) will be
addressed as longed as OA SSP is always checked. If the signer is a 3rd
party and the OA SSP is STRONG (optional, 3rd party allowed), a
consideration to notify (warn) the MUA can be made.
Phishing:
Phishing is the worst form of spoofing because it depends very much on
the trust the user has with the sender. It has two components:
- mail from known senders
- mail from unknown senders.
The problem is reduced to mostly unknown anonymous senders when the
message is signed with strong or exclusive policies since this be
appear as a spoof.
In my view, the phishing problem is more prevalent with high value email
(banks, eCommerce services, etc). These organizations can benefit with
non 3rd party signing and required signing policies.
Reply Attacks:
The easiest example of a DKIM reply attack is a malicious 3rd party
signing mailing list distribution.
However, this malicious server could only use a OA which either binds to
the malicious signing domain or has no policy at all. It could not use, for
example, a member address who has a non-3rd party signing policy for the
From address.
This means using your address for From: address distribution spoofing
can be protected with DKIM.
So in my opinion, I can only see this type of malicious server acting
as a spam server where the From user is anonymous (unknown).
This will most likely required other methods (IP PATH or reputation
analysis) to protect against these transactions.
The point of this exercise is that if the DKIM signers and verifiers are not
programmed to check the OA SSP, then very little will be gained with DKIM.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com