On Mar 19, 2006, at 11:31 AM, Eric Rescorla wrote:
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.
The risk within the AU might also mean individual systems submitting
messages, rather than the signing MTA itself. Each MTA should
utilize a unique key to track problems related to compromised signing
systems. If the compromise is that of user authentication, then that
would represent yet another type of attack. The area where DKIM can
also help is in locating compromised user systems by third-parties
for reporting/blocking purposes. This tracking ability would be
another advantage that could be afforded by DKIM. The last point is
not a minor concern as this represents a substantial avenue for abuse.
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.
A filter will not be likely to block this type of exploit, but
message annotation helps.
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.
This argument assumes that DKIM signature are used as a basis for
acceptance. Without a method to correlate the signature with the
signing system. Sender-ID allows too much network amplification.
This leaves perhaps HELO and PTR associations as an alternative.
There are two problems for DKIM being used for acceptance even after
vetting the name with a reputation service. One would be a bad actor
sending themselves messages and the other would be a competitor
abusing a promo and sending it to wrong, but influential, people to
ensure they become blocked. Of course, that would assume the
reputation service combines the message envelope with the message for
making an assessment, which would not be proper. Without message
envelope correlation, DKIM does not offer much value for accepting
email except in a few cases. Those few cases may then become plump
targets.
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.
Another aspect of this problem comes from various corporate
recommendations on the use of Sender-ID in conjunction with DKIM to
abate a message replay problem. Sender-ID however greatly
facilitates DNS and network attacks. HELO verification and DKIM-
Domain PTR EHLO association lists do not threaten DNS or the network
and yet provides the same protections from replay abuse. (Envelope
and message correlation.)
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html