Charles Lindsey wrote:
On Mon, 22 Jan 2007 12:32:10 -0000, Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Example:
So we hash the SIMPLE c14n empty message with the <crlf> l=2 bytes to
indicate that the message was indeed "empty" and not some malicious
body altered message if l=0 was allowed to be used to indicate an
"empty" message.
But l=2 does NOT indicate that the message was "empty". It merely
indicates that the first line of the message was an empty line. It says
nothing about the huge text that follows that empty line, whether that
text was provided by the original sender or by soem intermediate scammer.
That is correct as pointed out in my last issue post regarding leading
blank lines:
http://mipassoc.org/pipermail/ietf-dkim/2007q1/006941.html
I think the overall issue here is that the DKIM-BASE specs lacks
discussion on "Partial Hashing" considerations.
This is not a technical problem - but a SECURITY issue, and it should be
addressed with a KEY attribute that defines the EXPECTATION of the
signer for WHOLE or PARTIAL hashing requirements.
In fact, looking at the spec, section 8.1 makes a profound statement
statement about potential attacks, yet, offers no possible remedy:
8.1 Misuse of Body Length Limits ("l=" Tag)
Body length limits (in the form of the "l=" tag) are subject to
several potential attacks.
Thats it!! That is all it says. This needs action. I think this whole
issue can be resolves once and for all with a KEY attribute that defines
the whole vs partial hashing expectations.
I vote for a new corresponding key tag, "l=" in section 3.6 Key
Management and Representation.
l= Defines whole or partial hashing of body
w The entire body is hashed (default). The
DKIM-Signature: l= tag may be omitted or defined
with the full body length.
p Partial hashing allowed.
# If a number is defined, this is the MINIMUM bytes
allowed to hashed.
Again, I'm just winging it and I hope some doc person can do a better
job. I personally prefer the default to be entire body hashing.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html