ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Data integrity claims

2010-10-18 18:18:46
-----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