[ietf-dkim] DKIM Threat Analysis v0.06

[Douglas Otis]

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