> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Douglas Otis > Sent: Monday, October 18, 2010 3:33 PM > To: ietf-dkim@mipassoc.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
