On 5/4/11 1:25 AM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Tuesday, May 03, 2011 3:56 PM
To: Murray S. Kucherawy
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain
Identity"
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.
For a scenario where a caller is calling a DKIM milter which in turn
calls an API, this is all true. But DKIM will be/is deployed in many
more scenario's. Consider scenario's like:
* there can be one or more hops between verifier and consumer
* between verifier and consumer MTA's can re-order From headers,
* or remove From headers if there is more than one of them present.
* What if Postini and MessageLabs are going to use DKIM for inbound
traffic for their customers and want to communicate the DKIM
verification results to the consumers within the mail infra of
their customers?
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.
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.
But then DKIM is only authenticating the d= and we should no longer
position DKIM as being 'effective in defending against the fraudulent
use of origin addresses'.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html