----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)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.
As a follow-up, I think if the bh= hashing is based on the original body,
then it would be the same idea of using STRIP or "Eat All CR/LF" concept.
We have put DKIM testing on the backburner since BASE-01, but I was
supportive of the bh= concept since its introduction. The only that
scratched my mind what the separation idea and I think this issue now comes
to highlight the need to separate it.
I am reading the bh= specification now, and it seems to me that in order to
allow increase reliability, we might need an (optional) separate c= tag,
such as "bc=" to define a possible Body Canonicalization method.
I'm just winging it now, but here is something I see possible with backward
compatibility:
B0 - body hash of original content
BH - body hash based on STRIP method
bc=STRIP required, with no alternative method, this serves as
trigger for the verifier. If bc=STRIP is not found, then
we are back to BASE-04 logic, no need to calculate BO.
B - per spec, the hash of h= fields and constructed DKIM-SIG
minus the BO tag
In short, if a domains wants to increase the survivability of the message
distribution, he would do the following:
SIGNER:
1) Add bc=STRIP tag for the DKIM-SIGNATURE.
2) Calculate the bh= body hash of STRIP message content.
3) Per spec, add bh=body-hash tag to the DKIM-SIGNATURE: header,
and calculate the b= signature hash.
4) if BC=STRIP was enabled, calculate the BO= body
hash of the raw "as is" content, and add bo=orig-body-hash
tag to the DKIM-SIGNATURE: header
VERIFIER:
1) If the bc=STRIP tag is presence, this will trigger
a body hash based on the STRIP method.
2) Per spec, verify the signature.
3) If valid, an local policy or domain policy drive option should be
available to check the bo= tag.
I see as acceptable from my standpoint of having major concerns about the
open-end blasting of DKIM messages and its current high degree of
invalidity.
A) It gives us an important eliminating of 822/2822 CRLF related issues.
This issue as it relates to CR/LF characters, is now resolved for all
intent and purposes.
B) It increases the odds of successful DKIM validation that is
currently plagued with body CRLF mutation issues.
C) And Finally, if the signature FAILS at this point, then it really doesn't
matter what the original mail integrity issues are. However, if the
signature is valid, then we have an additional piece of information to
determine of the mail content was altered.
This provides four result conditions:
R1 - 100% validation (both signature and bo= valid)
R2 - near 100% validation (signature valid, bo= failure)
R3 - near 100% failure (signature invalid, bo= valid)
R4 - 100% failure (both invalid signature and bo=)
If everything checks out successfully (R1), then this was a strong
validation with no in-transient mutations.
If the bo= is the only failure (R2), then does not necessary mean it was a
BAD message from a BAD ACTOR as long as the signature itself survived. The
odds are good that this is condition due to transient mutations.
I would think that when the signature is invalid (R3 or R4), then this will
fall under the current specs considerations for invalid signatures.
However, a verifier may wish to check BO anyway to analyze if the header
hashing may have failed.
If there an exploit in any of this here, I don't see off hand, but the
verifier implementation should have the option NOT to hide the possible type
of message failure incidences.
In summary, the only changes I see to the base would be to offer a STRIP
method for the BH= coupled with a BO= hash that will help put a security
wrapper around authenticity protection.
- Add bc=strip to DKIM-SIGNATURE header
- Calculate bh= based on strip
- Calculate b= signature
- Add bo=orig-body-hash to DKIM-SIGNATURE header
Comments?
I personally like it and I think it will help me once again get excited
about restarting the DKIM project. The current system has a higher cost in
software changes in our framework where we still have various legacy 822
mail processing and gateway considerations. In addition, the current spec
introduces a redesign dilemma of where exactly do we fit DKIM in our
framework. Using a STRIP and BO= to protect it, will help eliminate our
integration design considerations and more importantly lower implementation
cost.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html