On 5/3/11 4:25 PM, Murray S. Kucherawy wrote:
Why does the output of DKIM need to include something when the
consumer of that output already has that information?
Because a consumer should/must not have to re-do the work of the DKIM
verifier. Or put it differently: a consumer is just consuming the output
of the DKIM verification process, it will rely on it (provided there's a
trust relation between consumer and verifier), and it normally will not
re-do the work of the DKIM verifier. It has no knowledge of DKIM rules
(bottom up etc.). Just like a MUA has no information about how two MTA's
exchange a mail over SMTP.
The assertion you're making is that the consumer of an API shouldn't need to
maintain any context; the API will give you back all the bits of context you
need to continue as well as the answer you need.
If you feed N bytes of data to a hash function, what you get back is the
resulting hash, not the hash and the source data or maybe the hash and N.
All of the context is still in the API consumer, not in the function that's
giving you what you want.
If you give RSA_Verify() a signature, a public key and a hash, it gives you
back a 1 if they match and a 0 otherwise, not 1/0 and then some of that same
information you gave it. The caller is the part of the system that knows
what the answer is telling you, because it understands the nature of the
function it called.
So it is with DKIM: If you get back an indication from a verifier function
that a signature verified, then the signature covered the lowest From: field
that you presented to it. You know that because that's how the interface
you're using was defined.
An implementation certainly could give you back that From: field's contents
(and OpenDKIM does, if you ask for it), but still I don't see any reason to
make it mandatory.
In the process of finding the bottom of the header stack, DKIM will have
read all headers. DKIM must also count headers as it advances up the
stack. Senders signing with DKIM likely do so to better protect
recipients and to obtain higher use rates. While conventions regarding
header limits may change, headers limited to one are unlikely to have
these limits change due to security issues. It is also likely those
using DKIM conform with current stricter requirements and can signify
this simply by listing them in the signature header field. Refusing to
validate malformed email is important to prevent DKIM results from being
misleading. Counting header fields is trivial compared to public key
cryptography. Not noticing deceptive pre-pended header fields may mean
DKIM could cause more harm than good. Nothing in in DKIM's API needs
to change for DKIM to provide the desired protections being sought.
-Doug
-Doug
I might even go so far as to say returning that From: field is dangerous
since it is not confirmed by anything, so DKIM (which is an authentication
protocol) returning data that can't be validated, even if it was signed, is
quite possibly asking for trouble.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html