On July 19, 2005 at 22:17, "Arvel Hathcock" wrote:
I don't think that will be problem because if users start poking around in
the email headers and wondering about the meaning we'd already be in a load
of trouble even without an AR header. There are plenty of things there
already to confuse users. But this does play into what Douglas was talking
about in another thread - namely, that if the "meaning" of the AR result is
ever to be communicated to the user via the MUA these "results" need to be
carefully defined to distinguish between "authorized" and "authenticated"
etc.
Interesting point, and I think DKIM, as it is now, may not easily
distinguish between "authorization" or "authentication" failure as
it is currently defined. For example, if the signature does not
validate, is it due to the From field being modified, from the body
being modified, or a (malicious) someone signed the message with an
unknown key.
From a cryptographic perspective, one can achieve separation if
two separate hashes were computed: One to denote "authorization"
data and one to denote "authentication" data.
Technical Note: What can be done is that a separate hash is
computed for the "authentication" portion. That hash, along with
the "authorization" portion is what gets cryptographically signed.
This way you only are generating only two hashes, with the effect
of "binding" the authorization component to the authentication
component.
This way, if (malicious) message mutation occurs, one can determine
what part failed, and that can be reflected in any status code/message
generated.
One nice side-effect of the separate hash approach is performance. The
authorization component (which will only reflect header information)
can be verified first. It it fails, there is no need to verify the
authentication hash (which would include the message body).
Potential nit pick: If signature verification of the authorization
portion fails, one cannot reliable determine if the sender was
authorized or not. All one can reliably state is that the signature
failed. Actual reason of failure would require an audit.
--ewh