In the new section 8.14, I believe there is many statements that are
hardly true, but subjective and written by someone begging to pass the
buck with conflictive arguments.
DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM. Lets play fair
with all parties.
1) Contradiction
Many email implementations do not enforce [RFC5322] with
strictness.
As discussed in Section 5.3 DKIM processing is predicated on a
valid
mail message as its input.
If DKIM designers knew there were many email implementations with less
than strict enforcement and strictness was an requirement, then DKIM
started with a problem it ignored to address. Either it was ignorant
or poor engineering.
Reword this.
2) There is no intent.
With the intent of providing a better user experience, many
agents tolerate
these violations and deliver the message anyway.
There is no intent by anyone to allow violations. This isn't a game.
People have commercial systems and do not just say "Hell, lets not
follow rules." There are just things that are not expected just like
DKIM didn't expect it.
Also keep in mind, many systems do reject or flag bad RFC
822/8222/5322 messages. The issue here is that DKIM was a loophole
even against compliant RFC5322 checking systems as the President Obama
message shown.
Reword this.
3) Philosophical conflictive parenthetical sentence:
(This can also be taken as a demonstration that DKIM is not designed
to support author validation.)
It demonstrated the opposite. Please, DKIM *does not reduce* the long
historical power of author of the message in any shape or form. The
AUTHOR will always be a powerful part of the message. DKIM does
validate the author and this requirement is reaffirmed by its special
consideration - the only REQUIRED header binding. Until the 5322.From
binding is made optional, it will always continue to be very important.
In addition, the statement is protocol inconsistent with other
existing and new internet protocols that do and continue to make the
author a powerful part of the message.
Please STOP trying to disassociate the 5322.From from the long time
email message communication between parties.
Please remove this "Oh by the way.." parenthetical statement.
Here is my reworded text. I would not give the "How to Exploit." Let
the bad guy figure it out. No blaming anyone.
8.14. Attacks Involving Addition of Header Fields
Historically, email implementations have been tolerant of less than
100%
strict RFC822, RFC2822 and RFC5322 formatted messages. There are
certain elements within DKIM predicated on having a valid RFC
5322 messages.
For example, a message with a single From: header field is expected and
required by DKIM. Having more than one From: header violates
Section 3.6 of [RFC5322] and should be rejected or flagged by
receiving MTA systems and not passed on to DKIM signing engines.
A signer wishing to be resistant to any specific multiple header
attacks can include in the signed header field list an additional
instance of each field that was present at signing. For example, a
proper message with one From: field could be signed using
"h=From:From:..."
Because of the way header fields are canonicalized for input to the
hash function, this would prevent additional fields from being added,
after signing, as this would render the signature invalid.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html