On Mon, Jul 24, 2006 at 10:21:51PM -0400, Hector Santos allegedly wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
This can produce an interesting result with the DKIM signature
calculated as valid but with feedback that the originality of
the message has change.
Given our current definition of "bh=" isn't this just the same
as inventing a new "eat all CR/LF" c14n alg. and including
two signatures - one with simple for the body and one with
the new c14n for the body?
If I am wrong about this approach or there is serious security exploit with
this suggestion, please show how so I can nix the idea and move on. I don't
wish to waste time it isn't technically sound.
Well, one of the earlier DKIM nofws variants was nixed because it had
something similar. One of the concerns was that you can re-inject a
mail and *effectively* remove MIME boundaries and various MIME headers
as far as the UA is concerned, yet still have the email verify.
For example:
--pWyiEgJYm5f9v55/
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
can get turned into this:
--pWyiEgJYm5f9v55/
Content-Type: image/jpegContent-Transfer-Encoding: base64
Is that a problem? Probably not, but it makes me nervous because I
can't assess how UAs will react and I can't predict future MIME
headers.
In short, if a domains wants to increase the survivability of the message
distribution, he would do the following:
SIGNER:
1) Add bc=STRIP tag for the DKIM-SIGNATURE.
One thing that came out of the earlier nixing of the nofws variant is
that new canonicalizations are in the business of trying to prove a
negative - that something is safe. Just because no one identifies a
fault in a few days on a mailing list does not in any way mean that no
fault exists.
My general premise has always been that the more leeway you give, the
more risk there is. Consequently, folk proposing more leeway need to
demonstrate the cost/risk benefits more clearly than proposals that
afford less leeway.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html