Thanks for your comments.
Eric Rescorla wrote:
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.
The intent in section 5 of the threat analysis is to present bad acts
that exist in the pre-DKIM environment, and I agree that this paragraph
probably belongs in section 6.3, "Message Replay".
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.
The focus on DKIM was intentional, since it's the chartering of a DKIM
working group, and not a MASS working group, that is being decided.
Russ has said that he will consider sponsoring multiple working groups
in this space, although the bar will be higher for subsequent efforts.
If an alternative design is determined to be superior, I'm sure it will
meet that bar.
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....
The threat analysis intentionally does not use the word "forgery"
because, based on mailing list discussions, it is clear that forgery
means different things to different people. To many, forgery involves a
false claim of authorship, and DKIM does not make an assertion of
authorship.
As noted in section 4.2, DKIM does not deal with other authorized users
in the other administrative domain, but other mechanisms like
authenticated message submission are available for that domain to apply
to that problem.
I disagree that the motivation for this design is all that relevant. If
there is a consensus that this does something useful, even if it isn't a
complete solution to what motivated us, shouldn't that be sufficient?
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
This is from the -00 draft, and was corrected in -01.
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?
The intent in this section is to give concrete examples, and describe
which ones DKIM addresses.
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.
True, but then it's easier to tell whose computer needs to be remediated.
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?
I agree with quite a bit of what you have to say when DKIM is used by
itself. But a more reliable source address for messages is also
beneficial by being the basis for reputation and/or accreditation, and
when such systems exist (they don't now, because there isn't a reliable
basis to use) users can be trained to expect particular accreditation,
for example when working with their bank. Yes, it won't be 100%
effective because it involves user education. Yes, it's further in the
future.
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.
That, plus the fact that replays can be more-or-less instantaneous,
happening before the revocation can take effect.
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.
On the other hand, if the threat analysis is to deal with the threat
environment (see your very first comment) there isn't a replay attack,
because there is no signature to replay.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org