[ietf-dkim] Output summary

[Rolf E. Sonneveld]

On 4/28/11 9:10 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld at sonnection.nl]
>> Sent: Thursday, April 28, 2011 12:01 PM
>> To: Murray S. Kucherawy
>> Cc: ietf-dkim at mipassoc.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