----- Original Message ----- From: "Mark Delany" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 24, 2006 11:36 PM Subject: Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method
> 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. Not sure I follow. The canoniculation should be transparent for hashing purposes. It should not be for correcting feeds. If such content was change to the above, you would be able to assest with 100% certainty all MIME processors (including our own) will fail since there is no delimiter. All MIME processors are not going be able to parse/read this anymore. Put another way, no would should expect the MIME processor, whether it was a UA or some other middle waire mail processor, to be able to parse the above. There has to be atleast 1 delimiter. The suggestion I am making removes the idea CR/LF alterations have taken place from the DKIM hashing process. The becomes an independent feed concept because the canonicalization is internal. There is no consideration for "correcting" a feed for other systems. There are two parts: - The BH is based on a transparent hashing as one ingredient for the DKIM signature, and - A separate BO for detecting original content alternation. The verifier will have the ability to report (provide result for a presenters, etc), a DKIM Signature is valid, but the original method content has been alterated. In the current scheme, signature validation would fail. In the old nofws, it would survive, but there wasn't a way to determine what actually failed. I believe this was the main point behind the new body hash (bh=), as a way to determine if the body failed or the header failed. This was why I added my support to it. It was a good idea. But we now need to fine tune it because we have not yet to resolve how to increase the surviiablity of the DKIM signature hashing during distibution. > 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. Agree, but I don't see any improvement in the current scheme. It appears nofws was removed because one made the determination that it was insecure. Was there an approach to how to fix it instead? > 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. I understand this philosophy 100% and in general, practice it myself. But we still have an engineering problem that will minimum the WIDE acceptability of DKIM. I am proposing a solution that might help without having the security problem that was deemed with nofws. I capped WIDE because DKIM is very good for a closed or exclusive signing system where there is a strong two-way DKIM negotiation between "known" end-points. But as a wide adoption, I strongly believe DKIM runs a high risk on causing more harm than good with an open-ended broadcasting of high potential failures. The only way to avoid it will be to ignore it - completely. Don't try to support it, just like we ignore all the Domainkey mail we see coming thru our side. With our testing, nearly all of them failed validation. We saw the "Fake Facsimiles" but for the most part it was all due to the mail integrity. It was impossible to determine why it really failed. To me, that is unacceptable There needs to be a good reliable reason to begin DKIM implementation. We already did the cost assessment, and for us, it presented a very high impact to implement DKIM as it currently defined. I believe a little more fine tuning will eliminate and/or lower the cost, and I think, this suggestion of stripping all CR/LF from the hashing will atleast give us the ability make the validation more reliable. With the additional, of the BO hash, that would resolve the authentication of the mail content concerns. What I see is this is a R1 and R2 condition that people will accept: R1 - 100% validation (both signature and bo= valid) R2 - near 100% validation (signature valid, bo= failure) What we have now is a high signature invalid condition where most of the failure is due to the hashing issue - a problem that can be solved and at the same time help lower all the pressures of trying to change the world to accommodate the current DKIM design. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
