Scott Kitterman wrote:
On Wednesday 24 January 2007 12:57, John Levine wrote:
If the signer wants to make sure that messages are not subject to
"append attacks", they shouldn't use l=. Use the default.
IIRC, every time someone brings up l= problems, the response is don't use
it. Is there a problem it solves that we need it? If it's inherently
risky and should not be used, I'm wondering if it should even be in the
RFC?
Personally, I have never thought that l= would be useful, but I was
willing to leave it in the draft for the benefit of people who want to
try it out. This document is in last call, it is nuts to propose
opening it up to add yet more untried features of at most debatable
utility.
-99 to any proposed new features
Agreed. My question was mostly academic (should have said that I guess), but
if we are going to get into a long discussion about fixing problems with l=,
then the alternative of removing it seems worth considering (I'm not
proposing we have the long arguement, but if we do...).
+101.
I don't claim the have the IETF handbook master, but what is the purpose
of the last call?
Come on, we spent a few hard fought years on this stuff. Many are
extremely anal on semantics, and gods knows that we had the battles over
very sensitive issues.
But if there is something we should all AGREE with is that if there is
an a SLIGHT HOLE that we can most definitely and concretely remove at
this point with the mere stroke of a few written keystrokes, then we
should not allow a "LAST CALL" claim stop what should be done.
Its not like we have production software in the market place. DKIM is
still a pipe dream. Lets at least get what we can out of the way. This
is one of them. The exploit is real very and we don't need to rehash
the spammer steps to do it.
At the very least, Eric should add a statement about omitting the l= tag
to avoid any signer concern about partial hashing body limit replay
exploits. This should be the default behavior for production software
before the RFC status is given. By then it would be too late.
Come on, this is small potatoes compared to the other debated stuff.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html