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

[Doug Otis]

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

> On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis <doug.mtview at gmail.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