ietf-dkim
[Top] [All Lists]

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