[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DoS and Replay protection for message signatures

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.