ietf-dkim
[Top] [All Lists]

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

2009-05-20 15:48:00

On May 20, 2009, at 9:55 AM, Dave CROCKER wrote:

Steve Atkins wrote:
If a signer uses l=0 (or, given MIME games that can be played, any  
other l= value) then the only thing you can say about any validly  
signed message from that sender is that the subject line of the  
message is the same as the subject line of a message that sender  
signed. I don't think that's a useful level of protection for any  
use case.

It means that I can, for example, take one copy of a service notice  
from my bank, leave the headers the same and replace the URLs in  
the body of the message to links to my website, then send it out to  
a hundred thousand people - and it would be validly signed by the  
bank. (The only user-visible content I wouldn't be able to change  
is the subject line).

This sounds like a plausible and serious scenario.  Even with l>0,  
it suggests a line of attack -- by adding malicious text that  
appears to be part of the bank notice.

What is the counter-argument, in favor of retaining l= ?

IIRC, this concern has been discussed at length.  Why rehash the l=  
feature so soon?

Is there any evidence it is being used?  Is there any evidence it is  
treated usefully by receivers?

Again, it seems too soon to tell.

IMPOV, malware scanning email, once considered essential,  must not be  
relied upon to detect threats. :^(

Any application attachment should generally contain source  
authentication signatures.  As this happens, DKIM protections become  
redundant for such application attachments.  This redundancy might  
become significant for large attachments, especially when DKIM adopts  
more resource intensive hashing algorithms.  There are new products  
and services emerging, along with a growing use of various content  
protection schemes.  The next few years will likely witness an  
industry evolve as it responds to what is becoming a serious security  
crisis.

People tend to treat email as a means of sharing files.  These files  
are then published and redistributed using various means.  This mode  
of sharing is not ideal, but having application information exchanged  
in self-authenticating containers would make security much easier to  
manage.

Since email must deal with large amounts of spam and abuse, it would  
be good to have provisions in DKIM that allow secured attachments to  
be excluded from the DKIM hash algorithm without causing the entire  
message to be considered unsigned.

Also, it is common to find notices or ads appended to messages.   
Explicit length indications as to what is signed provides a means to  
better determine what should and should not be annotated, without the  
entire message being considered unsigned.

It seems prudent to wait.

-Doug





_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>