-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Monday, October 18, 2010 3:33 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
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]).
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.
[1] http://tools.ietf.org/wg/dkim/charters?item=charter-dkim-2006-07-03.txt
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html