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
