Subject: Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

From: Doug Otis <[email-masked]>
Date: Mon, 1 Jun 2009 11:33:19 -0700

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