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