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