On 10/18/10 4:15 PM, Murray S. Kucherawy wrote:
On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote:
Should the charter of a security related protocol need to
anticipate minor modifications to a verification process, that
appears essential for ensuring a DKIM signature is not
inappropriately associated with an incorrect From header field?
Any effort, security or otherwise, needs to scope itself correctly.
We, for very good reasons, chartered ourselves originally to come up
with a system that requires minimal infrastructure changes.
I claim that inserting an Authentication-Results field is minimal, as
it is incremental. But if we also claim MUAs and users pretty much
ignore that, which is the case today, then it (or any solution that
is strictly an annotation of some kind) fails to have the protective
impact you're seeking. The only option then is to obstruct delivery
in some way, and that is not incremental and thus not minimal, and
certainly pushes the boundaries of our charter (e.g. [1]).
Ensuring an inappropriate DKIM PASS result is not conveyed through _any_
results mechanism when there are multiple From header fields is the
_only_ means able to deal with not knowing how the information will be
used.
For DKIM to play a role, it must affect how a message is handled, and/or
how it is displayed. There is no way to know which. In either case,
returning a DKIM PASS when there are multiple From header fields
represents a result that is easily exploited. Since multiple From
header fields violate RFC5322, there should not be a problem in having
DKIM require a MUST return PERMFAIL in such a case.
There is little to justify even checking the validity of the signature
for multiple From header fields. Advice indicating these messages
should be refused seems wholly appropriate, but this might conflict with
a desire to leave interpretations of DKIM results be defined by a policy
layer that specifies appropriate actions.
Rather than expecting changes to a plethora of consumers of DKIM
results, which might be used for sorting or display, ensuring
PERMFAIL occurs whenever replicate From header fields are detected
ensures DKIM will not be complicit in deceiving consumers of its
results.
This, again, fails to deliver on your stated goal since the PERMFAIL
result is almost completely invisible. On the other hand, if you
claim MUAs will adapt to DKIM to show what parts of a message were
covered by a validated signature, then we don't really need to
provide any normative requirements because MUAs have already figured
out what they need to do.
An MUA is only one of many different DKIM results consumers. The MUA
may highlight a From header field when signed by an Author Domain, or
annotate the domain offering a valid DKIM signature. Either way,
ensuring the DKIM result is PERMFAIL is the only sure method to ensure
exploitation is thwarted.
Are you suggesting DKIM should advise consumers about when PASS should
be ignored, and about critical checks that were skipped? This of course
would be due to DKIM's lack of format compliance checking of elements
bound to the signature. I too am willing to support Jim's text as being
a reasonable alternative to kicking the can down the road.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html