On May 28, 2009, at 9:28 AM, Barry Leiba wrote: > I'm going to make one attempt here, and then give this topic up: > > On Fri, May 22, 2009 at 5:38 PM, Doug Otis <[email protected]> > wrote: >>> Sounds like an argument /against/ allowing part of a message to be >>> signed, and part not. >> >> By having a body length parameter as part of the DKIM protocol, >> whenever offered by the signer, users can employ MUAs that properly >> indicate which portions of a message originated by the signer, and >> which did not. > > The point, Doug, is that WITHOUT l=, the portions of the message > originated by the signer are [all], and the portions that were not > are [none]. So your problem is covered.
By specifying message body length, an MUA can better deal with A-R chaining. A-R headers now permit mail-box delivery agents the freedom to insert notifications and/or ads into the message. The A-R header will report "Domain X" had signed the message, while not providing any method to detect and isolate these possible mail-box delivery modifications. Without the ability to determine the length of the original message signed, determining the locations of simple mail-box delivery modifications goes from being automatic to fairly cumbersome. > The issue is whether it's useful to be able to HAVE a non-null > portion that "was not", which is what l= provides. What everyone > here is saying is that it is NOT useful to have that, so we don't > need l=. 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. Such separate handling should make the textual communication more robust. Retaining the l= parameter ensures future body length conventions can enable the separate handling of message attachments without impairing non-refutable textual content. Such a feature requires that the unmodified message bodies be recoverable in a simple fashion. > If you're saying that you WANT to be able to have an unsigned > portion of the message, then you're the only one. Everyone else > thinks that if such a thing exists, it should be considered evil and > thrown away. The desire is to retain an ability to treat attachments separately, in addition to locating mail-box delivery agent modifications. Future conventions will likely become more cautious about the handling of attachments, while hopefully ensuring the textual portion of the message remains non-refutable. To allow this to occur, demarcating the where the textual information associated with the message body ends and the attachments being become imperative. While perhaps this is not an apparent need currently, DKIM has not really be used all that extensively. In addition, use of the A-R process is also extremely new. When signature hashes are commonly invalidated as a result of isolated attachments, phishers will also appear to have had their messages altered in this fashion. > We put l= in there with the idea that it would be useful. We > experimented with it. We have the results of the experiment, and it > looks like we have consensus on this point. DKIM has yet to deal extensively with A-R processing, so one might say that the l= experiment is not complete, nor should the timeframe be so brief, especially after such a profound change to the way DKIM will be handled. It has been about 2 years since RFC4871 was completed. It took 19 years before rfc821 was obsoleted and then another 8 years for minor updates that mostly addressed IPv6. In addition, permanently dropping the body length creates greater exposure to the use of rainbow tables commonly used to defeat secure hashes. Bad actors now exploit distributed file systems across millions of compromised computers to find hash matches. When the body length is undefined, this enables a simple and rapid way to extend available hash values associated with different phish bodies. The size and extent of this technique may place DKIM at greater risk, especially where providers may be reluctant to use more resource intensive hashes. In addition, a provider's sensitivity to the DKIM resource issue can not be ameliorated by excluding large stand-alone attachments that can (and should) be separately confirmed prior to any use. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
