[ietf-dkim] Review of draft-fenton-dkim-threats-01

[Jim Fenton]

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