ietf-dkim
[Top] [All Lists]

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

2009-06-04 15:24:12

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(_dot_)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  
it?

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.

-Doug

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

<Prev in Thread] Current Thread [Next in Thread>