[ietf-dkim] Not exactly not a threat analysis
mike at mtcc.com
Mon Aug 15 13:33:05 PDT 2005
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.
Eliot Lear wrote:
> I think what you wrote is concise and compelling. As you say, not
> exactly a threat analysis, but I imagine it could go there.
> 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.
>>ietf-dkim mailing list
>>ietf-dkim at mipassoc.org
> ietf-dkim mailing list
More information about the ietf-dkim