For readability, I will propose my 8.14 text change suggestions as a
whole:
8.14 Non-Compliant RFC5322 Messages
There are known conditions which can alter the originality of a
DKIM signed message without breaking the existing signature validity.
Since it is possible to maintain the integrity of the signature with
known non-compliant RFC5322 message altered conditions, there is an
increase possibility of abuse and exploitation of MUA displaying
information which were not validated by the signature. Examples may
be non-compliant RFC 5322 messages containing a 2nd 5322.From or
2nd Subject headers which were not hash bound to the DKIM signature,
yet due to the nature of MUAs, the wrong header could be displayed
to end-users.
It is unknown how these non-compliant RFC5322 messages will be
handled by backend MTA receivers and how MUAs will display them.
It is conceivable, some MTAs will reject these messages while other
MTAs may accept it but only after it has sanitize the message for
user display. Yet other MTAs may be unaware of the multiple
headers in these non-compliant RFC5322 messages.
Under unchecked conditions, this can allow an attacker to
replay a previously sent, signed message with a different Subject,
From or To field.
Despite the apparent scope of this requirement, there are
implementation circumstances in which how DKIM processes
these non-compliant RFC 5322 messages can not be determined
until it is known how these messages are first passed or
reach integrated DKIM processors.
With an increase alertness of the possibility for these
non-conforming RFC5322 yet DKIM compliant messages, receiver
MTA may begin to perform this filtering at an increase level.
This recommended form of processing will minimize any
implementation requirement for DKIM to perform this non-compliant
mail check.
In addition, enhanced MUA operations can address the situation
as well with attentive awareness of non-compliant message displays.
To address current or legacy email implementations that may not
aware of these non-compliant RFC 5322 double header messages, DKIM
Signers concerned their signed outbound messages might be
particularly vulnerable to this form of attack can ensure that
adding unexpected additional header fields will break the DKIM
signature by including two copies of the header fields about
which they are concerned in the signature h= tag e.g. "h= ...
from:from:to:to: subject:subject...". See Sections 3.5 and 5.4
for further discussion of this mechanism.
--
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