Hector Santos wrote:
Jim Fenton wrote:
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.
The followup comments from Hector and several others lead me to believe
that some people are over-interpreting what I said above. As with many
things, there is a tradeoff between security and flexibility; this is
why we have canonicalization algorithms, for example. We discussed this
tradeoff extensively for the l= tag, and decided to retain it. I don't
see a good reason to revisit that decision. Rather, I am saying that
this specific attack can be avoided by not using the l= flag.
I don't see the value of specific text having to do with l=2 when the
body starts with CR LF. Append attacks exist when the body begins with
other things as well.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html