----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
> 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
