On 4/28/11 9:10 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Thursday, April 28, 2011 12:01 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary
Right. I strongly believe in the layered approach. However, that's
exactly the problem here. Like with IP and SMTP and any layered
application, the upper layer is dependent on what the lower layer
provides it with. If DKIM only enforces:
d= and
verification status
to be output, then the layered applications you describe (ADSP, domain
reputation, whatever) doesn't (always) have the means to do their job.
Or maybe they would have sufficient information if there was a single
DKIM signature present and all singletons are only once present in the
header.
But that's not true. ADSP asks the question: Did this message have a valid
author domain signature? The output of a set of "d=" names that verified is
sufficient to answer that question: Either the author domain is in that list,
or it isn't.
[Note: ADSP is used here just as an example layered application.] What
is the author domain in case there are multiple From headers, if DKIM
doesn't specify it to the upper layer? You gave the answer, but see below.
Since signatures can break for more reasons than you can count, the only
valuable signature is a good one.
Agreed.
Thus, a reputation implementation should only be interested in domain
names whose signatures passed.
Agreed.
The output thus also satisfies that requirement.
The only utility in revealing failed signature information is forensics.
Let's concentrate for the moment on good signatures for this discussion.
That sort of debugging function doesn't need to go in a protocol
specification.
However, in practice we will see multiple DKIM signatures, with
possibly multiple From's. Which of the From's is associated with which
of the successfully verified signatures? For the d= payload, this
question is not interesting. But for the still-to-be-designed layered
applications, this question can become quite important.
There are three easy answers to that:
a) The specification presumes valid input, and warns signers and verifiers to
be sure that those rules have been observed.
I'm not sure this is an easy answer, given the amount of discussion on
this topic ;-)
b) If an application is presented two different From: fields and handed them
to DKIM, and the signature passes, the bottom one is the one that was signed.
We verify from the bottom up specifically to deal with the case where a
message has "m" signed instances but "n" total instances, where "m" is less
than "n".
Right. But this is DKIM logic, 4871bis. By not specifying the address in
the output, it means that the upper layer application needs to follow
the DKIM spec (4871bis) in order to be able to determine which From
address it should use for whatever function it provides (e.g. determine
1st vs 3rd party signature or determine whether something is an author
domain signature). In other words: by not specifying this type of
information in the output of DKIM we create a layering violation, as the
upper layer needs to be aware of the way DKIM deals with this kind of
situation. Or we rest with a situation where all sorts of functionality
in layered applications will never be developed, as the required
information is missing.
c) If an application is presented two different From: fields, it could just
as easily reject the message as invalid without even trying to apply DKIM to
it.
Yep, but then it has to check something that is already prescribed in
RFC5322, thus causing another layering violation.
From the design view of DKIM I know we should not want it, but what if
we would add the From address as a third _required_ output parameter?
With From: I mean: that particular From address that was used to verify
that particular signature for which the success status is handed over.
It's always the bottom one. (More generally, if the signer signed "n" of
them, and the signature passed, the bottom "n" of them were signed.) If you
signed the top one, verification will fail, unless they were both the same
anyway.
Again, this requires DKIM knowledge in the upper layer application.
As the From: address is mandatory input for the signature, it may be a
logical step to also make it mandatory in the output?
Given the above, do we still need to?
I'm afraid we do have. However, I agree it doesn't fit in the current
limited scope of DKIM (deliver 'd=' as the payload).
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html