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