On July 14, 2005 at 23:54, domainkeys-feedbackbase02(_at_)yahoo(_dot_)com wrote:
I suspect you already know this, but *everyone* appears to have their favori
te
canonicalization formula. And they are all different at the edges. As a
proposer of - dare I say it - Yet Another Canonicalization Algorithm, it'd be
interesting to hear your ideas on how we should assess the merits of each alg
.
and how we determine whether one algorithm is significantly superior to anoth
er
... as opposed to just being different.
Algorithms should be judged on:
(1) Security
(2) Performance
(3) Handling of common mutations in transmission
(3) needs to be constrained to mutations that do not effect the meaning
of the data (which is a (1) security concern). For example, whitespace
padding in header fields or at the end-of-lines in body data do not
change the "meaning" of the data. Now, the current nowsp algorithm
in the DKIM draft does. "Hello World" is different from "HelloWorld".
When whitespace is significant, it should not be dismissed.
Where the real discrepency is what mutations should be covered in (3).
I base my list of mutations is what is mentioned in the myriad of
email-related specs (due to the experiences of the respective authors)
and what is known to happen on the Net.
I'm aware of the following mutations that cause no changing in
the "meaning" of the data:
(A) Header line folding (as defined by RFC-2822).
(B) Whitespace padding at the end of line (records), headers
and bodies.
(C) Additional whitespace (e.g. CRLF sequence) at the end of
the message body (I've seen sendmail actually do this).
(D) Refolding and translation of whitespace in header fields.
Therefore, I try to address these, and address them in a manner that
does not compromise (1) security and can be done (2) efficiently.
Now, it may be the case that such mutations are becoming rarer,
and the verification failure rate may be acceptable for such cases.
If a mutation scenario is to be dismissed, some real stats should
be provided so potential adopters can determine if the dismissal
is justifiable or an unacceptable risk.
Mutation concerns can be influenced on when signing occurs.
For example (C) may not be a problem if the MTA does the signing vs
a signing agent that passes the messages to an MTA for delivery.
I still do not like that mail signatures should be restricted by
border MTAs, so I think (C) is worth handling and there is no real
(2) performance considerations.
(A) appears to be a gimmie to do, regardless.
--ewh