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