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
<doug(_dot_)mtview(_at_)gmail(_dot_)com>
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