S 1.1: Please expand the term "AU" before use in this figure. S 2.3.2:
Bad actors in the form of rogue or unauthorized users or malware- infected computers can exist within the administrative unit corresponding to a message's origin address. Since the submission of messages in this area generally occurs prior to the application of a message signature, DKIM is not directly effective against these bad actors. Defense against these bad actors is dependent upon other means, such as proper use of firewalls, and mail submission agents that are configured to authenticate the sender. I think this understates the risk. Because the attacker directly controls the compromised computer, he has access to all the user's authentication credentials and therefore firewalls and mail submission are ineffective against this attack. The attacker can simple emulate the user's MUA and send through the MTA. S 3.2. differences in popular typefaces. Similarly, if example2.com was controlled by a bad actor, the bad actor could sign messages from bigbank.example2.com which might also mislead some recipients. To the extent that these domains are controlled by bad actors, DKIM is not effective against these attacks, although it could support the ability of reputation and/or accreditation systems to aid the user in identifying them. Actually, the attacker doesn't need to control the domain he's forging mail from, as long as the domain owner doesn't represent that he signs his messages. Yes, there's an argument to be made that the messages in question will not otherwise pass through your content filters, but that needs to be explicitly stated if that's your theory. S 3.2.3. Another motivation for using a specific origin address in a message is to harm the reputation of another, commonly referred to as a "joe- job". For example, a commercial entity might wish to harm the reputation of a competitor, perhaps by sending unsolicited bulk email on behalf of that competitor. It is for this reason that reputation systems must be based on an identity that is, in practice, fairly reliable. I don't buy this argument. Say that I were the owner of "example.com" which has a strict (always sign) policy and I decide I want to spam. I simply use some other domain (e.g., example.net) which doesn't have that policy and send spam pointing to example.com. When people claim that I'm the spammer I say "hey, it's not signed. must be a Joe Job". So, given this obvious mechanism for preserving plausible deniability, it seems to me that an attacker who wants to damage my reputation would do exactly the same thing. So, it's not clear how signing helps here. S 4.1. It's not clear to me where the likelihoods for these attacks come from. They seem quite speculative (and in my opinion wrong in many cases). Rather argue about the details, I would simply remove them. S 4.1.2. are not practical to use. Other mechanisms, such as the use of dedicated hardware devices which contain the private key and perform the cryptographic signature operation, would be very effective in denying access to the private key to those without physical access to the device. Such devices would almost certainly make the theft of the key visible, so that appropriate action (revocation of the corresponding public key) can be taken should that happen. You need to be concrete in what you mean by "access" here. Yes, you can't steal it, but you can certainly use it till the machine is re-secured.. S 4.1.3. An MTA probably has are enough variables (system load, clock resolution, queuing delays, co-location with other equipment, etc.) to prevent useful observable factors from being measured accurately enough to be useful for a side-channel attack. Furthermore, while some domains, e.g., consumer ISPs, would allow an attacker to submit messages for signature, with many other domains this is difficult. Other mechanisms, such as mailing lists hosted by the domain, might be paths by which an attacker might submit messages for signature, and should also be considered as possible vectors for side-channel I'm not convinced by this argument. The appropriate reference here is "Remote Timing Attacks are Practical" from USENIX Security 04. One of the key things to remember about side channel attacks is that enough samples let you factor out the noise. I'm not sure why you raise the issue this way, because there are known countermeasures to timing attack on RSA. Rather than claim that the attack doesn't apply, why not simply recommend using them. S 4.1.4. If the verifier observes body length limits when present, there is the potential that an attacker can make undesired content visible to the recipient. The size of the appended content makes little difference, because it can simply be a URL reference pointing to the actual content. Recipients need to use means to, at a minimum, identify the unsigned content in the message. Please explain how identifying the unsigned content differently helps. 4.1.12. Falsification of Key Service Replies Replies from the key service may also be spoofed by a suitably positioned attacker. For DNS, one such way to do this is "cache poisoning", in which the attacker provides unnecessary (and incorrect) additional information in DNS replies, which is cached. DNSSEC [RFC4033] is the preferred means of mitigating this threat, but the current uptake rate for DNSSEC is slow enough that one would not like to create a dependency on its deployment. Fortunately, the vulnerabilities created by this attack are both localized and of limited duration, although records with relatively long TTL may be created with cache poisoning. I'm not sure why you say that the vulnerabilities are "both localized and of limited duration." This may be true for cache poisoning, but it's less true for name server hijacking or impersonation. Given that we know that spammers hijack BGP blocks, this seems like a substantially more serious threat than you imply. -Ekr _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
