ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: What the verifier can do

2006-04-30 05:54:00
Paul Hoffman wrote:
At 1:06 PM -0700 4/28/06, Eric Allman wrote:
The z= tag is only supposed to be used for "diagnostic purposes", not
for computing the hash.

Fully agree.

Changing that would have major implications that we would have to
examine very carefully.

Fully agree, but that doesn't lead to the conclusion that the verifier
*cannot* use heuristics (one of which might be the value of x=) to try
to get the signature to validate.

So, let's have that examination now.

I know that Michael Thomas was doing some work along these lines, to see
how resilient you could be to changes incurred through a mailing list.

At 1:16 PM -0700 4/28/06, william(at)elan.net wrote:
So if mail list changed Subject header field (and for purposes of this
question did not add other fields or changed content data) and there was
a signature in message before that contained original Subject in the 'z'
tag AND now message got to verifying agent - that agent is supposed
to say the signature is invalid rather then use data from 'z' tag to
attempt to verify the signature?

At 1:22 PM -0700 4/28/06, Eric Allman wrote:

Yes.

Fully disagree. The verifier can use whatever means it has, including
using heuristics, to see if the message is actually sent by the
purported sender. One such heuristic is to dissect the value of x= and
see if any parts are different than the current message; if so, try
validating with those parts. Another such heuristic is to notice that
the subject starts with "[foo]", and that is often a sign that the
subject might have been changed after the signature was applied, and to
try to validate the signature without that string in the signature.

The security implications of the verifier taking this route is that a
sender who wanted to spoof a signature could try to put in stuff that
the verifier would try which would be successful. However, doing so
involves creating a pre-image of the hash, which is considered
impossible here and in all IETF work. There is no collision attack here.
So, there is no attack vector in allowing the recipient to keep trying
heuristics until it either finds a changed message that works or gives up.

It is up to the verifier to decide how much effort after the first
attempt it wants to do. The cost to the verifier is a doing multiple
hashes, not doing multiple signature validations.

Ummm, we don't currently run a hash of the headers, just the body. We
currently do the signature validation based on the actual headers, the
body hash, and the dkim-signature. So doing such a verification *would*
require multiple signature validations.

It's been suggested that we adopt another tack, and use a hash of the
headers as well as a hash of the body. So the actual signature
validation would be on two hashes along with the rest of the
dkim-signature header field.

This particular suggestion hasn't received any traction as yet.

        Tony Hansen
        tony(_at_)att(_dot_)com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html