Jim Fenton wrote:
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.
+1.
In lieu of a proposed KEY attribute "l=w|p", not defining the body limit
with the DKIM-SIGNATURE: header l= tag, should be noted in the DKIM-BASE
specs.
Otherwise, you are open to Body Limit Security Attacks. I'm sure every
SIGNER would want to avoid any possible security exploit and not
defining the body limit during the signing practice and if not defining
the l= tag eliminates this exploit, then it should highlighted in the
specification.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html