[ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

[Jon Callas]

On 9 Aug 2005, at 5:23 PM, Eric Allman wrote:

> I'm not sure that we aren't in agreement here.  But I'm also not sure 
> that we are.
>

To toss my commentary in, I think we're within epsilon of agreement, 
for many epsilon.

I find it helpful when I think of this to look at both sides of the 
protocol, the sender and the receiver. When I am the receiver, a DKIM 
signature tells me that (to use you as an example because your message 
provides a particularly juicy one) that "sendmail.org" has taken 
responsibility for the message. There's also this other bit of 
qualification -- "eric+dkim" which is utterly irrelevant to me. It 
might be interesting, but it's irrelevant. I know nothing about 
"eric+dkim" which could be a "user" or not. (As a human being, I 
strongly suspect that there is no actual account on a mailserver for 
"eric+dkim" -- I suspect that there's actually an "eric" and the 
"+dkim" part facilitates internal mail processing.)

So I validate the DKIM signature and when it validates I pass it on to 
other parts of the mail processing system that process properly 
authenticated email. Likewise, if it doesn't verify, I toss it off into 
whatever subsystem handles invalid signatures.

That's it.

Now, on the sender side of the system, "eric+dkim" provides valuable 
information for me. It lets me, as we know, use a different signing key 
for it and other cute infrastructure setup tricks. But the most 
important thing it does is to provide signed information to me about 
valid, but improper messages. If an outside entity comes whining to me 
about the content of a properly signed, validated message, then I know 
whose knuckles to rap over it.

The i=/g= mechanisms are mechanisms for the *sender* that allow the 
sender to partition the keyspace, provide internal accountability, and 
so on. But they do not alter the fact that the *meaning* of the 
signature is at the domain level.

	Jon