Conjecture: There are counter examples where things are suboptimal for
any algorithm you can specify.
You bet.
Corollary: Yes, we can come up with examples where internal whitespace
is significant. Yes, we can come up with examples where trailing
whitespace is significant. Yes, we can come up with examples where
trailing trailing newlines are significant. (If you can't, try harder.)
The question for me is: How much do the different algorithms affect
security for typical use? And how much does the security degrade when
the non-optimal case is present? And is that acceptable?
It is clear a balance needs to be struck between the amount of security and and
the degree to which we want to tolerate alternations in transit.
I believe we need to err on the side of tolerance. Why? Because if the choice
we make is too strict too many people are going to experience signature
validation failures. They will then conclude that DKIM is a waste of time. And
if that becomes a common opinion bye bye deployment.
Now, I actually think the nowsp algorithm goes a bit too far in that it drops
internal whitespace in message bodies. I don't see a good reason to do that,
and would prefer to have it dropped. But I certainly can live with it if
that's what the group wants. Better to err...
I'm much more worried about simple mode. I even worry about the name, which
makes it sound like the preferred mode, which I don't believe it is or ever
will be. And as I said before, I worry about the incompatibilities with
existing messaging standards that have already been pointed out. I worry that
the specification doesn't provide enough advice about when (and if) it should
be used. And finally, I worry about the apparent secondary goal (or aspiration,
or whatever you want to call it) that we're gonna use this work as a means to
clean up the infrastructure.
There have also been proposals of other canonicalizations that might be used
instead. I would be happy with most of them as alternatives to nowsp. OTOH, I
really don't want to see a long list of supported canonicalization algorithms
in the specification, nor do I see a need to engage in change for change's
sake.
One final note. How many users of this stuff do you think are going to be able
to appreciate the difference between the various canonicalization modes? My
guess is very few will. This opens the door to attacks where simple mode use is
assumed but noswp mode was actually used. Of course including the mode
specification in the signature, as DKIM does, does mitigate some of these
attacks. But not all.
Ned