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>
|
- Re: [ietf-dkim] misusing DKIM, was chained signatures, was l= summary, (continued)
- Re: [ietf-dkim] misusing DKIM, was chained signatures, was l= summary, John Levine
- Re: [ietf-dkim] chained signatures, was l= summary, Michael Thomas
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
- Re: [ietf-dkim] chained signatures, was l= summary, John Levine
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
- Re: [ietf-dkim] incompetent list managers, was chained signatures, was l= summary, John Levine
- Re: [ietf-dkim] chained signatures, was l= summary, Murray S. Kucherawy
- Re: [ietf-dkim] chained signatures, was l= summary, Douglas Otis
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
- Re: [ietf-dkim] chained signatures, was l= summary, Michael Thomas
- Re: [ietf-dkim] chained signatures, was l= summary,
Douglas Otis <=
- Re: [ietf-dkim] chained signatures, was l= summary, Murray S. Kucherawy
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
- Re: [ietf-dkim] chained signatures, was l= summary, Doug Otis
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
- Re: [ietf-dkim] chained signatures, was l= summary, Murray S. Kucherawy
- Re: [ietf-dkim] chained signatures, was l= summary, Doug Otis
- Re: [ietf-dkim] chained signatures, was l= summary, Murray S. Kucherawy
- Re: [ietf-dkim] chained signatures, was l= summary, Doug Otis
- Re: [ietf-dkim] chained signatures, was l= summary, Stephen Farrell
- Re: [ietf-dkim] chained signatures, was l= summary, Charles Lindsey
|
|
|