On 4/28/11 12:00 PM, Rolf E. Sonneveld wrote: > 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. 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. > > 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. > So if there are two From's, and only one signature verifies, the upper > layer application knows for which of the two From addresses the success > status applies. Then the upper layer applications are enabled to perform > whatever they want to do. Wouldn't that also mitigate the problem of > multiple singletons present? > > As the From: address is mandatory input for the signature, it may be a > logical step to also make it mandatory in the output? Don't dismiss the fact DKIM accepts input that could have been easily established as bogus during its handling.
Validating input does not represent an ugly Layer violation. However, not validating input represents an evil Trust violation. Policy conveyed to recipients likely depends upon DKIM's valid signature result combined with the signature header field's "d=" parameter when making basic acceptance decisions that vary from domain to domain. Would one describe the expected use of DKIM to be a layer violation? Since DKIM only requires the From header field be confirmed by its signature, failing an easy check for unsigned pre-pended From header fields clearly indicates DKIM can not be trusted! DKIM MUST verify the form of critical elements and not simply assume they are valid. DKIM's output MUST accurately reflect the validity of the signature AND the validity of message format related to the From header field AND the validity of the A-Label used to reference the public key. These checks are not a protocol layer violation. Not making these checks would be misleading and a violation of trust. Do not assume recipients will be protected by more complex output not reflected in the elemental output of a valid signature and its domain. DKIM is a security mechanism. Negligence can not be escaped blaming the underlying protocol since it does not make any additional assurances of trust. That is clearly the role accepted by DKIM for good or for evil. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
