----- Original Message -----
From: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
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