On 05/May/11 22:54, Barry Leiba wrote:
If this is the sort of advice we are going to give then we should just
deprecate "l=".
+1: it was an error in the PS and the DS fixes it.
Alternatively we can allow it, warn, and expect implementers to code
heuristics that can discern attacks from regular footers.
Speaking as an implementer, I ignore l=, because the hassle of working
around it and trying to guess how hostile any added content might be is
vastly greater than any utility it has.
We certainly could deprecate it, and add something that says that
verifiers MAY consider a signature for which l= is less than the full
message length to fail verification. Such a change should have been
proposed earlier in the process, but I won't consider it out of scope
if we have consensus to do that now.
One place to put a normative "MAY" is in the last paragraph of section
6.1.3 "Compute the Verification". E.g., replacing it with
A body length specified in the "l=" tag of the signature limits the
number of bytes of the body passed to the verification algorithm.
Any added content, that is text beyond that limit, is not
validated by DKIM, whether it was present at the time of signing
or not. Verifiers MAY apply whatever heuristics in order to
determine the legitimacy of existing added content; in particular,
verifiers MAY consider any added content hostile and hence return
PERMFAIL (unsigned content) for signatures having l= less than the
full message length.
If something like this is stated, the INFORMATIVE IMPLEMENTATION
WARNING of section 3.5 should be modified so as to avoid redundancy.
E.g. by replacing
To avoid this attack, signers should be extremely wary of using
this tag, and verifiers might wish to ignore the tag
with, say,
To avoid this attack, signers should be extremely wary of using
this tag, unless they know what heuristics verifiers will apply.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html