ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] chained signatures, was l= summary

2009-06-08 14:34:28

On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote:

On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis 
<doug(_dot_)mtview(_at_)gmail(_dot_)com>
wrote:

On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote:

By selecting specific A-R headers to remove, header content might  
be processed post delivery, and then appear to match against some  
trusted domain.

For sure, individual recipients may wish to check signatures etc.  
for themselves, espeicially if they have doubts about the policies  
applied by their local assessors. If the local assessor has  
unnecessarily removed some A-R that is actually covered by the  
signature, then that becomes impossible.

The use of the DKIM l=,  z= and x= features provide a means for  
recipients to separately evaluate DKIM signatures without reliance on  
intermediary assessors.  In addition, the A-R header does not capture  
the IP address when assessing path registration protocols, which means  
that safe recipient reassessment might only be possible in the case of  
DKIM or reverse DNS.

And if they have doubts about the policies of sone earlier mailing  
list expander, they might wish to see exactly what that expander had  
actually done to the message. For such forensic investigations,  
removing useful information (aka "dumbing down") is always a dumb  
thing.

Removal of foreign A-R headers provides better security.  Since A-R  
header fails to capture source IP addresses for path registration  
schemes, the forensic value of this header is very limited, to the  
point of being dangerous.

Reliance upon the A-R header offers providers permission to modify  
messages.  Some providers offer their services free, however there  
remains a profit motive where their security may overlook embedded  
iFRAMEs referencing malware injected into one of their third-party ad  
servers.   A-R header may indicate to recipients that the message  
originated from Big-Bank, but ads might appear from a different  
entity.  In this case, the goal of DKIM is has been lost.    
Unfortunately, the introduction of ads is fairly common, and the  
authserv-ids may not offer a means to consolidate or identify who is  
being trusted.  There are significant risks and problems created when  
dealing with A-R headers.  DKIM without A-R headers does not invite  
questionable practices likely to create many duped victims.   An  
appearance of a message being from someone trusted can be worse than a  
message with an unknown status when the content source is in doubt.

The safest solution would be to remove _all_ A-R pre-existing A-R  
headers from different environments ...

But that's not what the standard says.

Wrong.  See RFC 5451 section 5, complete removal is suggested for  
maximum security.  It also suggests:

"A more robust border MTA could allow a specific list of  
authenticating MTAs whose information should be let in, removing all  
others."

Note that Appendix B.6 of RFC 5451 contains an example exactly  
equivalent to the one I have just given, including the retention  
of A_1 (and even S_1).

IMHO, appendix B.6 is overly optimistic for today's environment.

Maybe so, but that document is a proposed standard, and unless you  
have plans to get it revised, we must try and work with it as it  
stands.  Nothing in that example is contrary to what that standard  
says normatively.

No.  Nor does the RFC warn of encoded headers or header reordering.   
Headers may be altered during handling.  In addition, the "Trust  
Environment"  can use any type of token, and not just those derived  
from a host name.  The lack of uniformity or standardized means of  
ensuring uniqueness means little should be assumed regarding any A-R  
header not generated by the receiving MTA.

-Doug


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