ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM Threat Analysis v0.06

2005-08-10 16:55:29

On Aug 10, 2005, at 3:14 PM, Dave Crocker wrote:

On Mon, 1 Aug 2005 12:13:10 +0200, Dave Crocker wrote:

  * Who are the bad actors?
* Where do they fit into the protocol environment (eg, middle of net)? *
  * What are we trying to prevent them from doing?

DKIM Threat Assessment v0.06

There should be better focus as to the scope of what is being protected from various threats. I think there was general agreement that the domain name is what DKIM is protecting. What are the threats related to the domain name may be another way to view this problem.

Protect the domain!

1. Who are the bad actors? (Characterize them, eg, what resources do they have?)

Although IP based reputation is generally effective at preventing a substantial amount of abuse, there are techniques which cause otherwise reputable sources to act as relays for abusive email. There are additional techniques that depend upon the reliance on the IP address.

Rather than listing entities, perhaps enumerating techniques would be helpful.

IP address reputation weaknesses:

1) Use asymmetrical routing to obfuscate the source of outbound traffic.

2) Utilize messages returned in DSNs where rejection is elicited after acceptance with the bounce-address spoofed. (Joe-Job)

3) Utilize different address space through tunneling techniques. (Trojans or open-proxies)

4) Hijack network access via insecure wireless.

5) Spoof authentication header information appearing to belong to the backup or border MTA.

6) Dynamic address assignment.

7) ISP level NATs

8) Routing exploits.


Domain name reputation weaknesses:

1) Obfuscated HTML links in email messages that appear to belong to a reputable domain.

2) Acquisition of recently abandoned domain names.

3) Employed low wage workers to acquire free email accounts.

4) Spoofed mailbox domains to fool recipients.

5) Inject messages through compromised systems with pre-registered client services that automatically authenticate with the provider's servers.

6) Hijack network access from provider using address based server access.

7) Rapid deployment of domain names by registrars.

8) Hoarding or squatting of domain names.


IP based reputation also has an unfortunate side affect with respect to the domain. An IP address does not discern separate administrative domains, and therefore IP based reputation often creates collateral damage when applied to shared address space.

Actors, both good and bad, are senders of email. A "sender" is any agent in the transit path that creates a message or that moves it towards a recipient.

Perhaps we could stick to the domain theme, and describe the entities as accountable domains. This would tend to focus less on the average consumer, but remain more administrator centric.

Bad actors create new messages, or modify existing messages, for the purpose of asserting an invalid originator, sender or recipient identity or to add
unauthorized or undesired content.

I wonder how this is useful. Bad people lie. Again, perhaps examining how our current defenses are failing with respect to reputation would be useful. I know some hold an ideal of being able to once again create a closed environment and only permit those that have been accredited, when will this be practical? Are we being nostalgic thinking this will be an email model for the future?


For any email, the recipient might view the author or sender as a good or bad
actor.

This is where we start slipping down the slope with claims being made about the individual rather than the domain administrator.



That is, they might want to receive the message or they might want not to receive it, according to criteria specific to that recipient. Nonetheless, there are classes of mail that are commonly assessed to be unacceptable. The
two major examples -- and they overlap -- are:

        a.    Spam -- unsolicited bulk email (UBE), and

This represents a general failure of a reputation system. Beyond that, without enumerating these failures, I don't see the value in this statement. We don't want to define spam.


b. Forgery -- messages that state false authorship (Joe Job) that might be known to the recipient, and might attempt to trick the recipient into
disclosing private information (Phishing).

I view these two techniques differently where neither should resolve down to the author of the message. Can we conclude that assuring the individual is beyond the scope of DKIM? The text that follows this is more wanting to know who the author is stuff. I think we can make better progress getting that off the plate. At least until there is a user-based key service able to handle such a task. For now, assume the DNS service being sought is limited to protecting the reputation of the domain and shoring up domain related reputation services. One of the goals that should be part of improving protection for the domain, would be to dramatically reduce reliance upon IP address reputations.

-Doug

_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim

<Prev in Thread] Current Thread [Next in Thread>