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
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
