>> 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 [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
