Re: [ietf-dkim] l= summary, as I see it
2009-05-28 21:24:56
On May 28, 2009, at 5:00 PM, J.D. Falk wrote:
Barry Leiba wrote:
Just on one portion, here:
On Thu, May 28, 2009 at 3:30 PM, Doug
Otis<doug(_dot_)mtview(_at_)gmail(_dot_)com>
wrote:
Some systems handle message attachments separately, and at times
may exclude attachments. Eventually, a practice similar to DKIM
should be established to separately encapsulate attachments. Once
such a convention exists, separating message attachment hashes
will better ensure textual portions of a message can be handled
independently from that of message attachments.
Hm.
I should think that the DKIM way to handle the removal of
attachments would be for the agent that remove the attachments to
re-sign the message after it does so.
Agreed. No matter which MIME part was affected, it's still a
modification of the original message and thus invalidates the
assertions inherent in the original signature.
I don't agree. Information can be contained within a message that
indicates the existence of the attachments, and even, after extracted
from some repository, what their hash results should be. I also agree
with John about providers being unlikely to go to any additional
effort. It not in their nature, but of course only time will tell.
We should take the time to discover how DKIM and A-R will be abused or
misused.
One thing is fairly certain. The l= parameter might greatly assist
MUAs in isolating cruft added by a provider. Unfortunately, when the
debate is about security, or what a provider can get away with,
security always is at the short end of the stick.
When a reputation service bases a recommendation upon the DKIM signer,
an MUA finding the original signature and a broken hash due to some
notice or ad, could still utilize the l= parameter to differentiate
what had been appended or prefixed by some third-party. It will be
exceedingly difficult to establish fully independent two-way
reputations. The reputation of the signer, and that of the provider
which might include some unknown fly-by-night ad links. The recipient
is likely to think they are trusting big-bank endorsed by the
reputation check, only to find the link contains an iFRAME that
installs malware because the ad server was improperly secured. Only
when an MUA carefully annotates what is the signed content, can the
reputation be based upon the source of the message, independent of
notices that may have been included. Needing a single reputation
result rather than two makes resolving the l= issue well worth the
effort.
-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] l= summary, as I see it, (continued)
- Re: [ietf-dkim] l= summary, as I see it, Douglas Otis
- Re: [ietf-dkim] l= summary, as I see it, J.D. Falk
- Re: [ietf-dkim] l= summary, as I see it, J.D. Falk
- Re: [ietf-dkim] l= summary, as I see it, Doug Otis
- Re: [ietf-dkim] l= summary, as I see it, J.D. Falk
- Re: [ietf-dkim] l= summary, as I see it, Doug Otis
- Re: [ietf-dkim] l= summary, as I see it, Barry Leiba
- Re: [ietf-dkim] l= summary, as I see it, Doug Otis
- Re: [ietf-dkim] l= summary, as I see it, Barry Leiba
- Re: [ietf-dkim] l= summary, as I see it, J.D. Falk
- Re: [ietf-dkim] l= summary, as I see it,
Douglas Otis <=
- Re: [ietf-dkim] l= summary, as I see it, Tony Hansen
- Re: [ietf-dkim] l= summary, as I see it, Michael Thomas
- Re: [ietf-dkim] l= summary, as I see it, Dave CROCKER
- Re: [ietf-dkim] who's using l=, John Levine
- Re: [ietf-dkim] l= summary, as I see it, Wietse Venema
- [ietf-dkim] evangelizing dkim, Dave CROCKER
- Re: [ietf-dkim] l= summary, as I see it, Charles Lindsey
- Re: [ietf-dkim] chained signatures, was l= summary, John Levine
- Re: [ietf-dkim] chained signatures, was l= summary, Barry Leiba
- Re: [ietf-dkim] chained signatures, was l= summary, John R. Levine
|
|
|