----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Hi Hector,
Not that I follow this entire thread (anyone like to summarise?)
From my perspective, I can summarized it as a debate on the
essential question:
Does the System fit into DKIM or does DKIM fit into the System?
but just on this point:
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 bh= is based on the raw original content, then yes, it would be
the same thing.
I also think that the putative "eat all CR/LF" c14n might be
hard to get approved, given the obvious vulnerabilities it'd
create.
I would like to see some documentation or references on this and its
conclusions.
Of course, if so, it is not addressable?
I mean, if STRIP provides a more robust and high reliability for validation
and can help DKIM from an implementation standpoint (DKIM fit into the
system), is there a way to protect against STRIP exploits thereby making the
method more acceptable?
The issue is very clear, hashing on original content and expecting this to
survive is on the low end of reliability spectrum. Nothing really matters in
DKIM if body hashing isn't deem reliable.
So "theoretically" hashing needs to be done with a canonicalization method
that is deemed to be robust and reliable in addressing on 822/2822 EOL
integrated infrastructure issues.
If and only if the DKIM signature is valid, the verifier can choose to check
the original content hash (hopefully based on the policy driven original
domain expectation for in-transient survivability or not).
John made a good suggestion for experimentation, that's always a good idea.
But it seems pretty obvious if the current hashing is problematic because of
unexpected cr/lf characters in the stream or lack there of, then removing
them from the DKIM hashing equation is a random simple understanding for a
solution.
But I would like to see some references on the vulnerabilities for his "eat
all cr/lf" CL4N method and then see if using a secondary original content
hash can help protect this scheme.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html