[ietf-dkim] Not exactly not a threat analysis
dotis at mail-abuse.org
Mon Aug 15 00:45:15 PDT 2005
On Sun, 2005-08-14 at 22:30 -0700, Dave Crocker wrote:
> On Sun, 14 Aug 2005 16:42:01 -0700, Jon Callas wrote:
> > > 1. DKIM makes it easier to detect sender forgery. The three important
> > > kinds of forgery are:
> > >
> > I think I'm in violent agreement with you. I'd state it slightly differently.
> I'm suggesting some minor changes, only to tighten it up a bit:
> There is nothing in an ordinary email message, except for the RCPT TO line
> and the IP address of the host that sent it to you, that is a reliable
RCPT TO is not a reliable identifier, nor one that would really
establish any trust of the message. Often the RCPT TO identifier is
invalid to induce a message bounce. I guess this statement would be
assuming the message was delivered to a local mailbox, but so what?
> A validated DKIM signature lets you take some reasonable subset
> of the message you received and know that it came from a designated source.
There is nothing requiring a signature be bound to any sub-set of the
message. In addition, there is no existing convention for communicating
such binding reliably to the recipient. Statements that use the terms
"you" or "sender" should attempt to clarify who is playing the role of
"you" or "sender".
> The main benefit of DKIM is that a validating agent can know where the
> message came from.
The signature does not indicate the actual source of the message. In
fact, the signature is independent of the immediate source of the
message and this creates risk should the signature be used as a basis
for acceptance under such a false impression.
| The assured benefit of DKIM's verified signature is authentication of
| the domain accountable for permitting the initial introduction of the
| message. DKIM does not indicate who within the domain is accountable
| for the message. DKIM only indicates an accountable domain best able
| to respond to reports of abuse.
| Optional assertions may attempt to constrain headers within the
| message to be related to the signing domain. Such relationship will
| not encompass the local-part of a mailbox-address and is out of scope
| for DKIM. Even policy assertions regarding a domain can not be
| reliably communicated to the recipient, which precludes any claims
| or justification that depends upon such communication.
> This is more reliability than email source identification has ever
> had before.
Reliability would be a poor way to describe a fragile signature scheme.
| DKIM provides a means to authenticate the initial source of a message
| with a name, as opposed to the immediate source of a message with an
| IP address. This differences helps eliminate much of the collateral
| damage that may occur when limited to using only the IP address of the
| immediate source as a basis for acceptance.
Take some of the weaker and more contentious items off of the table.
DKIM is not about preventing forgery. Such a statement confuses
assurances of the message's author with that of the domain granting
initial access. The concept of the author should be left to S/MIME and
The goal of wide deployment necessitates a narrower scope. Don't let
DKIM become a house of cards built upon a set of assumptions that
'could' be true, when you tilt your head. By limiting DKIM to only
providing an accountable domain and saying nothing about what may or may
not be true about anything else in the message, this still be worthy of
of merit. Consider the assertions which may attempt to add constraints
to headers secondary at best.
More information about the ietf-dkim