Threats:
- Adversary gains unauthorized access to domain private key
- Internal thief (black market) of domain private key
This is seems to be along the lines of Section 9.2, though that
section seems to talk mostly about user keys being compromised.
Perhaps that section can be broken into two subsections: one on
malware and user keys, and a second with an emphasis on protecting
private keys under the control of sysadmins.
I agree. A side note would be that private keys will mostly likely be
automated (coupled with some change frequency). So this automation has to be
protected.
- Adversary compromises MUA DKIM signers
See above.
The difference between the two is the entry points and the protected
resources. One addresses the server-side, one address the client-side. From
a business standpoint, I think we are talking about key management
responsibility. From a design standpoint, rethorically, do we really want
the MUA to be signing? Why not just move the responsibility to the MSA or
outgoing MTA? One less threat with user level exploits.
- Adversary attack against non-DKIM community
- Invalid DKIM Spoofing
- Relaxed Policy DKIM Spoofing (High Threat)
I don't understand this.
This same threat has occurred with SPF relaxed domain policies.
The first group of exploited domains will be those who expose a relaxed
signing policy. We used the following legend in IETF-MAILSIG:
Current Sender Signing Policies:
o=~ NEUTRAL (signature optional [,No 3rd party?])
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
New SSP suggestion by Arvel Hathcock:
o=? WEAK (signature optional, no third party)
Adversaries will most likely exploit policies with optional signing and
those who allow 3rd party signing; NEUTRAL, STRONG, WEAK. The verification
decision making process will be indeterminate with these policies (Not a
hard FAIL or PASS).
In addition, an adversary can target non-DKIM sites and provide the illusion
of protected messages. Not much that can be done here until the downlink
software are DKIM aware.
- Adversary removal of signatures
Does this mean that a party relaying the message removes the signature?
Yes. Although, I am having difficulty seeing how the applications where a
party can get its hand on a signed message for stripping purposes that the
sender did not want to send to, but I imagine there could be a honeypot
scams or new and growing ad-centric email services possibly.
In this case, a benign relay may deem it necessary to reduce all possible
end-user ambiquity dealing with DKIM validation. Stripping the signatures
will accomplish this.
Side note: I can see new LEGAL conflicts here. "A email service removing a
DKIM signature does causing tort or harm to reputation of domain."
- Adversary adds "This is a DKIM Safe Message" to body.
- New Social Engineering issues
This should probably be mentioned in Section 9. I'm not sure there
is anything that can be done about it, though.
I agree. Not much can be done here.
- Adversary increases DKIM transaction frequency
I believe this is the point of Section 9.7.
- Adversary increases DKIM payload
Is this different from Section 9.1?
- Adversary promotes BOUNCE attacks
I don't think this is an attack specific to DKIM.
I think the above three threats addresses new possible scalability issues.
As you know, DKIM is a payload (2822) based protocol. Not a 2821 based
protocol.
I understand some have played down this increase of scale issue. But it
might become a source of frustration, especially if DKIM is their own add-on
for mail protection.
I want to come back to this later. Need to go to the airport to drop
daughter off (back to college).
- Adversary attacks known 3rd party servers
Another good point for Section 9.2. If you have a third party doing
some signing on your behalf, it would be worth it to make sure they
have good practices around protection of the key.
- Signers who do not honor OA SSP
I don't understand how this is an attack on DKIM.
Correction:
- Signers and verifiers who do not honor OA SSP
If a message is signed as a EXCLUSIVE policy, then no additional 3rd party
resigning must take place. Conversely, a verifier should raise a red-flag
when it sees a conflicting signing. i.e., 3rd party signed message when the
OA domain policy indicates no 3rd party signing allowed.
Hence, signers and verifiers need to double check policies. The current
protocol has an optimization feature where it only checks for the OA SSP
policy under certain conditions.
I think this optimization is premature. The worst scenarios are still
possible when this optimization is enabled.
- Agents modify email content
I would put this in the "feature" category.
Hand flying over head <g> Explain?
This is your standard benign Mailing List server adding footers etc,
breaking the integrity of any original signing.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim