[ietf-dkim] chained signatures, was l= summary
dotis at mail-abuse.org
Thu Jun 4 12:19:34 PDT 2009
On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
> <msk at cloudmark.com> wrote:
>>> WTF is the point of inserting an A-R header if you are not willing
>>> to take responsibility for what you have done by signing it?
>>> And why should anyone else believe your A-R if you have omitted
>>> that elementary step?
>> Because, if you've followed the RFC defining it, the border MTA
>> has removed any others present that could possibly be
>> misinterpreted by internal agents.
> Yes, but that is the MTA at MY border. I would expect the assessor
> at MY border to have indicated some degree of suspicion if the A_R
> header it was about to remove (before substituting its own) was not
> included in the signature that accompanied it.
>> You're not required to sign them, but it's not a bad idea.
> Then why are people on this list not trying to enocourage that good
> practice? Indeed, why are they so vociferously trying to DIScourage
Before A-R headers can be trusted, A-R headers MUST be removed by
incoming border MTAs. See section 1.6 of RFC 5451.
Border MTAs may exchange messages with internal servers that might
process filters where internal routes are influenced by message
content. Whenever removing A-R headers is done on a conditional
basis, this creates gaps in security, especially when trust is placed
upon A-R headers added by a subsequent filtering process. Only
removing A-R headers at the border exactly matching those added by the
receiving domain invites trouble. There are many three-step tricks
that thwart matching techniques, where these headers might appear
differently at some later stage. The safest approach for handling A-R
headers would be to remove _all_ of them as they arrive. After
filtering messages, incoming MTA can decide what they wish to do with
the message. When a filtering process decides to reject a message,
this should be done prior to adding A-R headers, perhaps even after
removing existing A-R headers. A safe process must ensure there is no
overlap between where incoming A-R headers are removed, and where the
incoming receivers add A-R headers to messages.
The issue of A-R headers being trusted only when signed by DKIM runs
counter to their intended use. When it is concluded that MUAs should
independently check DKIM signatures that include A-R headers, this
suggests A-R headers are not very trustworthy, which might be the
case. Whatever leak that allows a bad actor's A-R header to appear
could also find itself inadvertently signed by the incoming domain.
Just check originating DKIM signatures, and ignore A-R headers would
be the safest solution. Use of A-R headers allow providers a means to
visibly modify messages without the recipient being aware that the
visible content had been added by the provider. In general, this
seems like a bad idea with respect to DKIM.
More information about the ietf-dkim