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:
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.
NOTE WELL: This list operates according to