On May 21, 2009, at 10:30 PM, Eliot Lear wrote:
My recollection of the debate about l= is that there were about as
many theories about the point of l= as there were people promoting
it. The main theory I remember was about hypothetical mailing
lists that were too incompetent to filter incoming spam so the list
recipients would do it based on the signatures of messages that
passed through the list.
Except we now know that one major piece of list software can
preserve the signature, depending on whether subject is signed /
preserved.
While mailing lists are common, it seems doubtful mailing lists will
be where the l= feature adds much value. It is fairly common to find
notices and ads added to messages. Having the length of the message
body explicitly defined allows signatures to be checked and added
content identified without tracking every iterative hash value.
Unlike OpenPGP or S/Mime, the message does not contain a structure
that might be visible to recipients, but this creates some risk. Some
providers might even wish to prevent MUAs a means to verify DKIM
signatures and thereby remove a means to ascertain exactly what
portion of the message had been signed, as might be revealed by the l=
parameter. When a provider does not offer DKIM signature checking as
part of their service, adding the l= feature ensures DKIM signatures
in general remain more reliable. A declared body length ensures the
signature remains robust and more able to endure varied use. A
partially signed set of the body parts, other than attachments,
represent a reasonable basis upon which to reject a message as being
deceptive. Perhaps an extension to DKIM might even include a signed
header containing attachment hashes.
One other aspect to keep in mind involves a growing threat caused by
bot-nets. Hashes are quickly defeated with rainbow tables. Not
having a body length asserted by a DKIM signature header allows the
generation of hash lists by simply extending a phish body and
recording results at each length extension. Millions of systems
controlled by bad actors can generate partial rainbow tables and be
queried against intercepted message signature hashes to improve the
odds of generating convincing spoofs. By having DKIM signatures
explicitly declare body length, this then requires significantly
greater resources to build rainbow tables. With storage and bot-net
growth, estimates of the time to defeat hashes may need further
review. Causing the generation of rainbow tables to be more resource
intensive provides another possible benefit of the l= feature.
The current impetus for recent changes to DKIM seem aimed at
increasing dependence upon the providers performing DKIM signature
checks rather than allowing MUAs a means to retain this ability when
needed. This strategy may even make DKIM appear too unreliable within
current email infrastructure for conducting commerce. These changes
seem unlikely to improve DKIM, nor should the ultimate goal be to only
allow a DKIM state of Signed/Not Signed. This takes DKIM down a path
likely to cause complaints and to generate a greater uncertainty which
will lead to more victims.
Signed/Not Signed does not represent a result that can be made robust,
nor made to encompass DKIM's modes of use. Don't expect DKIM to adopt
the limitations of authorization strategies as a desired goal. DKIM
may not have been signed by the Author Domain, which requires more
than just a lock-symbol. In addition, the body of the DKIM message
may have been appended to or prefixed. A body length allows a quick
means to determine which.
How are the suggested "simplifications" to DKIM beneficial when they
increase the odds of recipients finding legitimate signatures marked
invalid, or when they make it more difficult for signers and recipient
to mitigate replay abuse? Leave DKIM as is and allow time to shape a
best practices document. Don't underestimate what a MUA is able to
convey.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html