On May 22, 2009, at 11:40 PM, John Levine wrote:
When the body of the message has an open-ended length, the number
of attempts to produce a collision might be within what now seems
like a small number of attempts.
If SHA256 is that weak, we have worse problems than spoofed DKIM
messages. Fortunately, nobody I know in the crypto community thinks
that it is.
An open-ended body length places any hash algorithm at increased risk,
especially sha-1 which is likely to remain in common use. However,
with any hash algorithm, vulnerabilities are reduced whenever an
attack must generate specific body lengths, rather than allowing
variable body lengths be used in conjunction with various differential
collision techniques. The difference is the ease of an attack that
might be made possible through the use of a distributed network
supported by millions of compromised computers.
There remains a few prudent reasons for retaining the l= parameter:
1) better protects hash algorithms.
2) provides simple techniques to isolate prefixed or appended ads or
notifications added by the incoming providers. Recipients remain
better able to determine which message element had been signed, rather
than blindly relying upon ambiguous A-R headers.
3) allows future schemes to encapsulate attachments separately without
increased resource burdens.
It should also be noted that DKIM has yet to fulfill its intended
use. IPv6 has not become widely adopted where DKIM's features will
have been more fully exercised. Most of the changes to RFC-4871
appear aimed at preventing recipients a means to independently assess
incoming messages, and/or to differentiate incoming provider's content
from that of the original sender. This effort significantly
undermines the intent of the original RFC4871. Removal of explicit
expiry assertions or copied header fields also servers to limit a
recipient's ability to evaluate messages modified by incoming
providers. Knowing what to trust, is equally important to knowing who
is being trusted.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html