GENERAL COMMENTS
This document reads much more like an analysis of DKIM than it
does like a threat analysis of the environment in which DKIM
will be deployed. There's a subtle but real difference here.
Consider, for instance, Section 5.2.3 says:
Reputation attacks of this sort are sometimes based on the
retransmission (often referred to as a "replay") of a legitimately
sent message. DKIM provides little protection against such acts,
except that the key used to sign the original instance of the message
can be revoked. Other reputation attacks, involving the fabrication
and transmission of a fictitious message, are addressed by DKIM since
the bad actor would not, without inside assistance, be able to obtain
a valid signature for the fabricated message.
Now, it may be true that DKIM doesn't address this issue, but it's
certainly possible to address this issue (arguably well or badly)
in a message origin signature system.
What I would have expected in a threat analysis of this type is that
one would start with a relatively broad view of the type of system
one was considering developing ("server-based message-based signatures
to prevent mail forgery") and then describe potential attacks on
such systems and the types of countermeasures that can be used to
protect against them. What I see here assumes that the system to
be developed is essentially DKIM and asks how DKIM can be attacked.
That's only somewhat useful for determining whether DKIM should be
standardized and not at all useful for determining whether alternative
designs would be inferior or superior.
A related issue is the focus on forgery as the end-goal. The reason
that people are interested in stopping forgery is that they
believe that that can be used to block spam (see Section 2, where
this is explicitly stated). Indeed, if what you wanted to do
was stop message forgery as a general case, you would have to
consider the issue of forgery by other authorized users in
the same administrative domain, which generally leads to an
S/MIME style solution. What motivates this particular design is
the spam application and I think that that requires a real argument
that this approach will be useful in stopping spam, not just
saying that stopping forgery is good and this stops forgery, so....
SPECIFIC COMMENTS
S. 1-3:
These sections do a pretty good job of laying out the basic
threat environment.
S. 4.3:
Bad actors may also exist with the administrative unit of the message
^^^^
within
S 5:
One of the most fundamental bad acts being attempted is the delivery
of messages which are not authorized by the alleged originating
domain. As described above, these messages might merely be unwanted
by the recipient, or might be part of a confidence scheme or a
delivery vector for malware.
This seems to me to be too concrete. At a meta-level, the bad
act being attempted is the delivery of messages which the receiver
doesn't want to see (see Section 2 again). What's the necessary
connection between that and sending forged e-mail?
S 5.2.1:
Note that some such e-mail propagated worms
really did come from the person who they claim to come from,
because that person's computer has been taken over.
S 5.2.2:
Well, it's certainly true that much e-mail based fraud involves
forging the sender address, it's not clear that this kind of
forgery protection will help. Consider how a typical phishing attack
works:
(1) attacker sends forged mail from <addr>@legitimate-site.com
This message contains a link to
http://address-that-looks-like-legitimate-site.com/
(2) Victim clicks on link. Note that this is can be an SSL link
with at least a semi-legit cert.
This attack works because the victim doesn't do a sufficiently good job
of checking that the URL that he's connecting to actually corresponds
to the site he thinks he's connecting to.
Now, in an environment where DKIM is deployed, the situation would
differ in that From address in the mail would contain
address-that-looks-like-legitimate-site.com/
Now, in theory, of course, the user might notice that the From
address was wrong, but since the entire attack is premised on the
notion that he doesn't adequately check the URL in the browser
location bar, why should we expect him to do a better job of
checking the From address?
This is acknowledged to some extent in 5.2:
Similar types of attacks using internationalized domain names have
been hypothesized where it could be very difficult to see character
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.
But doesn't this effectively say "DKIM (or any sender signing scheme)
doesn't work against attacks that attempt to involve impersonating
a specific source address"? What class of specific impersonation
attacks does this technology actually work against in practice?
S 5.2.3:
I don't see how you can reasonably deal with replay attacks
by revoking the key that was used to sign the message. This
enables a trivial DoS attack on any message sender--just
get some messages from that sender and generate some replays.
S 6.3:
Again, I realize that the DKIM designers have chosen not to
handle replay, but that doesn't mean there's no way to handle
it with a server-based signing scheme. This seems like exactly
the kind of issue that a threat analysis should cover.
-Ekr
_______________________________________________
ietf-dkim mailing list
http://dkim.org