ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

2009-06-12 14:30:21

On Jun 12, 2009, at 4:47 AM, Charles Lindsey wrote:

On Thu, 11 Jun 2009 15:34:19 +0100, Michael Thomas <mike(_at_)mtcc(_dot_)com> 
 
wrote:
J.D. Falk wrote:
Michael Thomas wrote:

There is *NO* *REASON* to strip signatures. NONE.

In fact it is HARMFUL.

Well for starters, RFC4871 section 3.5:

And from RFC2822 section 3.6:

And then RFC4871 section 4.2 goes on to say:

In general +1 to all that, though I am not as passionate as Michael,  
and can accept that hopelessly broken signatures _might_  
occasionally be  removed.

But by and large, I do not want to prevent Forensics.

Agreed.  This concern has was muddled by J.D's suggestion that second- 
hand RFC5451 A-R headers can be used in lieu of DKIM signature  
validation (and even that DKIM signatures could be removed).   Some  
cautionary advice for this is needed.  Mike is right to express concern.

One the fundamental problems would be in respect to not knowing what  
"authserv-ids" are trusted by recipients, and email from different  
sources might be commingled.

To ensure that reliance upon the suggested A-R alternative to valid  
DKIM signatures does not become an easy avenue for exploitation, A-R  
headers should be removed or defanged whenever second-hand  
originations would be in doubt based the message content.  This goes  
beyond just first-party trust environments removing obvious "authserv- 
ids" conflicts.  Inhibiting exploitation requires A-R removal to  
include those headers not confirmed by valid DKIM signatures.

Until A-R filtering become universally adopted and there is consensus  
about header encoding/decoding handling, acceptance of second-hand A-R  
headers should be conditioned upon being contained within a valid and  
trusted DKIM signature, or matching with the immediate trust  
environment.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html