On Aug 5, 2005, at 12:47 AM, Earl Hood wrote:
On August 4, 2005 at 13:50, "Arvel Hathcock" wrote:
However, message signatures offer _no_ authenticated identifier
prior to
resources being committed.
Such is the nature of message signatures in headers. But, there
are still
substantial resource savings because, although you have to go as
far as the
DATA command and expend some bandwidth and disk (or RAM) to accept
the
message, you can always verify the signature before going any
further. In
my MTA's case, DKIM can lead to the rejection of a message which
represents
SUBSTANTIAL resource savings because the message won't have to go
through
subsequent content-filtering (at the system and user levels), anti-
virusing,
or SpamAssassin'ating.
You could potentially save even a little more if the data that
is signed is completely in the message headers. For example, if
a separate hash of the body is computed and placed in the
DKIM-Signature field, the cryptographic signature would be limited
to header only data while still protected the integrity of the
body.
If the signature fails, there is no need to compute the hash
of the body.
The separate hash of the body also allows for limited verification
of a message when the body data is not available.
This sounds like a good idea, but how would you sign the hash used to
develop the signature? Perhaps as a diagnostic, a simple checksum of
the body could be placed within the signature to confirm the body has
been altered, and could be a reason the signature has failed. I like
the idea of dropping the body hash into the signature header, but
this seems to demand two separate signatures and this would be bad.
The network and IO resources can not be defended with just a
signature mechanism alone. There are ways to defend these resources,
but they currently depend upon the IP address. This seems to degrade
the benefit of establishing a name upon which reputation would be based.
Normally DKIM does not confirm the local-part of an email address.
DKIM verifies a domain that could be compared against various mailbox-
domains. Be careful about making claims that DKIM prevents spoofing
or phishing. I would also be careful about making claims that DKIM
will prevent bogus DNS messages or be effective against Joe-Jobs
without significant use of the Junk folder.
DKIM verifies a domain that can be held accountable for signed
messages. When there is a problem, it should be reasonable to expect
that this domain can take action to correct issues of abuse. This
should include preventing replays of their signature. Normal methods
to limit damage to their IP address reputation is to use rate
limiting, and to monitor sending logs. DKIM however can not defend
the reputation of the domain when based upon signature verification,
because it currently lacks any means to deal with the replay
problem. Adding replay prevention should be relatively simple,
provided the goals are focused upon what DKIM actually provides.
-Doug