Hector Santos wrote:
hmmmmm,,
I read the DKIM-BASE specs a few times now and I don't see anything
nor do I recall any list discussion about the body content containing
leading <CRLF> lines and dealing with them, especially in relationship
to the much debated l=2 or SIMPLE c14n "empty" message.
Consider the following RFC 2822 message:
headers:<CRLF>
<CRLF> <-- RFC x2822 header/body delimiter
<CRLF> <-- Beginning of body
12345678<CRLF>
12345678<CRLF>
<CRLF>
Here we have 24 message body bytes with 1 leading blank lines.
It would be super silly to set a L=2 to hash only the first two bytes
here where the two bytes are <CRLF>. This would result in a facsimile
of an of empty message which has an exploitable body altering hole.
I think we need one more LINE of text in the DKIM-BASE.
"Although it is possible to hash only a part of the
SIMPLE canonicalized message body, it is highly discouraged
to hash only two octets if the leading two octets are <CR><LF> and
there additional non <CR><LF> octets."
I don't think this accomplishes what you intended. If you're worried
about an attacker exploiting a body-less message signed with l=2, the
attacker could still start their message with a blank line. It then
would be up to the verifier to treat this specially. Expecting the
verifier to do something special with messages signed with l=2 is an
unnecessary, and error-prone, rule.
If the signer wants to make sure that messages are not subject to
"append attacks", they shouldn't use l=. Use the default.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html