Subject: [ietf-dkim] New Issue: review of threats-01

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2006 09:31:41 -0800

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

---

From: Jim Fenton <[email-masked]>
Date: Sun, 19 Mar 2006 22:17:59 -0800

> Please expand the term "AU" before use in this figure.
Will do.
> can simple emulate the user's MUA and send through the MTA.
This is a bad act we're not trying to address, because it does not
involve address spoofing (unless you are arguing that the attacker, by
proxying through a compromised computer, is in fact spoofing that user's
address).  In fact, I would argue that DKIM is quite effective, because
it limits the attacker to the address(es) corresponding to credentials
on that computer.  Limiting the range of signed addresses the attacker
has available is good, especially when the credentials help identify the
compromised machine.
> your content filters, but that needs to be explicitly stated
That of course is the major argument for SSP, which I should perhaps
mention here.
> my reputation would do exactly the same thing. So, it's not clear
I'm not clear on what you mean by "pointing to example.com".  If you're
saying that a human will probably confuse example.com with example.net,
that is true, but this will not be the case with automated reputation
management that will not confuse the two.
> many cases). Rather argue about the details, I would simply
The likelihoods are speculative but actually have prompted less
disagreement than I expected. Stephen Farrell suggested that taxonomy
and I think it's useful as a broad categorization of the threats.
> can't steal it, but you can certainly use it till the machine is 
Fair enough.  Perhaps "denying export of the public key" is more precise?

> why not simply recommend using them.
Probably because I don't know what the countermeasures are.  Are they
also described in the USENIX paper you cite?
> Please explain how identifying the unsigned content differently helps.
There are a lot of things that could be done, including requiring that
the user push a button to see the unsigned content (Thunderbird does
this sort of thing a lot), rendering the unsigned content on a colored
background (probably only very marginally helpful), rewriting embedded
URLs in the unsigned content to render them unclickable, and simply not
displaying it (invisible is different, I suppose).
> a substantially more serious threat than you imply.
You're right, I over-focused on the cache poisoning threat (as many seem
to be doing lately).  I'll try to word so that the comment as a whole
applies to cache poisoning only.

Thanks for your comments.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Mar 2006 12:33:45 +0000

Hi Eric, Jim,

There're a couple of cases here where Eric is more-or-less
saying "not convinced" or that the document needs to also
mention something not currently covered. Eric - if you and
Jim could work out new text for those cases offline during
the week, that'd really help us finish this document. So
can you guys try to get together sometime to do that during
the week? We can do it on the list, but that'll take longer
and is more likely to generate a flood of messages (will
the flood metaphor be common this week I wonder:-)

Just on a couple of these:

> and I think it's useful as a broad categorization of the threats.

Yep - I take the blame for suggesting these and agree that they
can only be subjective/speculative at this stage. However, I would
maintain that they are useful - some of the threats are niggly
corner-cases whereas others are fairly fatal.

 > also described in the USENIX paper you cite?

I think that, or some similar, reference is a really good suggestion.
However, if we also had a paragraph describing this nicely (hint: Eric
could write one:-) that'd help since I believe there may be a good few
potential implementers that aren't aware of the side-channel attacks
that've been demonstrated.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 20 Mar 2006 07:47:41 -0800

> the flood metaphor be common this week I wonder:-)
Sounds good to me.  I'll work on revising the text (Eric, thanks for
your followup comments) but I would appreciate some suggested text on
the timing attacks.  I'm less likely to get that right without several
iterations.

Eric, I'm happy to get together if you have some time this week.  I'll
be here all week (leaving Friday afternoon).  I'll let you suggest a time.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Mar 2006 10:39:47 -0600

On Mar 19, 2006, at 11:31 AM, Eric Rescorla wrote:

> 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.

> 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.

> 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.

> 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