[ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method
MarkD+dkim at yahoo-inc.com
Mon Jul 24 20:36:52 PDT 2006
On Mon, Jul 24, 2006 at 10:21:51PM -0400, Hector Santos allegedly wrote:
> ----- Original Message -----
> From: "Stephen Farrell" <stephen.farrell at cs.tcd.ie>
> To: "Hector Santos" <hsantos at santronics.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.
can get turned into this:
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
> In short, if a domains wants to increase the survivability of the message
> distribution, he would do the following:
> 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
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.
More information about the ietf-dkim