ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-15 13:44:07
I think that there's one other important aspect that's hard
for me state concisely. Utility is often bound up in the network
effect, and though PGP and SMIME solve for many of the threats
-- equally or superior -- they have not achieved any sort of
network effect. I believe that DKIM by design is specifically
trying to address the network effect and make it a goal. We
have made some specific design decisions that are ultimately
traced back to that goal:

1) use of DNS, and our lowering the bar on cryptographic trust anchors
2) lowering the expectation of what is actually asserted (ie, domain
   based rather than individual based)
3) absolutely no attempt to deal with encryption
4) the ability to ride "stealthfully" within the existing
   infrastructure without need to upgrade either MTA's or MUA's
5) ease of deployment at choke points (MTA's), and into existing
   naming infrastructure (DNS)

I'm not sure that I ultimately know where the network effect will
take us -- can anybody really predict such a thing with better than
random odds? But pervasive authentication even with lowered expectations
seems like it will enable a lot of things that point solutions with
higher barriers will cannot.

                Mike

Eliot Lear wrote:
John,

I think what you wrote is concise and compelling.  As you say, not
exactly a threat analysis, but I imagine it could go there.

Eliot

John Levine wrote:

Here's a short list of what I think DKIM tries to accomplish, with the
threat being what happens when it's not accomplished.  Please note
that I use terms like "sender" in a general sense.

1. DKIM makes it easier to detect sender forgery.  The three important
kinds of forgery are:

* Pretending to be someone with a good or neutral reputation to avoid
recognition as someone with a bad reputation (spam)

* Pretending to be someone with a good reputation to take advantage of
that reputation (phish)

* Pretending to be someone with a good reputation to send material
intended to damage that reputation (joe job)

There are other forgery scenarios possible, but these are the ones I
see every day and the ones that seem important to deal with.

2.  DKIM avoids depending on endpoints.  That is not to say it can't
be done at endpoints, but its design is tuned to work on mail servers.
The reasons are that endpoints are hard to set up (because there are
so many of them, and they're unmanaged) and usually insecure.

3.  DKIM matches the ways that mail is sent and received.  ISPs can do
DKIM for their users, list management software can do DKIM on mailing
lists, common kinds of forwarding work, etc.

R's,
John



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


_______________________________________________
ietf-dkim mailing list
<http://dkim.org>

_______________________________________________
ietf-dkim mailing list
<http://dkim.org>