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
