[ietf-dkim] chained signatures, was l= summary
doug.mtview at gmail.com
Mon Jun 8 11:30:38 PDT 2009
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>
>> 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
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
>>> 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.
More information about the ietf-dkim