[ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines
for SIMPLE c14n.
hsantos at santronics.com
Wed Jan 24 08:26:00 PST 2007
Jim Fenton wrote:
> Hector Santos wrote:
>> 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:
>> <CRLF> <-- RFC x2822 header/body delimiter
>> <CRLF> <-- Beginning of body
>> 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.
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
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
More information about the ietf-dkim